Приложил карту к турникету — списался 1 ₽. Через минуту пришло второе уведомление — 83 ₽. С самокатом похоже: при привязке списался 1 ₽, после поездки — 189 ₽. Снаружи одинаково: два списания и задержка между ними. Внутри — три совершенно разных паттерна, и аналитику важно их различать, потому что архитектура у них разная.

TL;DR

  • Самокат, такси, отели — причина бизнесовая: сумма неизвестна на старте. Две фазы: preauth (заморозили 1₽) → capture (списали реальную сумму).
  • Метро — причина техническая: сумму знаем, но турникет не может ждать банк. Отложенная авторизация: сначала пропусти, потом спиши в фоне.
  • Привязка карты к подписке — причина верификационная: проверяем, что карта настоящая и твоя. Списали 1₽ и сразу вернули.
  • Один симптом — два уведомления от банка. Первый вопрос аналитика: почему два шага, а не один?

Бизнесовая причина: не знаем сумму (preauth + capture)

Когда сканируешь QR на самокате, приложение не знает, сколько ты накатаешь — 5 минут или час. Поэтому платёж разбит на две фазы:

  • Фаза 1 — авторизация (preauth). Приложение просит банк проверить карту и заморозить 1 ₽. Банк отвечает: «карта живая, деньги есть», самокат разблокирован.
  • Фаза 2 — списание (capture). Поездка окончена, сервис посчитал 189 ₽ и говорит банку: «списывай». Холд снимается, реальная сумма уходит со счёта.

Между фазами проходит время, потому что этого требует бизнес-логика: итоговая сумма появляется только когда ты закончил. Тот же паттерн в каршеринге, такси, аренде, отелях.

Техническая причина: не можем ждать (отложенная авторизация)

В метро всё наоборот. Сумма известна заранее — 83 ₽. Казалось бы, списывай сразу. Но через турникеты загруженной станции в час пик проходят тысячи человек в минуту, а полный цикл банковской транзакции — это цепочка «терминал → банк-эквайер → платёжная система → банк-эмитент → ответ обратно», и это секунды.

Поэтому турникет делает минимум: проверил, что карта не в стоп-листе (чёрный список периодически подгружается с серверов) — открылся. Полная транзакция уходит в фоновую очередь и обрабатывается позже. Сначала пропусти, потом разберись. Турникет пропустит даже при нуле на счёте: минус спишут потом, когда деньги появятся, либо карта попадёт в стоп-лист и в следующий раз не сработает.

Верификационная причина: не уверены, что это ты

Привязываешь карту к подписке — списался 1 ₽ и через секунду вернулся, а уже потом уходит полная сумма. Здесь сумма известна и нагрузка нормальная, но сервис сначала проверяет: карта настоящая, принадлежит тебе, с неё можно списывать. Причина не «не знаю сколько» и не «не могу ждать», а «не уверен, что ты — это ты».

Почему аналитику важно это различать?

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

Нарисовал одно действие «оплатить» — потерял половину логики. Видел кейс: аналитик описал оплату подписки одним действием «списать», без авторизации и проверки карты. В прод ушло как есть. Первый баг прилетел, когда у пользователя сменилась карта — система молча «списала» с несуществующего счёта и неделю показывала «подписка активна».

Снаружи — два уведомления от банка. Внутри — три разных мира. Увидел задержку между операциями — спроси: это бизнес не знает сумму, система не тянет синхронно, или идёт проверка карты? Ответ определяет архитектуру.