Ключевые темы
Связанные публичные страницы
Если нужен не только разбор, а страница продукта, API или операционного сценария, начните с этих разделов VPOS.am.
Payment session должна создаваться на backend
Frontend может запускать checkout, но сумму, валюту и финальный статус должен контролировать server-side слой.
Для кастомного сайта, Laravel/Yii2 backend, React storefront или мобильного приложения безопасный flow начинается на server-side. Клиентский интерфейс может собрать корзину и отправить намерение оплаты, но backend должен рассчитать сумму, валюту, order id и создать payment session.
Если frontend сам решает сумму или считает платеж успешным после redirect, возникают риски подмены параметров, дублей заказов и потерянных successful оплат. Payment session должна хранить внутренний id, merchant order id, amount, currency, status и срок жизни.
- создавать payment session только после backend validation;
- фиксировать amount и currency до checkout;
- использовать hosted checkout или controlled redirect;
- не считать redirect финальным статусом оплаты.
Idempotency защищает от дублей заказов и платежей
Повторный запрос создания платежа должен возвращать тот же результат или контролируемую новую попытку.
В реальном checkout пользователь нажимает кнопку дважды, мобильная сеть повторяет запрос, браузер перезагружает страницу, а webhook может прийти несколько раз. Без idempotency каждая такая ситуация может создать дубль payment attempt или заказа.
Idempotency key лучше связывать с операцией: create payment session, process webhook, create fiscal receipt, update CRM. Тогда retry возвращает предсказуемый результат, а audit trail показывает, что произошло.
- уникальный ключ для create payment session;
- повтор webhook не меняет финальный статус назад;
- CRM/ERP update должен быть повторяемым;
- ручные исправления должны попадать в audit log.
Webhooks, status checks и синхронизация с бизнес-системами
Платежный backend должен принять финальное событие, проверить его и затем доставить нормализованный статус во внутренние системы.
Webhook нельзя обрабатывать как обычную форму. Нужно проверить подпись или выполнить status check у провайдера, сопоставить provider reference, amount, currency и order id, а затем провести разрешенный переход статуса.
После этого нормализованное событие можно доставлять в CRM, ERP, фискализацию, уведомления и сверку. Если одна из downstream-систем временно недоступна, платежный статус должен сохраниться, а интеграция должна повторить доставку.
- проверять provider reference, amount и currency;
- использовать state machine для переходов статусов;
- доставлять события в очереди с retry;
- отделять payment status от fiscal и delivery status.
FAQ
Можно ли создать payment session с frontend?
Frontend может инициировать запрос, но session должен создавать backend после проверки заказа, суммы, валюты и прав доступа. Иначе параметры оплаты легко подменить.
Нужен ли webhook, если есть success page?
Да. Success page показывает результат клиенту, но финальный бизнес-статус лучше ставить после webhook или server-side status check.
Что делать, если CRM недоступна после успешной оплаты?
Сохранить paid-статус во внутренней payment session, поставить CRM update в retry и показать исключение оператору только если повторные попытки не прошли.
