Webhooks vs Polling: консистентность стейтов, пока ваш API не врёт

Webhooks vs Polling: консистентность стейтов, пока ваш API не врёт

Polling — это когда вы вежливо долбите провайдера вопросом «ну что, прошло?». Webhooks — когда провайдер обещает сам принести событие. На бумаге второе выглядит как зрелая архитектура, на практике — как очередь из дублей, таймаутов и потерянных доставок.

Если коротко: polling терпит, webhook обязателен к защите. Для платежей держите оба канала и сравнивайте их между собой:
— webhook пришёл, но статус в API не совпал → не верьте первому же payload;
— polling видит settled, а webhook завис в processing → у вас лаг или потеря доставки;
— событие пришло дважды → идемпотентность или смерть.

Главная ошибка — считать webhook источником истины. Нет. Источник истины — ваш ledger, а внешний сигнал лишь триггер на проверку. Подпись, timestamp, replay protection, дедупликация по event_id, retry-логика с backoff — это не «доп. безопасность», а минимальный набор, чтобы не ловить двойные списания и фантомные отмены.

Polling тоже не панацея: он жрёт лимиты, создаёт лишнюю нагрузку и маскирует проблемы доставки. Но как страховка он полезен: если webhooks молчат, polling добирает консистентность и добивает зависшие стейты. Документация — это ложь, логи — истина.

Держите webhook как быстрый сигнал, polling как контрольный обход, а reconciliations — как судью. Иначе ваш мерчант забанен без объяснения причин, а вы ещё будете искать «почему статус сам изменился».