Платёжный webhook — это не «событие из интернета», а потенциальный источник рассинхрона. Пока всё гладко, хватает create → webhook → update status. Но в реальности прилетает дубль, задержка, запрос не от того IP, а локальная БД уже живёт своей жизнью.
Рабочая схема для ЮKassa выглядит так:
1. Создаём платёж с `capture=False`
2. Входящий webhook режем по IP-check
3. Любое событие сначала пишем в event log, потом уже в обработчик
4. `capture` подтверждаем только стабильным `idempotence-key`
5. Успешный платёж валидируем по `amount`, `currency` и `metadata`
6. Если контур разъехался — есть ручной `confirm`, который дочитывает реальный статус из ЮKassa и синхронизирует локальную БД
Главная мысль: webhook сам по себе не истина. Истина — это верифицированное событие + журнал + идемпотентный вызов + аварийный путь 🔧
Такой контур переживает повторные вебхуки, гонки статусов и ручные ошибки без «магии» и без потери денег.
DevTools Radar
@DevToolsRadarPro
Платёжный webhook — это не «событие из интернета», а потенциальный источник рассинхрона. Пока всё гладко, хват
Этот пост опубликован в Telegram-канале DevTools Radar. Подписаться можно по ссылке: @DevToolsRadarPro.