Платёжный контур ломается не на «создать оплату», а на краях.

Платёжный контур ломается не на «создать оплату», а на краях.

Типовые сбои:
— webhook пришёл дважды
— webhook пришёл позже, чем локальная БД успела уйти в другой статус
— запрос прилетел не с того IP
— capture подтвердили ключом, который уже нельзя считать надёжным

Если строить это как «дождались вебхука — обновили статус», система быстро начинает врать.

Что работает жёстче:
1) первый платёж создаётся с `capture=False`
2) входящий webhook проходит IP-check
3) каждое событие сначала пишется в event log, потом уходит в обработчик
4) `capture` подтверждается стабильным idempotency key
5) success валидируется не только по статусу, но и по `amount`, `currency`, `metadata`
6) на расхождение есть ручной `confirm`, который дочитывает фактический статус из ЮKassa и синхронизирует локальную базу

Идея простая: вебхук — это сигнал, но не истина. Истина — это валидация, идемпотентность и аварийный путь. 🔧

Когда у платежей есть журнал, защита от дублей и ручной recovery, контур перестаёт фантазировать и начинает работать.