Платёж через нашу форму

Большинству мерчантов невыгодно проходить сертификацию PCI DSS ради того, чтобы собирать карты самостоятельно. Для них есть второй способ: мерчант создаёт платёж без карточных данных, получает ссылку на нашу платёжную страницу и отправляет туда плательщика. Карту принимаем мы.

Чем отличается от базового флоу

Отличия сосредоточены в начале. Всё, что происходит после того, как карта оказалась у нас, совпадает с платежом server-to-server начиная с выбора гейта: антифрод, каскад, поход в банк, 3DS, переспрос статуса, финализация, колбек.

	Server-to-server	Через нашу форму
Кто собирает карту	Мерчант	Мы
Что создаётся первым запросом	Платёж с картой	Платёж без карты
Что получает мерчант в ответ	Ссылку на 3DS	Ссылку на нашу форму
Куда уходит карта	Из системы мерчанта в PCI-шлюз	Из браузера плательщика в PCI-шлюз
Нужна ли мерчанту сертификация	Да	Нет

Как это выглядит целиком

Шаг за шагом

1. Мерчант создаёт платёж

Публичное описание запроса — Create payment form. Запрос идёт на обычный публичный шлюз, а не на PCI-домен: карточных данных в нём нет. Мерчант передаёт сумму, валюту, идентификатор своего заказа и данные плательщика, которые у него есть.

2. Ядро создаёт транзакцию и ссылку на форму

Транзакция заводится в статусе «новая» и сразу помечается как оплачиваемая через форму. Гейт на этом шаге ещё не выбран: неизвестно, какой картой заплатят, а от этого зависит маршрут. Ядро возвращает мерчанту адрес нашей страницы, привязанный к конкретной транзакции.

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

3. Плательщик открывает форму

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

4. Плательщик вводит карту

Данные карты уходят не на тот адрес, с которого форма получала остальные данные, а напрямую в PCI-шлюз. Это принципиально: страница отдаётся из обычного контура, а карта отправляется в защищённый, минуя и мерчанта, и наш обычный шлюз.

PCI-шлюз меняет карту на токены точно так же, как в базовом флоу, и передаёт платёж в ядро.

5. Дальше — как обычно

Ядро дописывает в транзакцию данные карты и браузера плательщика, отдаёт платёж антифроду, выбирает гейт и отправляет операцию в банк. С этого момента путь полностью совпадает с базовым флоу, включая 3DS, переспрос статуса и уведомление мерчанта.

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

Что это меняет для разработчика

Транзакция живёт дольше. Между созданием и походом в банк проходит время, в течение которого платёж существует без гейта и без карты. Значительная часть транзакций в состоянии «новая» — это просто незаполненные формы.

Отказ возможен до того, как плательщик что-то сделал. Если каскад не найдёт гейт уже на этапе показа формы, плательщик увидит ошибку вместо полей ввода.

Дизайн формы — часть продукта. Внешний вид настраивается под мерчанта, и изменения в форме затрагивают конверсию напрямую, поэтому правки там требуют большей осторожности, чем кажется по объёму кода.

Где ломается чаще всего

Симптом	Обычная причина
Мерчант получил ссылку, плательщик видит ошибку	Не нашлось подходящего гейта или сработал лимит
Форма открылась, но карта не принимается	Проблема на стороне PCI-шлюза или токенизации
Транзакция закрылась отказом без действий плательщика	Сработал таймаут формы
Плательщик оплатил, но вернулся не туда	Неверный адрес возврата в настройках мерчанта

Куда дальше

• Платёж картой server-to-server — общая часть пути.
• Статусы и стадии — как выглядит форма, которую не заполнили.
• Почему шлюзов несколько — почему карта с нашей же страницы уходит на другой домен.