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

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

Перенос токенов платежных методов — это не «перелить данные», а смена домена доверия. Если не зафиксировать соответствие old_token → new_token, можно получить двойные списания, потерю подписок и тихий рост отказов на повторных платежах.

Критический минимум: • исходный токен и новый должны жить в едином реестре маппинга; • операция миграции обязана быть идемпотентной; • каждый токен проходит валидацию на уровне шлюза до включения в автоплатежи; • старый токен не удаляется сразу, а переводится в статус pending_decommission.

Дальше важна последовательность. Сначала создается новый токен, затем выполняется пробный charge/verify без влияния на цикл биллинга, после этого подписка переключается атомарно. Если шлюз возвращает timeout, система не должна гадать: повтор нужен только при сохраненном idempotency key и понятном статусе операции.

Отдельная зона риска — dunning и ретраи. Если миграция совпала с неуспешным списанием, нельзя запускать обе ветки одновременно: либо сначала стабилизировать платежный метод, либо отложить перевод до завершения recovery-цикла. Идемпотентность в биллинге — это не рекомендация, а базовый вопрос выживания системы.

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