Миграция payment tokens между шлюзами без простоя — это не перенос, а хирургия

Миграция payment tokens между шлюзами без простоя — это не перенос, а хирургия

Если токен привязан к PAN-деривативу у старого PSP, нельзя просто «переписать ID» в новый шлюз. Нужен слой абстракции: внутренний vault-token, mapping на provider-token и статус пригодности к charge/rebill. Идемпотентность в биллинге — это не рекомендация, а базовый вопрос выживания системы.

Критические правила:
• сначала строится двойная запись: старый токен остается источником истины до подтверждения в новом шлюзе;
• все операции миграции проходят через saga с компенсирующими шагами, а не через одну транзакцию;
• на период параллельного существования включается контроль дрейфа: сверка customer, card metadata, expiry, mandate, 3DS-атрибутов.

Дальше начинается самая опасная часть — автосписания. Для recurring-платежей нужен canary-маршрут: небольшой процент rebill-трафика уходит на новый шлюз, а отказ обрабатывается без потери очереди и без повторной авторизации на старом контуре. Если провайдер не умеет детерминированный token exchange, закладывайте fallback на re-tokenization через customer action, иначе получите revenue leakage и ложные отказы.

Перед cutover обязательно проверьте: не потеряны ли merchant-specific token scopes, совпадает ли merchant account routing, сохранены ли права на MIT/CIT, и можно ли откатить mapping без ручной правки базы. Давайте разберем, что происходит с транзакцией в момент сетевого сплита шлюза: именно там всплывают дубли, «призрачные» успешные ответы и зависшие pending-статусы.

Лучший сценарий миграции — когда старый и новый шлюзы живут в режиме dual-read, а switch происходит только после сверки успешных списаний и отказов. Тогда токены переезжают без прерывания обслуживания, а не с надеждой, что «как-нибудь разрулится».