«Заказ должен стать оплаченным» — самая дорогая иллюзия в требованиях

На демонстрации флоу оплаты выглядит линейно:
нажатие кнопки → смена статуса.

В промышленной эксплуатации этот процесс всегда распадается на сценарии вероятности.
Чтобы спроектировать устойчивое решение, полезно использовать Scenario Slicing.

⸻

🟢 1. Идеальный сценарий (~95% случаев)

Пользователь совершает оплату, эквайринг подтверждает её мгновенно (в течение 1–3 секунд).
Система автоматически меняет статус на Paid, резервирует остатки и отправляет чек.

Ловушка этого этапа:
кажется, что проектировать больше нечего.
Но именно здесь закладывается фундамент, который может «сложиться» на оставшихся 5%.

⸻

🔴 2. Критический сценарий (~1–3% случаев)

События приходят с нарушением таймингов или дублируются.

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

Проектные вопросы, которые нужно решить «на берегу»:

— Идемпотентность: как система распознает дубль, чтобы избежать двойного списания?
— Источник истины: кому верим больше — статусу в нашей БД или ответу API шлюза?
— UX неопределенности: что видит пользователь в эти 30 секунд «серой зоны»?

⸻

🟡 3. Штатные исключения (~0.1–1% случаев)

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

Вебхук потерян.
API шлюза недоступно 10 минут.
Данные не синхронизировались.

Решения для «выживания»:

— Ручной контур: инструментарий в админ-панели для саппорта, позволяющий сопоставить платеж вручную
— Сверка (Reconciliation): фоновый процесс сопоставления реестров из банка с нашей базой
— SLA: регламент «если статус не подтвержден за 2 часа — инициируем ручную проверку»

⸻

🛠 Чек-лист: 5 вопросов к любому процессу

Проверьте свои требования на устойчивость. Что произойдет, если:

— Задержка: шаг №2 случится через 60 минут после шага №1?
— Дублирование: система получит одно и то же уведомление дважды?
— Инверсия: подтверждение оплаты придет раньше, чем запись о создании заказа?
— Слепое пятно: что видит пользователь, когда деньги списаны, а статус «В обработке» висит долго?
— Вмешательство: как оператор может форсировать процесс, если автоматика зациклилась?

⸻

Итог

Сценарии 95 / 4 / 1 показывают простую вещь:
архитектура — это не только код, но и регламенты работы людей там, где автоматизация слишком дорога.