<b>Webhooks vs Polling: почему ваш стейт ломается не в платеже, а в синхронизации</b>

<b>Webhooks vs Polling: почему ваш стейт ломается не в платеже, а в синхронизации</b>

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

Если строите платёжный контур, запомните базу:
— webhook обрабатывается идемпотентно, иначе привет двойной сеттлмент;
— любой event может прийти повторно, не по порядку и после таймаута;
— отсутствие webhook не равно failure, это просто дырка в доставке;
— polling без backoff и дедупликации превращает API в жертву собственного интегратора.

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

Главный анти-паттерн — верить, что callback пришёл и значит всё ок. Нет. Проверяйте подпись, correlation id, state machine и переходы. Иначе ваш мерчант забанен без объяснения причин, а вы ещё спорите с поддержкой про «редкий кейс». Идемпотентность или смерть.