Платежи ломаются не на «создать оплату», а на первом рассинхроне.
Кейс: ЮKassa, webhook-и, локальная база и реальный бой. Сценарий собрали так:
1) Первый платеж уходит с `capture=False`
2) Входящий webhook проходит IP-check
3) Событие сначала падает в event log, потом — в обработчик
4) `capture` подтверждается только стабильным `idempotency key`
5) Успешный платеж валидируется по `sum / currency / metadata`
6) Если статусы разъехались — есть ручной `confirm`, который дочитывает фактический статус из ЮKassa и синхронизирует БД
Что это дает на практике:
— повторный webhook не ломает состояние
— «поздний» webhook не перетирает актуальный статус
— левый IP не проходит в контур
— capture не дублируется
— при аварии есть ручной путь восстановления, а не молитва на логи
Вывод простой: платежный контур нельзя строить на одном вебхуке. Нужны проверки, журнал событий и аварийный сценарий. Иначе система не принимает оплату — она просто красиво врет. 🔧
WB Pulse
@WBPulsePro
Платежи ломаются не на «создать оплату», а на первом рассинхроне.
Этот пост опубликован в Telegram-канале WB Pulse. Подписаться можно по ссылке: @WBPulsePro.