Webhooks vs Polling: почему стейт в платежах ломается не на API, а на вашей логике

Webhooks vs Polling: почему стейт в платежах ломается не на API, а на вашей логике

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

Нормальная схема не выбирает религию, она строит консистентность:
• webhook = триггер, poll = страховка;
• все входящие события кладем в очередь, а не сразу в бизнес-логику;
• обработчик обязан быть идемпотентным, иначе двойное списание — не баг, а закономерность;
• статус оплаты обновляем только по собственной таблице переходов, а не по первому красивому JSON.

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

Правильный паттерн простой и злой: принимаем webhook, сверяем его с локальным стейтом, при споре дотягиваем polling’ом, а дальше раскладываем по конечному автомату. Без этого у вас не интеграция, а костыль на костыле и финтехом погоняет.

Идемпотентность или смерть: если не можете объяснить, какой источник истины главный, значит, у вас его нет.