<b>Миграция токенов между шлюзами без даунтайма: где ломается биллинг</b>

<b>Миграция токенов между шлюзами без даунтайма: где ломается биллинг</b>

При переносе токенов главная ошибка — считать их «данными карточки». На деле токен привязан к контексту: шлюзу-эмитенту, мерчанту, валюте, типу операции и правилам сети. Если просто перелить идентификаторы в новую систему, получите silent decline, рост повторных попыток и расхождение статусов между биллингом и PSP.

Безопасная схема строится в два слоя: каталог соответствий и двойная запись событий. Сначала фиксируете mapping старый_token → новый_token, но не переключаете оплату. Затем каждое списание проходит через оркестратор, который умеет: • выбирать активный токен по приоритету; • откатываться на старый маршрут при ошибке; • сохранять идемпотентный ключ на попытку списания.

Критично разделить миграцию на трафик новых платежей и renewal-трафик. Для подписок сначала переводят only-on-success операции: успешный renewal создает новый токен, старый остается резервным до подтверждения нескольких циклов. Для рекуррентных списаний нужен shadow mode: новый шлюз получает запросы в параллель, но не влияет на пользовательский статус, пока не пройдут сверка авторизаций, capture и reconcile по журналам.

Идемпотентность в биллинге — это не рекомендация, а базовый вопрос выживания системы. Если у вас нет строгого дедупа по payment_intent, retry-policy и трассировки каждого gateway_response, миграция превратится в генератор двойных списаний и ручных разборов. Финальный принцип простой: токен не мигрируют «разом», его переводят через управляемую фазу совместного существования, где старый и новый маршрут живут параллельно до полной консистентности.