Платёжный провайдер отправил уведомление об успешной оплате. Компания может сразу обновить заказ, отправить чек и передать его на сборку. Но что произойдёт, если уведомление придёт дважды? Если злоумышленник отправит похожий запрос? Если получатель окажется недоступен?
Webhook — способ сообщать об изменении, не заставляя партнёра постоянно спрашивать API, произошло ли что-нибудь новое. Идея простая. Реализация становится серьёзной, когда на таком сообщении начинают держаться деньги и клиентские обещания.
В чём выигрыш перед опросом
При polling приложение регулярно делает запрос «есть новости?». Большая часть проверок может возвращать отсутствие изменений. С вебхуком отправитель вызывает заранее согласованный адрес только при событии. Это часто уменьшает число бесполезных запросов и сокращает задержку реакции.
Но вебхук — не всегда единственный источник истины. При сбоях полезно иметь возможность запросить состояние операции у партнёра и сверить пропущенные события. Особенно когда речь о платежах, доставке или статусе договора.
Прежде чем верить событию, проверьте источник
Сам факт POST-запроса на нужный URL ничего не доказывает. Провайдер может поддерживать криптографическую подпись полезной нагрузки, секрет для проверки или другой механизм подлинности. Нужно следовать конкретному контракту, проверять срок действия сообщения и не считать секретом адрес, который может попасть в логи.
При этом подлинный вебхук не обязательно означает окончательный бизнес-статус. Некоторые провайдеры присылают промежуточные состояния и отдельные события о возврате или отмене. Их следует интерпретировать согласно правилам партнёра.
Подтвердить получение лучше быстро
Если обработчик внутри HTTP-запроса пытается обновить несколько систем и отправить письмо, он повышает риск таймаута. Более устойчивый вариант — проверить источник, надёжно принять событие и отдельно выполнить дальнейшую работу.
Нужно учитывать повторные попытки доставки, возможное нарушение порядка и требования к формату ответа. Идентификатор события позволяет защититься от дублей, а номер бизнес-операции — не повторять эффект, если отправитель создал новое уведомление о том же результате.
Кто узнает о пропущенном уведомлении
Важен контроль не только успешных HTTP-ответов, но и завершения бизнес-сценария. Если оплата принята, а заказ не получил корректный статус, мониторинг должен обнаружить расхождение и позволить восстановить его по авторитетному источнику.
Для редкого изменения, которое легко узнать обычным запросом, собственная инфраструктура вебхуков может быть избыточной. Но для интеграции с высокой ценой задержки или большим числом событий она способна окупиться.
Webhook сокращает путь от события до реакции. Он не отменяет проверку подлинности, защиту от дублей и ответственность за итоговое состояние заказа.