Как подключить онлайн-оплату на сайт: эквайринг, агрегатор или платёжный шлюз

Для большинства сайтов проще всего подключить онлайн-оплату через платёжный агрегатор: один договор, много способов оплаты, готовая платёжная страница и чеки по 54-ФЗ. Прямой интернет-эквайринг банка выгоднее по комиссии при больших оборотах, а собственный платёжный шлюз с несколькими провайдерами нужен крупным проектам, которым важны отказоустойчивость и маршрутизация платежей.

Разберём варианты, как устроена интеграция и что проверить перед запуском.

Какие варианты приёма платежей бывают?

Принимать платежи на сайте можно через платёжный агрегатор, напрямую через интернет-эквайринг банка или через собственный слой поверх нескольких провайдеров. Они различаются числом договоров, набором способов оплаты, комиссией и тем, какую часть работы вы берёте на себя.

Вариант	Как работает	Кому подходит	Что учесть
Платёжный агрегатор	Один договор, агрегатор подключает карты, СБП, кошельки	Малый и средний бизнес, быстрый старт	Комиссия обычно выше, чем у прямого эквайринга
Интернет-эквайринг банка	Договор с банком, приём карт и СБП	Стабильные обороты, выгодная ставка	Меньше способов оплаты, иногда сложнее интеграция
Несколько провайдеров	Свой слой маршрутизации между провайдерами	Крупные проекты с большим оборотом	Разработка и поддержка своего платёжного контура

Конкретные тарифы и условия меняются, поэтому их стоит сравнивать на момент подключения и с учётом вашего оборота и среднего чека.

Как устроена интеграция онлайн-оплаты?

Интеграция устроена одинаково у большинства провайдеров: сервер сайта создаёт платёж через API, покупатель оплачивает на платёжной странице провайдера или в виджете, а результат приходит на сервер уведомлением — вебхуком. Статус заказа меняется только по уведомлению или проверке через API, а не по возврату пользователя на сайт.

Шаги интеграции:

1. Сервер создаёт платёж с суммой, описанием заказа и ключом идемпотентности.
2. Покупатель переходит на платёжную страницу или видит встроенную форму.
3. Провайдер присылает вебхук об успешной или неуспешной оплате.
4. Сервер проверяет подпись, обновляет заказ и формирует чек.
5. Покупатель возвращается на сайт и видит актуальный статус.

Почему так важны ключи идемпотентности и правильная обработка вебхуков, мы подробно разбирали в статье идемпотентность платежей и вебхуков.

Фото: Unsplash

Какие способы оплаты подключить?

Подключать стоит те способы, которыми реально платит ваша аудитория: банковские карты, Систему быстрых платежей и, в зависимости от ниши, оплату по счёту для юрлиц, рассрочку или «оплату частями». Каждый лишний способ — это настройка и поддержка, а отсутствие нужного — брошенные корзины.

Что обычно нужно:

• банковские карты — базовый способ для любого магазина;
• СБП — оплата по QR-коду или через приложение банка, часто с более низкой комиссией;
• оплата по счёту — для B2B-продаж;
• рассрочка и оплата частями — для дорогих товаров;
• сохранённые карты и рекуррентные платежи — для подписок.

Чеки и 54-ФЗ

При приёме оплаты онлайн по закону 54-ФЗ продавец обязан выдать покупателю электронный чек через онлайн-кассу. Многие агрегаторы предлагают облачную кассу и формируют чеки сами — это заметно упрощает запуск. Для чека нужны данные о позициях заказа, ставке НДС и признаке расчёта, поэтому их стоит продумать при проектировании каталога.

Что проверить перед запуском оплаты?

Перед запуском проверяют все сценарии, а не только успешную оплату: отказ банка, повторное уведомление, возврат, частичный возврат и ситуацию, когда покупатель закрыл страницу, не дождавшись возврата на сайт. Большинство проблем с оплатой обнаруживаются именно в этих ветках.

Чек-лист:

1. Успешная оплата — заказ оплачен, чек сформирован, письмо отправлено один раз.
2. Отказ — заказ остаётся неоплаченным, покупатель может повторить оплату.
3. Повторный вебхук — статус не меняется повторно, письмо не дублируется.
4. Полный и частичный возврат — корректные статусы и чеки возврата.
5. Покупатель закрыл вкладку — статус всё равно обновился по вебхуку.
6. Тестовые и боевые ключи API разделены, секреты не попали в репозиторий.

Отдельно — данные карт: при оплате на странице провайдера или в его виджете номера карт не проходят через ваш сервер, что сильно снижает требования к безопасности. Общие правила защиты данных — в статье персональные данные на сайте.

Когда нужен собственный платёжный шлюз?

Собственный слой над несколькими провайдерами нужен, когда оборот большой и даже небольшая разница в комиссии заметна, когда нельзя допустить остановку продаж из-за сбоя одного провайдера или когда разные способы оплаты выгоднее проводить через разных провайдеров. Для большинства проектов это избыточно.

Что появляется в таком слое:

• маршрутизация платежей между провайдерами по правилам — сумма, способ, доступность;
• автоматическое переключение при сбое основного провайдера;
• единая модель платежей и статусов поверх разных API;
• сверка с каждым провайдером и единая отчётность.

Коротко

• Для быстрого старта подойдёт платёжный агрегатор: один договор, много способов, чеки по 54-ФЗ.
• Прямой эквайринг банка выгоднее при стабильных оборотах; несколько провайдеров — для крупных проектов.
• Статус заказа меняйте по вебхуку или проверке через API, с ключами идемпотентности.
• Подключайте способы оплаты, которыми реально платит ваша аудитория, включая СБП.
• Перед запуском проверьте отказы, повторы, возвраты и закрытую вкладку, а не только успешную оплату.