Платежный шлюз нужен, когда бизнес принимает оплату на сайте, в приложении или по ссылке и должен автоматически связать деньги с заказом. До запуска проверьте четыре вещи: серверные статусы, возвраты, сверку выплат и схему формирования чеков. Если настроить только кнопку оплаты, вы получите обращения «деньги списались, а заказ не появился».
Автор: Александр Пылев, Основатель Интернет Касса.
Платежный шлюз — это программный слой между страницей оплаты, платежным провайдером и вашей CMS, CRM или системой заказов. Он создает операцию, передает ее на обработку и возвращает статусы: платеж создан, подтвержден, отклонен, отменен или возвращен.
Интернет-эквайринг позволяет принимать оплату банковскими картами. Платежный агрегатор может дать один договор и один интерфейс для карт, СБП и других методов. Платежная форма — экран, на котором покупатель вводит данные и подтверждает оплату. Один провайдер часто объединяет эти функции, однако в документации отдельно найдите создание платежа, финальный статус, возврат и способ доставки уведомлений.
Не считайте оплату успешной по редиректу покупателя или странице «Спасибо». Покупатель может закрыть браузер до возврата на сайт, а операция при этом завершится. Меняйте статус заказа только после серверного уведомления от провайдера либо после подтверждения статуса запросом к API.
Шлюз не заменяет онлайн-кассу. Если по вашему расчету требуется ККТ, заранее определите, кто передает данные о товаре или услуге в кассу и как покупатель получает чек. Практическая схема описана в материале 54-ФЗ для бизнеса: когда нужна ККТ и как запустить работу с чеками; официальные сервисы по ККТ размещены на сайте ФНС России.
Подключайте платежное решение с готовой формой или CMS-модулем, если покупатель оплачивает корзину на сайте, в мобильной версии или по ссылке. Передавайте номер заказа при создании платежа, принимайте серверный статус и проверьте электронный чек, если применяете ККТ. Для выбора кассового контура используйте инструкцию «Касса для интернет-магазина: как выбрать решение под ваш сценарий продаж».
Выбирайте провайдера с токенизацией и поддержкой повторных списаний, если клиент платит регулярно. До старта пропишите действия при неуспешной попытке: отправить ссылку на оплату, выполнить разрешенную повторную попытку или приостановить доступ. Порядок запуска автосписаний разобран в статье о рекуррентных платежах для бизнеса.
Берите API-интеграцию, если создаете счета или платежи из своей системы и регулярно сверяете поступления. В карточке заказа храните номер заказа, идентификатор платежа, сумму, метод оплаты, финальный статус и дату выплаты. Эти поля позволяют сопоставить заказ с реестром провайдера и банковским зачислением.
| Формат | Когда выбирать | Что проверить до договора |
|---|---|---|
| Банк-эквайер | Нужен прием карт и команда готова работать с продуктом конкретного банка. | Доступные методы оплаты, API или CMS-модуль, тариф, график выплат, реестры и каналы поддержки. |
| Платежный агрегатор | Нужны карты, СБП и другие методы в одном договоре или требуется быстрый типовой запуск. | Какие методы включены для вашей категории, условия выплат, лимиты, возвраты и качество документации. |
| Отдельный шлюз или кастомная интеграция | Нужны несколько провайдеров, собственная маршрутизация или нестандартная логика платежей. | Кто отвечает за каждый участок цепочки, стоимость разработки и сопровождения, мониторинг и резервный сценарий при сбое. |
Выбирайте не по названию продукта, а по вашему платежному сценарию. Магазину с одной витриной часто достаточно банка или агрегатора с модулем. Сервису подписки нужны токены и работа с повторными списаниями. Платформе с несколькими источниками оплаты важнее API, реестры, маршрутизация и сверка.
Запросите тестовый доступ до подключения в боевом режиме. В тестовом контуре проверяйте не только успешную оплату, но и отказ, возврат, повторную доставку уведомления и задержку вебхука.
| Критерий | Что запросить или проверить | Действие до запуска |
|---|---|---|
| Способы оплаты | Карты, СБП, платежные ссылки и иные методы, которые вы планируете предложить покупателю. | Проведите тест каждого выбранного метода на мобильном устройстве и компьютере. |
| Тариф и выплаты | Комиссию, дополнительные платежи, срок и график зачисления, порядок удержаний и условия возвратов. | Посчитайте экономику на среднем чеке и пиковом месячном обороте; закрепите условия в договоре. |
| Лимиты | Ограничения на сумму одной операции, оборот, возвраты и число платежей. | Сопоставьте лимиты с максимальным заказом и прогнозом продаж. |
| API и CMS-модуль | Создание платежа, запрос статуса, возвраты, подпись запросов, примеры кода и совместимость с вашей CMS. | Передайте документацию разработчику и оцените доработки до подписания договора. |
| Вебхуки и отказоустойчивость | Список статусов, подпись уведомления, повторы доставки, API для повторного запроса статуса. | Сделайте обработчик идемпотентным и добавьте фоновую проверку статуса через API для зависших операций. |
| Антифрод и 3-D Secure | Настройки проверки операций, правила блокировок, отчет по отклонениям и порядок разбора спорных платежей. | Назначьте сотрудника, который проверяет подозрительные операции и обращения покупателей. |
| SLA и статус-страница | Канал поддержки, порядок регистрации инцидента, публичную или доступную клиентам статус-страницу. | Добавьте контакты поддержки и адрес статус-страницы в внутренний регламент. |
| Реестры и сверка выплат | Выгрузку операций и выплат, поля реестра, сроки появления данных, поиск по идентификатору. | Настройте ежедневную или согласованную по графику сверку заказов, платежей и выплат. |
| ККТ и чеки | Кто передает состав заказа, сумму и контакты покупателя в ККТ; как отражаются отмена и возврат. | Согласуйте схему фискализации и проведите сквозной тест с кассой. |
Обязательное поле для связки систем — единый идентификатор заказа. Передавайте его при создании платежа, сохраняйте в CRM и получайте обратно в уведомлении или при запросе статуса. Тогда поддержка найдет операцию за минуты, а не будет сопоставлять суммы вручную.
Ошибка: подтверждать заказ по странице «Спасибо». Исправление: подтверждайте оплату только серверным статусом — вебхуком с проверенной подписью или ответом API.
Ошибка: доверять только вебхуку. Исправление: храните время создания платежа и запускайте проверку API для операций, по которым уведомление задержалось. Это восстановит статус после сбоя вашего сервера или доставки уведомления.
Ошибка: не защищаться от повторных уведомлений. Исправление: сделайте обработку идемпотентной. Повторный вебхук с тем же идентификатором должен обновить запись, а не создать второй заказ, чек или отгрузку.
Ошибка: запускать оплату без теста возврата. Исправление: до выхода в продакшн проведите отмену, полный возврат и частичный возврат, если вы допускаете его для своих товаров или услуг. Проверьте статус заказа, кассовое действие и запись в реестре.
Ошибка: не сверять выплаты. Исправление: регулярно сопоставляйте заказы, успешные платежи, возвраты и реестры выплат. Расхождение разбирайте по идентификатору платежа, а не только по сумме.
Ошибка: не проверять мобильный путь. Исправление: откройте форму на iOS и Android, пройдите подтверждение в банковском приложении и возврат на сайт. Покупатель должен увидеть понятное сообщение о том, что статус еще проверяется, если сервер не получил финальное подтверждение.
Закажите аудит платежного контура, если запускаете оплату впервые, меняете провайдера или уже теряете заказы из-за расхождений. Команда Интернет Касса разберет путь платежа от формы до заказа и чека, проверит сценарии вебхуков и резервного запроса API, поможет определить требования к кассе и составит перечень сквозных тестов.
На выходе вы получите схему интеграции с зонами ответственности провайдера, разработчика и кассового контура, а также чеклист запуска и сверки. Обратитесь в Интернет Касса, чтобы обсудить аудит, подбор платежного решения или проверку готовой интеграции.
Это технический слой, который связывает форму оплаты на сайте с платежным провайдером и вашей системой заказов. Он создает платеж, передает данные по защищенному сценарию и сообщает серверу статус операции.
Нет, отдельный шлюз подключать не обязательно. Магазину нужно платежное решение — банка, агрегатора или другого провайдера — которое передает серверные статусы платежей и позволяет связать оплату с заказом.
Эквайринг обеспечивает прием оплаты картой, а шлюз реализует технический обмен: создание платежа, передачу статусов и обработку уведомлений. У банка или агрегатора эти функции могут входить в один продукт, но при интеграции их нужно проверять отдельно.
Проведите в тестовом контуре оплату, отказ, отмену, полный или частичный возврат, повторный вебхук и задержку уведомления. Решение подходит, если платеж, заказ, чек и запись в реестре выплат сопоставляются по идентификаторам без ручного поиска.
Да, до запуска зафиксируйте, кто передает состав заказа в ККТ, по какому событию формируется чек и как оформляется возврат. Шлюз не заменяет онлайн-кассу и не формирует фискальный чек сам по себе.