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

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

Самый частый чёрный кейс — когда webhook считают истиной по умолчанию. Приходил повторно, с задержкой, с чужого IP, с расхождением статуса — и всё равно запускал бизнес-логику. Итог предсказуем: локальная БД живёт своей жизнью, удалённый платёж — своей, а потом начинается ручная археология по инцидентам.

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

Это не про «подстраховаться». Это про то, чтобы платежный контур не врал под нагрузкой и в сбое. Без журнала событий, идемпотентности и аварийного пути webhook — не источник правды, а источник риска. ⚠️