Клиент нажал «Оплатить», деньги списались, а статус заказа не обновился. Вебхук не пришёл, пришёл трижды или пришёл с несовпадающей подписью. Покупатель ждёт подтверждения, менеджер не видит заказа, а вы разбираетесь, что пошло не так.
В документации платёжных сервисов обычно описывают только идеальный сценарий. А что делать, когда запросы дублируются, клиент закрыл страницу до редиректа или платёж завис в статусе PENDING? В статье — об архитектуре приёма платежей: от создания заказа до фискального чека. С примерами кода, схемами и разбором граничных случаев, которые не описаны в документации.
Интеграция оплаты на сайте для интернет-магазина через API или CMS-модуль — задача с чёткой документацией: создать заказ, отправить запрос, обработать вебхук, обновить статус. С точки зрения разработки — ряд штатных HTTP-вызовов. Но в документации провайдеров редко описывают, что делать, когда вебхук приходит трижды, клиент закрыл страницу до редиректа, а подпись уведомления не совпадает с ожидаемой.
В статье — пошаговый разбор архитектуры приёма платежей в интернет-магазине: от создания заказа до фискального чека. Рассматриваем, как хранить order_id и payment_id, почему проверка подписи — единственная защита от поддельных уведомлений и как спроектировать обработку вебхука так, чтобы повторные запросы не обновляли статус дважды. С примерами кода, схемами и разбором граничных сценариев, о которых молчит документация.
