Онлайн-эквайринг — это приём безналичной оплаты на сайте через банк-эквайер или платёжного провайдера. Покупатель платит картой или через СБП, а ваш сайт получает подтверждённый статус операции и может передать заказ в работу. Если расчёт требует применения ККТ по 54-ФЗ, одновременно настройте кассу и передачу чеков через ОФД.
Покупатель нажимает «Оплатить», открывает платёжную страницу или виджет и выбирает карту либо СБП. Банк или платёжный провайдер обрабатывает операцию. После этого провайдер отправляет вашему серверу уведомление и показывает результат в личном кабинете.
Храните у заказа идентификатор операции — payment_id или его аналог из API. Минимальный жизненный цикл, который нужно учитывать: заказ создан, платёж ожидает оплаты, платёж успешно завершён, платёж неуспешен или отменён, возврат выполнен. Точные названия статусов берите из документации выбранного провайдера, но доступ к товару, услуге или отгрузке открывайте только после финального успешного статуса.
Не подтверждайте заказ по переходу клиента на страницу «Спасибо». Покупатель может закрыть браузер после оплаты, а злоумышленник — открыть URL страницы успеха без оплаты. Статус меняет только ваш сервер после получения и проверки уведомления провайдера.
Настройте обработчик webhook так: проверьте подпись уведомления способом из документации провайдера; сопоставьте payment_id, номер заказа, сумму и валюту с данными вашего заказа; затем сохраните статус операции. Повторные уведомления обрабатывайте идемпотентно: если этот payment_id уже учтён, не создавайте повторный заказ, отгрузку или чек.
В торговой точке клиент прикладывает карту к POS-терминалу, а в интернет-эквайринге оплачивает дистанционно. Банковский перевод по реквизитам тоже не равен эквайрингу: он не даёт готовый checkout и обычно не передаёт автоматический статус заказа на сайт.
Сравнить варианты подключения можно в материале «Онлайн-эквайринг: как подключить оплату на сайте и выбрать тариф».
Для корзины, доставки и промокодов выбирайте API или модуль для CMS. Цепочка должна быть такой: покупатель оплачивает заказ → сервер проверяет уведомление → заказ получает статус «оплачен» → начинается сборка или отгрузка → при возврате статус меняется после подтверждения возврата.
Для предоплаты на лендинге или после заявки используйте готовую платёжную страницу либо ссылку на оплату. Менеджер может отправить ссылку в мессенджере, а в счёт добавить QR-код, ведущий на платёжный сценарий. Не начинайте работу по оплачиваемой заявке, пока не получили подтверждённый статус платежа.
Для регулярных списаний нужен провайдер с рекуррентными платежами. До подключения проверьте сценарии согласия на списания, отмены подписки, неуспешного списания, возврата и уведомления клиента. Обычная разовая ссылка на оплату не заменяет рекуррентный механизм.
Карта подходит для привычной формы оплаты: покупатель вводит реквизиты и подтверждает операцию в своём банке. СБП переводит клиента в приложение банка или открывает банковский сценарий подтверждения.
QR-код не является отдельным платёжным методом наравне с картой и СБП. Это форма предъявления ссылки или инструкции для оплаты — чаще всего для сценария СБП. Показывайте QR-код в счёте, переписке, на экране администратора или в печатном документе, когда покупатель оплачивает с телефона.
На странице заказа выводите карту и СБП. В личном кабинете и API проверьте, что по каждому из этих методов видны создание платежа, успешная оплата, отказ или отмена, а также полный и частичный возврат.
Эквайринг проводит платёж, но не заменяет кассу. Если по вашей модели расчёта нужна ККТ, передавайте в кассу данные, необходимые для чека: состав покупки, сумму, контакт покупателя и признак расчёта.
Для безналичных расчётов между организациями и ИП без предъявления электронного средства платежа предусмотрено исключение из применения ККТ. Продажи физлицам, предоплаты, доставка, сертификаты и подписки требуют отдельной настройки кассового сценария. Официальные сервисы и разъяснения доступны на сайте ФНС России.
Для продаж через сайт часто используют связку платёжного сервиса и облачной кассы. Как выбрать и запустить её, читайте в статье «Облачная касса для интернет-магазина: выбор, подключение и запуск без ошибок».
| Критерий | Что проверить до договора | Практическое решение |
|---|---|---|
| Способы оплаты | Есть ли карта, СБП, возвраты по каждому методу | Для checkout подключите карту и СБП; для счёта или переписки добавьте ссылку либо QR-код для сценария СБП. |
| Комиссия и выплаты | Ставка для вашей категории, условия возврата, порядок зачисления | Сравнивайте условия договора и выплаты, а не рекламную ставку. |
| Интеграция | Модуль CMS, API, webhook, тестовая среда | Корзине нужен API или модуль; лендингу часто достаточно платёжной страницы. |
| Безопасность callback | Как проверяется подпись, какие поля приходят, как повторяется уведомление | Внедрите проверку подписи, сверку ID, суммы, валюты и номера заказа, а также идемпотентную обработку. |
| Возвраты | Полный и частичный возврат, статус возврата в API или кабинете | Возвращайте через провайдера на исходный способ оплаты и меняйте заказ после подтверждённого статуса. |
| Фискализация | Передача позиций заказа и данных расчёта в кассу | Настройте связку эквайринга, ККТ и ОФД до первого реального платежа. |
| Поддержка | Кто разбирает сбои оплаты, webhook и ошибки кассы | Назначьте ответственного и сохраните канал эскалации. |
Задайте провайдеру пять вопросов до договора: есть ли тестовый контур; как проверяется подпись webhook; какие статусы считаются финальными; поддерживаются ли частичные возвраты; какие данные передаются в кассу. Если ответы не закреплены в документации или поддержка не может показать тестовый сценарий, не запускайте интеграцию в боевой режим.
Выбирайте шлюз или модуль CMS для магазина с корзиной, CRM и автоматическим изменением статусов. Берите платёжную страницу или ссылку для лендинга, разовой услуги и ручной обработки заявок. Если сайт ещё проектируется, сначала определите формат продаж: лендинг, каталог или магазин. Это определяет объём интеграции. Поможет руководство «Сайт с онлайн-оплатой и кассой: лендинг, каталог или интернет-магазин».
Нужен запуск без угадывания? Интернет Касса подберёт связку эквайринга, СБП и кассы под ваш сценарий, проверит передачу статусов и чеков, а затем поможет подготовить запуск. Оставьте заявку на подбор и проверку интеграции — получите перечень подходящих вариантов и список работ до старта.
Заказ подтверждается по возврату пользователя на сайт. Оплата может пройти без возврата в браузер, а страница успеха не доказывает факт оплаты. Исправление: учитывайте только проверенный webhook или подтверждённый API-статус.
Webhook принят без верификации. Нельзя доверять уведомлению только потому, что оно пришло на ваш URL. Исправление: проверяйте подпись по документации провайдера и сверяйте ID платежа, заказ, сумму и валюту с вашей базой.
Повторное уведомление создаёт повторную отгрузку. Провайдер может доставить callback повторно. Исправление: сохраняйте обработанный payment_id и не выполняйте бизнес-действие второй раз.
QR-код подключён вместо СБП. Код сам по себе не создаёт платёжный рельс. Исправление: подключите СБП у провайдера, а QR-код используйте как способ открыть этот сценарий.
Возврат делают произвольным переводом. Так теряется связь между исходной операцией, заказом и отчётностью. Исправление: запускайте возврат через платёжный сервис на исходный способ оплаты, храните ID возврата и ждите подтверждённый статус в API или кабинете.
Касса не получает состав заказа. Чек может оказаться неполным или неверным. Исправление: на тестовом заказе проверьте все поля, которые сайт отправляет в кассу.
Для разовой услуги начните со ссылки или готовой страницы оплаты. Для магазина с автоматической обработкой заказов сразу закладывайте API, webhook и связку с CRM. Для подписки на первом этапе включите рекуррентные списания, отмену подписки и возвраты.
Перед стартом пройдите чек-лист: карта и СБП подключены; webhook проверяет подпись и реквизиты платежа; повторы не создают дублей; касса получает данные для чека; возвраты подтверждаются в API; назначен ответственный за ежедневную сверку. Это дешевле, чем исправлять потерянные заказы после запуска.
Да, применяйте онлайн-кассу, если ваш расчёт с покупателем подпадает под требования 54-ФЗ. Эквайринг принимает деньги, а ККТ формирует чек и передаёт сведения через ОФД; для безналичных расчётов между организациями и ИП без предъявления электронного средства платежа предусмотрено исключение.
Да, подключите карту и СБП на одной платёжной странице. QR-код можно показать как способ открыть сценарий СБП в счёте, сообщении или на экране, но он не заменяет подключение самого метода СБП.
Выберите платёжный шлюз или модуль CMS, если сайту нужны автоматические статусы заказов, корзина и интеграция с CRM. Готовая страница оплаты подходит для лендинга, заявок и ссылок, когда автоматизация минимальна.
Да, используйте готовую платёжную страницу, ссылку на оплату или модуль для CMS. До публикации проверьте серверное уведомление, его подпись, возврат и формирование чека, если ККТ обязательна.
Нет, подтверждайте заказ только после проверенного серверного уведомления или подтверждённого статуса в API. Клиент может закрыть браузер после оплаты или вернуться на страницу без успешной операции.
Сделайте возврат через платёжный сервис на исходный способ оплаты. Сохраните идентификатор операции и меняйте статус заказа после подтверждения возврата в API или личном кабинете; при применении ККТ обеспечьте корректное оформление кассового документа.