Клиент нажал «Оплатить», деньги списались, а статус заказа завис. Разбираем архитектуру приёма платежей: вебхуки, синхронизация систем, защита от дублей и почему конверсия падает раньше, чем вы это замечаете.
Клиент нажал «Оплатить», деньги списались, а статус заказа не обновился. Вебхук не пришёл, пришёл трижды или пришёл с несовпадающей подписью. Покупатель ждёт подтверждения, а вы разбираетесь, что пошло не так — и теряете деньги прямо сейчас. Для бизнеса, который принимает платежи онлайн, каждый такой сбой — это упущенная выручка и недовольный клиент.
Приём оплаты — это не один HTTP-запрос, а цепочка взаимодействий между вашим сайтом, платёжным сервисом и банками. Если в любом звене что-то идёт не так, платёж зависает, а заказ теряется.
Вот как выглядит стандартный сценарий:
order_id. Этот идентификатор связывает заказ с платежом во всех последующих запросах.order_id, описание. Сервис возвращает свой идентификатор (payment_id) и ссылку на платёжную страницу или виджет.SUCCESS и готовит вебхук-уведомление. При двухстадийной модели деньги сначала холдируются, при одностадийной — списываются сразу.Документация платёжных сервисов описывает счастливый путь. Но на практике вебхук может прийти трижды, не прийти вовсе или прийти с подписью, которая не совпадает с ожидаемой.
Никогда не обновляйте статус заказа без проверки подписи вебхука. Злоумышленник может отправить поддельный запрос на ваш URL и «подтвердить» несуществующий платёж. Алгоритм проверки описан в документации вашего провайдера — как правило, это HMAC-SHA256 от тела запроса с секретным ключом.
Сервисы гарантируют доставку вебхука, но не гарантируют, что он придёт ровно один раз. Правильная архитектура: перед обновлением статуса проверяйте, не был ли этот payment_id уже обработан. Если статус уже PAID — возвращайте 200 OK и не трогайте заказ.
Редирект после оплаты — это UX-подтверждение для пользователя, но не основание для обновления статуса. Статус должен меняться только по вебхуку. Если клиент закрыл вкладку, вебхук всё равно придёт — и заказ обновится корректно.
Настройте периодическую сверку: раз в несколько минут запрашивайте статус платежей в статусе PENDING через API провайдера. Не полагайтесь только на push-уведомления.
Это два разных процесса. Платёж прошёл — деньги на счету провайдера. Но заказ в вашей CMS обновится только тогда, когда вебхук будет корректно обработан. Если синхронизация сломалась, возникает классическая ситуация: деньги списаны, заказ в статусе «Ожидает оплаты», клиент звонит в поддержку.
Чтобы этого избежать, обрабатывайте вебхуки асинхронно через очередь задач (RabbitMQ, Redis, SQS): сразу отвечайте провайдеру 200 OK, а обновление CRM, склада и службы доставки выполняйте воркером. Если одна из систем временно недоступна, задача останется в очереди и будет повторена — уведомление не потеряется.
Каждый отказ платежа — это не просто технический сбой. Это клиент, который не завершил покупку. Для бизнесов, которые принимают рубли через СБП, особенно актуальна ситуация, когда один провайдер начинает давать сбои: конверсия падает, клиенты уходят, а вы узнаёте об этом только из жалоб.
Именно поэтому профессиональные платёжные решения строятся не на одном провайдере, а на каскаде: если первый отказал — запрос автоматически уходит к следующему. Такой подход используют платформы-оркестраторы, в частности MultiFlow — сервис маршрутизирует каждый платёж через пул провайдеров, что снижает количество отказов и поддерживает стабильную конверсию. Это особенно критично для крипто-обменников и P2P-бизнесов, где каждый отказ на приёме рублей напрямую бьёт по марже.
PCI DSS — международный стандарт безопасности для всех, кто работает с карточными данными. Требования зависят от объёма транзакций и способа приёма платежей:
Практический вывод: большинство бизнесов работает через провайдера с редиректом или виджетом — это и проще технически, и безопаснее юридически. Данные карт не проходят через ваш сервер, и полная сертификация не нужна.
Надёжный приём платежей — это не только правильно написанный обработчик вебхука. Это архитектурное решение: идемпотентная обработка уведомлений, проверка подписи, асинхронная синхронизация с внутренними системами и регулярная сверка статусов. Если хотя бы одно звено выпадает, вы теряете деньги молча.
Если ваш бизнес принимает рубли через СБП и вы сталкиваетесь с нестабильностью приёма или высоким процентом отказов — стоит посмотреть в сторону платформ с каскадной маршрутизацией. MultiFlow позволяет подключиться к пулу провайдеров, принимать рублёвые платежи с фолбэком при отказе и выводить средства в том числе в USDT — без необходимости выстраивать собственную инфраструктуру с нуля.
Материал подготовлен с помощью ИИ на основе публикации habr.com.
Без российского счёта, без серых схем — только официальная инфраструктура.
Написать в Telegram →