Большинство проблем с вебхуками не в коде доставки, а в предположениях о том, как получатель будет их обрабатывать.
Сетевые сбои неизбежно приводят к повторной доставке одного и того же события. Если обработчик не проверяет, было ли событие уже обработано по его id, повторная доставка может привести к двойному списанию средств или дублированию записей.
Если обработчик вебхука выполняет долгую операцию (отправку email, генерацию отчёта) до ответа, велик риск таймаута и лишнего повтора. Правильный паттерн — быстро подтвердить получение (200 OK), а тяжёлую работу вынести в очередь.
Без проверки HMAC-подписи любой, кто узнает URL эндпоинта, может отправить поддельное событие. Это особенно критично для событий вроде order.paid, влияющих на бизнес-логику.
Если вебхук перестал доходить из-за смены домена или истёкшего сертификата на стороне получателя, об этом узнают, только когда пользователи начинают жаловаться. Настройте алерт на серию неудачных попыток заранее.
Обработка всех событий в одном большом if/else усложняет тестирование и повышает риск, что ошибка в обработке одного типа события уронит обработку остальных. Разносите логику по отдельным обработчикам с общей точкой входа только для проверки подписи.
Начните с бесплатного плана и подключите первый маршрут за 5 минут.