Webhooks против polling: где умирает консистентность стейтов в платежах

Webhooks против polling: где умирает консистентность стейтов в платежах

Webhook — это не магия, а чужой POST в ваш хрупкий бекенд. Polling — не «надёжный запасной план», а дорогой способ самому себе устроить DDoS на API провайдера. В платежах оба подхода ломаются не на словах, а на граничных кейсах: дубль события, потерянный callback, гонка между авторизацией и сеттлментом.

Если у вас нет идемпотентности, webhook превращается в генератор двойных списаний. Если нет нормального storage state machine, polling будет врать про «успешно», пока платёж уже отменён или завис в холде. Документация тут обычно врёт по умолчанию: порядок событий, задержки доставки, ретраи — всё это выясняется по логам. Документация — это ложь, логи — истина.

Нормальная схема такая:
— входящий webhook валидируете по подписи и кладёте в очередь, а не обрабатываете в лоб;
— состояние платежа обновляете только через переходы, а не через «перезаписать как пришло»;
— polling оставляете как reconciliation, а не как основной источник правды;
— каждое событие дедуплицируете по event_id и merchant_reference.

Самый токсичный костыль — смешать оба канала без приоритета. Тогда webhook говорит «paid», polling через минуту говорит «pending», а саппорт потом рисует вам ручные компенсации. Идемпотентность или смерть.

Вывод простой: webhook — для доставки сигнала, polling — для сверки реальности. Если у вас один и тот же платёж может жить в двух версиях истины, архитектура уже трещит.