Комментарии 1
Спасибо за разбор именно грязных мест, а не только happy path из документации провайдера.
Неторопясь подключаю сейчас оплату не в интернет-магазине, а в SaaS с подпиской, но архитектура у нас та же самая.
Уже зафиксировали у себя вот что:
Доступ выдаём только по webhook. Страница “успех” и return URL — это просто экран для пользователя, а не доказательство оплаты. Пользователь может закрыть вкладку, зависнуть на редиректе или вообще не дойти до страницы, а платёж при этом уже пройдёт.
Используем два идентификатора: свой order_id до создания платежа и payment_id провайдера. Когда приходит уведомление, искать заказ лучше по payment_id , потому что это стабильная точка привязки.
Делаем идемпотентность. Если один и тот же webhook придёт дважды, подписка не должна продлиться два раза, даже если у нас два API-воркера или провайдер отправил повтор.
Проверяем подпись уведомления. Это базовая защита от поддельного POST, который иначе мог бы случайно или намеренно включить платный доступ.
Карты не идут через наш сервер. Используем редирект или виджет, чтобы не трогать чувствительные данные и не усложнять PCI-часть.
Отдельно спасибо за то, что вы развели сам факт оплаты и внутреннее обновление доступа.
Это важное различие: деньги могли уже списаться, но у нас в кабинете статус ещё не обновился, пока не пришло и не обработалось серверное уведомление.
То, что обычно пропускают в туториалах, но важно в реальности:
PENDING — это нормальный промежуточный статус, а не ошибка.
Повторные уведомления — это ожидаемое поведение, а не сбой.
Если у нас на стороне сервера ошибка, нельзя просто отвечать 200 OK , иначе провайдер решит, что всё уже принято, и повторно событие может не прислать.
Получается что правильная и логичная схема такая: пользователь платит, провайдер присылает нам подтверждение на сервер, мы проверяем, что оно настоящее, и только потом выдаём доступ.
Как подключить оплату на сайт интернет-магазина: полное руководство по выбору и настройке