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

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

При переносе токенов ошибка редко выглядит как «не работает». Чаще это тихая деградация: часть customer vault уезжает, часть платежей начинает падать на повторной авторизации, а часть списаний превращается в двойные попытки из-за рассинхронизации статусов. Идемпотентность в биллинге — это не рекомендация, а базовый вопрос выживания системы.

Безопасный перенос строится вокруг трех слоев: — реестр соответствия old_token ↔ new_token с версионированием; — контроль жизненного цикла: создан, перенесен, подтвержден, отозван; — атомарная публикация в биллинг, чтобы оркестратор никогда не видел «полупереезд». Если шлюз-источник и шлюз-приемник не поддерживают единый callback contract, нужен отдельный reconciliation-процесс, иначе потеряете хвостовые записи.

Критично не мигрировать «в лоб» все платежные методы сразу. Делайте shard-by-shard или tenant-by-tenant, сохраняйте fallback на исходный токен, а списание переводите в режим dual-read: сначала новый токен, при отказе — старый, но только в рамках строгого окна и с маркировкой причины. Так вы не ломаете dunning-цепочку и не зацикливаете retry на недоступном токене.

После переноса проверьте три вещи: совпадение количества активных токенов, расхождение по decline reason codes и наличие orphaned subscriptions, привязанных к старому идентификатору. Если хотя бы один из этих сигналов шумит, останавливайте раскатку и пересчитывайте состояние в reconciliation-очереди.

Главное правило: миграция токенов — это не ETL, а распределенная транзакция с финансовым хвостом; проектируйте ее так, будто любой callback может потеряться, а любой retry — прийти дважды.