Двойное списание платежа в коде, прошедшем ревью: разбор инцидента глазами инженера

Разбор реального инцидента в платёжном сервисе: код прошёл ревью, тесты были зелёными, в базе зафиксирован один успешный платёж — но с карты клиента деньги списались дважды. Автор показывает, что к дублированию привели два разных сценария, и оба оказались неочевидными для стандартного тестирования.

Материал построен как расследование по коду и логам: шаг за шагом восстанавливается, где именно логика дала сбой и почему ревью не поймало проблему. Особый акцент — на концепции идемпотентности и на том, как её правильно выстраивать в платёжных системах, чтобы повторные списания были исключены на архитектурном уровне.

Для индустрии это напоминание, что зелёные тесты не гарантируют корректность в распределённых финансовых сценариях, а ревью без понимания бизнес-контекста может пропустить критичные дефекты. Кейс полезен backend- и платёжным командам как чек-лист по идемпотентности. Полный разбор — на Хабре.