Платёжный контур ломается не на создании оплаты, а на стыке событий: повторный вебхук, задержка доставки, IP н

Платёжный контур ломается не на создании оплаты, а на стыке событий: повторный вебхук, задержка доставки, IP не из списка, расхождение между удалённым и локальным статусом.

В рабочей схеме сначала создают оплату с `capture=False`, затем проверяют входящий webhook по IP, каждое событие пишут в event log и только после этого передают в обработчик. Capture подтверждают стабильным idempotency key, а успешный платёж дополнительно сверяют по сумме, валюте и `metadata`.

Отдельно держат аварийный ручной confirm: он дочитывает фактический статус из ЮKassa и синхронизирует локальную базу, если автоматический сценарий уже разошёлся с реальностью. Такой подход не «ускоряет оплату», а делает систему проверяемой и предсказуемой 🔧