Что происходит после нажатия кнопки оплаты
Платеж картой - это цепочка между сайтом, банком, платежной платформой, процессингом и backend магазина.
Для покупателя card payment выглядит как один экран оплаты. Для бизнеса это цепочка событий: заказ создан, платеж зарегистрирован, клиент прошел платежную страницу, провайдер обработал результат, backend проверил статус и обновил заказ.
Официальные страницы банков подтверждают базовый набор: Evocabank описывает прием ArCa, Visa и Mastercard через V-POS с 3D Secure, AEB публикует комиссии отдельно для ArCa, локальных Visa/Mastercard и международных карт, Inecobank также разделяет тарифы по card schemes. Поэтому архитектура должна учитывать не только "успешно/неуспешно", но и тип карты, валюту, отчетность и возвраты.
- создать заказ и payment attempt;
- передать сумму, валюту и order id;
- получить внешний payment id;
- проверить финальный статус;
- обновить CRM/ERP только после проверки.
Зачем нужен 3D Secure и server-side verification
Платежная безопасность строится на стороне провайдера и backend, а не на доверии к frontend redirect.
3D Secure помогает подтвердить cardholder action; Evocabank и Inecobank прямо указывают 3D Secure/SecureCode в vPOS-контексте. Но бизнесу все равно нужно корректно обработать финальный результат платежа. Redirect на success page не является достаточным доказательством оплаты.
Server-side verification нужна, чтобы проверить payment id, сумму, валюту, order id и допустимый переход статуса. Это защищает от ошибок, повторных callbacks и несогласованности между сайтом и CRM.
- не доверять query parameters на success URL;
- проверять сумму и валюту;
- обрабатывать pending/failed статусы;
- логировать provider response в безопасном объеме.
Возвраты и сверка должны быть частью дизайна
Card payments не заканчиваются successful payment: бизнесу нужны refunds, reports и reconciliation.
После запуска онлайн-оплаты быстро появляются операционные вопросы: как оформить возврат, как сверить банковский отчет, как объяснить клиенту failed payment и как найти платеж по обращению поддержки.
Если эти сценарии заложить заранее, платежная интеграция становится управляемой: payment id связан с order id, refund привязан к исходному платежу, а отчет банка можно сверить с CRM/ERP. Если нет - команда будет разбирать операции вручную и исправлять статусы после каждого спорного случая.
- отдельный статус refund/refunded;
- связь возврата с исходным payment id;
- daily reconciliation report;
- correlation id для поддержки;
- история всех payment events.
FAQ
Можно ли принимать ArCa и международные карты через один checkout?
Часто да, если это поддерживает выбранный банк или платежный провайдер. Конкретные карты и условия нужно проверять у провайдера.
Почему нельзя ставить заказ paid после success redirect?
Redirect может быть неполным или подделанным с точки зрения бизнес-логики. Paid должен выставляться после server-side проверки или trusted webhook.
Нужна ли сверка, если все статусы приходят автоматически?
Да. Автоматические статусы снижают ручную работу, но финансовая сверка с отчетами провайдера остается важной частью контроля.
Источники
- Evocabank - V-POS TerminalОфициальное описание приема ArCa, Visa, Mastercard и 3D Secure через V-POS.
- Armeconombank - VPOS tariffsОфициальные тарифы по ArCa, локальным Visa/Mastercard и международным картам.
- Inecobank - VPOS tariffs and 3D SecureОфициальная страница vPOS с тарифами и упоминанием 3D Secure/SecureCode.
