Webhooks vs polling: кто первым врёт вашему биллингу про статус платежа

Webhooks vs polling: кто первым врёт вашему биллингу про статус платежа

Провайдеры любят рисовать вебхуки как «реал-тайм магию». На практике это просто доставка события, которая может прийти позже, дважды или не прийти вовсе. Polling, наоборот, тупой и дорогой, но хотя бы честно показывает: пока не спросил — не знаешь. И вот тут начинается любимый цирк интеграций: заказ уже отдан, а стейт ещё в pending.

Если строите платежный контур, держите оба канала:
— webhook как триггер для быстрого обновления
— polling как страховку для расхождений, ретраев и пропущенных событий
— idempotency key и дедупликация по event_id, иначе словите двойную обработку
— отдельный reconciliation-job, который сверяет локальный стейт с провайдером и чинит мусор в очереди

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

Постройте state machine с явными переходами: created → authorized → captured → settled → failed. Всё, что не укладывается в схему, уходит в quarantine и не ломает checkout. Идемпотентность или смерть.