Миграция платёжных токенов между шлюзами без даунтайма — это не импорт, а операция с риском потери выручки

Миграция платёжных токенов между шлюзами без даунтайма — это не импорт, а операция с риском потери выручки

Ключевая ошибка — переносить token vault как «справочник». На деле токен завязан на PAN-посредника, схему, merchant_id, а иногда и на криптопрофиль шлюза. Если новый контур не умеет принимать старый токен без re-tokenization, то платежный поток начнёт ломаться на повторных списаниях, 3DS и off-session charge.

Рабочая схема обычно строится так: • заводите двойное хранение связки old_token/new_token и статуса миграции; • все списания идут через router, который выбирает допустимый токен по merchant, scheme и gateway capability; • на переходный период включайте fallback на старый шлюз с жёсткой идемпотентностью запросов. Идемпотентность в биллинге — это не рекомендация, а базовый вопрос выживания системы.

Важно отдельно считать не только success rate, но и «тихий» отказ: declined by token mismatch, expired cryptogram, unsupported MIT, рассинхрон customer reference. Для этого нужны reconciliation-джобы, события по каждому шагу миграции и ручка для pause/resume по клиенту или пулу клиентов. Давайте разберем, что происходит с транзакцией в момент сетевого сплита шлюза: если нет корреляционного ключа и повторов с ограничением, вы получите двойную авторизацию или ложный отказ.

Оптимальная стратегия — мигрировать токены лениво: сначала новый токен создаётся при любом успешном платеже, затем старый помечается как deprecated, и только после окна наблюдения выключается из маршрута.

Так вы не режете подписку и не превращаете миграцию в массовый churn.