Платежный контур обычно выглядит надежным до первого сбоя.

Платежный контур обычно выглядит надежным до первого сбоя.
Потом всплывает знакомый набор: webhook прилетел дважды, пришел с задержкой, статус в ЮKassa уже один, а в локальной базе — другой. И внезапно выясняется, что «просто дождаться события» — это не архитектура, а надежда.

Что здесь работает в нормальном сценарии:

— платеж создают с `capture=False`
— входящий webhook проверяют по IP
— каждое событие сначала пишут в event log, и только потом отдают в обработчик
— capture подтверждают через стабильный idempotency key
— успешную оплату сверяют по сумме, валюте и `metadata`
— на расхождение держат ручной `confirm`, который дочитывает фактический статус из ЮKassa и синхронизирует локальную базу

Я бы назвал это не «защитами», а базовой дисциплиной платежей. Потому что webhooks без журнала, idempotency и аварийного пути почти всегда начинают врать 🧩

Паттерн простой: сначала фиксируем факт, потом доверяем событию, и только потом меняем состояние.