Платёжный шлюз
Платёжный шлюз — техническая прослойка между сайтом и банком-эквайером: принимает данные карты на своей защищённой странице, передаёт запрос на авторизацию и возвращает магазину статус платежа.
Что делает платёжный шлюз и чего он не делает
Платёжный шлюз (payment gateway) — программный посредник между интернет-магазином и банковской инфраструктурой. Задача у него узкая и техническая: безопасно собрать платёжные данные, довести запрос до банка-эквайера и вернуть магазину однозначный статус операции.
Цепочка онлайн-платежа выглядит так: покупатель на странице оплаты, затем шлюз, затем банк-эквайер, платёжная система и банк-эмитент — и обратно тем же маршрутом. Шлюз стоит на первом участке и берёт на себя самую неприятную часть работы: обращение с номером карты. Магазин не видит карточных данных, не хранит их и не попадает под полный объём требований PCI DSS, потому что покупатель вводит реквизиты в поле, которое принадлежит шлюзу.
Чего шлюз не делает: он не открывает расчётный счёт, не заключает за вас договор с платёжной системой и в классической схеме не принимает деньги покупателей себе. Договор интернет-эквайринга магазин подписывает с банком, банк же и перечисляет выручку. Шлюз получает плату за функциональность и трафик, а не долю с оборота.
Как устроен платёж технически
Интеграция почти всегда строится по одной схеме, независимо от провайдера.
- Создание платежа. Бэкенд магазина вызывает метод API: сумма, валюта, описание, номер заказа, адрес возврата. В заголовке передаётся ключ идемпотентности — уникальная строка, по которой повторный запрос не создаёт второй платёж. Без неё двойное нажатие кнопки или ретрай после таймаута легко порождают дубль.
- Ввод данных. В ответ приходит ссылка на форму оплаты или токен для встроенного виджета. Покупатель вводит карту на стороне шлюза. Альтернатива карте — оплата по QR через СБП или сохранённый платёжный токен, если карта уже привязана.
- Аутентификация. Шлюз инициирует 3-D Secure второй версии. Часть операций проходит без единого действия покупателя (frictionless flow) на основе накопленных данных о поведении и устройстве, остальные требуют подтверждения в приложении банка. При пройденной аутентификации ответственность за оспоренную операцию смещается на эмитента.
- Авторизация и подтверждение. Эквайер получает разрешение эмитента, сумма блокируется. Дальше либо одностадийная схема со списанием сразу, либо двухстадийная: сначала холд, затем capture на фактическую сумму — удобно, когда часть заказа собрать не удалось.
- Вебхук. Финальный статус шлюз присылает на ваш URL. Это единственный надёжный источник правды: покупатель может закрыть вкладку до редиректа, а деньги при этом спишутся. Уведомление проверяется по подписи, обрабатывается идемпотентно и подтверждается кодом 200, иначе провайдер будет повторять доставку по своему расписанию.
Рядом с картами шлюз обычно закрывает и остальные способы оплаты: СБП с генерацией QR в формате EMVCo, платёжные ссылки, рекуррентные списания по токену, рассрочку. Для магазина это один API вместо нескольких разных интеграций и один формат статусов вместо зоопарка.
Шлюз, агрегатор и процессинг банка: кто за что отвечает
| Признак | Платёжный шлюз | Платёжный агрегатор |
|---|---|---|
| Роль | Техническая маршрутизация запросов | Приём денег и последующая выплата мерчанту |
| Куда поступают деньги | От эквайера сразу на счёт магазина | Сначала на счёт агрегатора, затем магазину |
| Договоры | Отдельно с банком, отдельно с провайдером | Один договор с агрегатором |
| Кто проверяет магазин | Банк-эквайер при подключении | Комплаенс агрегатора |
| Оплата услуги | Чаще фиксированная плата или цена за транзакцию | Процент с оборота |
| Скорость запуска | Дольше: нужна проверка банка | Быстрее: подключение за день-два |
На практике граница размыта: крупные провайдеры совмещают обе роли и продают их одним продуктом. Понять, что именно вам предлагают, помогает один вопрос — на чей счёт поступают деньги покупателя и с кем у вас договор. Роль посредника, который принимает выручку на себя, разобрана в статье про платёжный агрегатор. Третий вариант — прямой процессинг банка без внешнего шлюза: ставка ниже, но интеграция, мониторинг и поддержка ложатся на вашу команду.
Что проверить при выборе и интеграции
Ставки сравнивают все, а ломается интеграция обычно из-за другого. Короткий список, который экономит недели:
- тестовый контур с наборами карт под каждый сценарий: успех, отказ эмитента, провал 3-D Secure, таймаут;
- идемпотентность в методах создания платежа и возврата, иначе ретраи превращаются в двойные списания;
- подписанные вебхуки и понятная политика повторной доставки;
- фискализация по 54-ФЗ: чек отправляет провайдер или это ваша задача — сверяйтесь с актуальной редакцией закона и текстом договора;
- реестры и сверка: выгрузка операций в машиночитаемом виде, без неё бухгалтерия сводит выписку руками;
- возвраты через API, включая частичные, и понятные сроки зачисления покупателю.
Отдельно стоит проверить, что происходит при сбое: сохраняется ли очередь платежей, как провайдер уведомляет об аварии, есть ли резервный маршрут на другого эквайера. Это то, что видно только в инциденте, поэтому спрашивать нужно до подключения.
Если сайта нет вовсе, шлюз часто оказывается избыточным: выставить счёт можно готовой платёжной ссылкой из личного кабинета банка и отправить её в мессенджере. Для офлайн-точки тот же результат даёт печатный код на кассе, собранный в генераторе QR-кодов.
Частые вопросы
Чем шлюз отличается от эквайринга?
Эквайринг — банковская услуга: договор, по которому банк принимает карточные платежи в пользу магазина и зачисляет выручку на счёт. Шлюз — программная часть, доставляющая запрос от сайта до банка и обратно. Без договора эквайринга шлюз бесполезен, без шлюза эквайринг придётся интегрировать напрямую собственными силами разработки.
Хранит ли шлюз данные карты?
Полный номер карты хранится только у сертифицированных по PCI DSS провайдеров и в зашифрованном виде. Магазину возвращается токен и маска вида 5100 XX XXXX 1234. Повторные списания делаются по токену — этого достаточно для подписок, и при утечке базы магазина карточные данные не пострадают, потому что их там просто нет.
Почему платёж завис в статусе ожидания?
Типичные причины: покупатель не завершил подтверждение 3-D Secure, закрыл вкладку до редиректа или у платежа двухстадийная схема и не сделан capture. Статус нужно уточнять запросом к API по идентификатору платежа, а не по факту возврата на сайт. Незакрытые холды банк-эмитент снимает сам по своему регламенту.
Можно ли подключить два шлюза одновременно?
Можно, и в крупной рознице так и делают: один провайдер основной, второй резервный. Это страховка от сбоя процессинга и способ направлять платежи туда, где выше проходимость. Плата за такую схему — двойная интеграция, две сверки и логика переключения, поэтому небольшому магазину она обычно не окупается.
Нужен ли шлюз, если оплата идёт только по СБП?
Не обязательно. QR-код и ссылку по СБП многие банки выдают прямо в личном кабинете, а для витрины хватает API самого банка. Шлюз приобретает смысл, когда способов оплаты несколько, нужны единые статусы и общая логика возвратов, либо когда вы хотите переключаться между банками без переписывания кода.