Webhooks vs Polling: кто виноват, когда платеж «завис» в чужом стейте

Webhooks vs Polling: кто виноват, когда платеж «завис» в чужом стейте

В платежной интеграции это не спор архитекторов, а выбор между «нам прилетает событие» и «мы сами долбим API, пока не отпустит». Webhooks дают почти реальное время, но только если у вас есть идемпотентность, дедупликация и нормальная обработка ретраев. Иначе один дубль превращает подтверждение в двойное списание. Документация — это ложь, логи — истина.

Polling выглядит как костыль, и часто им и является. Зато он предсказуем: вы сами контролируете частоту, окна, таймауты и можете пережить падение чужого webhook-эндпоинта без паники. Но у polling есть любимая болезнь — консистентность с лагом. Клиент уже оплатил, а ваш бэк ещё играет в «подожди, сейчас проверим». UX плачет, саппорт горит 🔥

Нормальная схема почти всегда гибридная: webhooks — для быстрого изменения стейта, polling — для сверки спорных/подвисших операций и восстановления после провалов доставки. Обязательные правила:
— входящий webhook должен быть идемпотентным;
— каждое событие храните как отдельный факт, а не «последний статус»;
— ретраи без backoff’а — это DDoS на самого себя;
— если статус критичен, подтверждайте его повторной проверкой по API.

Главная ошибка — верить одному каналу доставки. Webhook может потеряться, polling может опоздать, а ваш мерчант забанен без объяснения причин в самый неудобный момент. Поэтому строите стейт-машину, а не набор if’ов.

Идемпотентность или смерть: webhooks для скорости, polling для страховки, а истина — только в журнале событий.