Миграция токенов между шлюзами без простоя: где чаще всего теряют платежи

Миграция токенов между шлюзами без простоя: где чаще всего теряют платежи

Если токен переносится как «просто запись в БД», система почти всегда получает хвост из дублей, отложенных списаний и спорных статусов. Для безопасной миграции нужен не копипаст, а конвейер с явной семантикой: source-of-truth, статусы жизненного цикла и идемпотентный ключ на каждое действие.

Первый слой — инвентаризация. Для каждого токена фиксируйте: исходный шлюз, тип метода, привязанные подписки, последний успешный charge, ограничения на повторную токенизацию. Без этого нельзя отделить активные токены от «мертвых», а значит миграция начнет повторно дергать невалидные платежные инструменты.

Второй слой — параллельный режим. Новый шлюз должен принимать токен в статусе shadow, а боевой списывать только после успешной валидации: минимальный authorization, проверка 3DS/step-up, сверка валюты и рекуррентного профиля. Любая ошибка уходит в очередь повторов, но не запускает новый tokenization без дедупликации. Это снижает риск revenue leakage и не ломает dunning-логику.

Третий слой — отсечка старого контура. Не выключайте старый шлюз, пока не закрыты открытые авторизации, не завершены отложенные попытки списания и не подтверждено, что у всех активных подписок есть рабочий replacement token. Идемпотентность в биллинге — это не рекомендация, а базовый вопрос выживания системы.

Практика простая: сначала тень, потом сверка, потом переключение, и только затем деактивация старого токена.