Прием платежей для интернет-магазина: схема запуска

1. От корзины к платежу

До создания платежа магазин проверяет наличие товара, итоговую цену, доставку, скидки и валюту. Заказ получает постоянный идентификатор, а сумма передается в платежную инфраструктуру на серверной стороне. Описание назначения должно быть понятным и соответствовать покупке.

На checkout полезно показать итог, продавца, контакты поддержки и ссылки на условия. Выбор СБП, карты или платежной ссылки зависит от аудитории и фактически одобренных методов. Карточный эквайринг доступен только там, где он поддержан и согласован.

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

2. QR, ссылка и возврат покупателя

Для СБП динамический QR или ссылка формируются для конкретного заказа. После перехода в банковское приложение покупатель возвращается в магазин, однако сам возврат в браузер не подтверждает оплату. Источником результата служит серверный статус.

Страница результата должна корректно обрабатывать задержку: показывать ожидание, запрашивать статус безопасно и не создавать новый заказ без явного действия. Если покупатель закрыл вкладку, webhook все равно позволяет обновить заказ.

• не используйте универсальный QR для автоматизированной корзины;
• разделяйте return URL и подтверждение оплаты;
• покажите покупателю номер заказа;
• предусмотрите повторную проверку статуса.

3. Заказ, склад и доставка

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

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

• определите финальный статус оплаты;
• защитите обработчик от повторного выполнения;
• логируйте смену статуса заказа;
• разделяйте заказ и платежные попытки.

4. Возвраты, сверка и запуск

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

WHITECAPITAL помогает построить платежный контур с СБП, динамическим QR, платежными ссылками, API и операционными статусами в рамках одобренной инфраструктуры. Доступность карт, тарифы и условия определяются после проверки.

• опубликуйте актуальную политику возврата;
• проведите тестовую сверку;
• подготовьте инструкции поддержке;
• наблюдайте ошибки и незавершенные оплаты.

Вопросы и ответы