PSP token migration is the transfer of stored card tokens from an outgoing payment processor to a new one, so saved cards and recurring payments keep working. For PayFacs, PSPs and ISVs, the traditional process depends on the outgoing provider's cooperation and can take months. With a universal token, the new processor is usable immediately while existing tokens keep working.
Every operator that changes acquirer, takes over a merchant portfolio or adds a processor faces the same question: what happens to the cards already stored? This article, updated in October 2026, explains when token migration is needed, why operators run several processors, how the traditional process works step by step, what slows it down, how universal tokenization changes it, where network tokens fit, and what to check before migrating.
What is PSP token migration and when do PayFacs and PSPs need it?
A token is an identifier that replaces a card number, so the operator and its merchants never store sensitive card data. Each processor issues its own tokens, readable only on its own systems. Token migration moves the underlying card data from the outgoing processor's vault to the new one, which issues new tokens in return.
PayFacs and PSPs need it when they replace an acquirer or processor, when they take over a portfolio of merchants from another provider, or when an ISV moves its embedded payments to a new partner. In each case, the stored cards behind subscriptions, one-click payments and installments must follow, or the merchants lose recurring revenue.
Why do payment operators run several processors?
Because one processor rarely gives the best result in every market, for every card type and at every moment. Several processors let an operator route each transaction to the provider with the best authorization rate or cost, keep a fallback during outages, and negotiate better terms.
Payments consultant Dwayne Gefferie made the same point in a widely shared essay on why a single PSP is not enough: payment performance requires multiple transaction routes. The catch is that tokens tied to one processor make every new route harder to use for existing customers.
How does the traditional token migration process work, step by step?
In the traditional process, the operator, the outgoing processor and the receiving processor go through nine steps:
- Information gathering: the operator identifies the outgoing processor's security contacts and migration policy.
- Request initiation: the operator's security team formally requests the export of token data.
- Processor agreement: the outgoing processor must accept the migration, which can be delayed or, in some cases, refused.
- Compliance check: the outgoing processor verifies that the receiving one is PCI DSS compliant.
- Transfer procedure: both processors agree on encryption methods, transfer mechanisms, credentials, data formats and timeline.
- Data export: the outgoing processor exports the card data, sometimes for a fee.
- Initial transfer: the receiving processor imports the data and issues new tokens.
- Integration: the operator maps old tokens to new ones in its systems and in its merchants' systems.
- Wrap-up transfer: cards added or updated since the initial export are transferred as a final differential.
What slows a token migration down and what can it cost?
Mostly, the outgoing processor's timeline. It has little incentive to hurry, its security team handles migrations alongside other priorities, and each pair of processors has its own encryption and file requirements. In NORBr's experience, agreeing on the transfer procedure alone can take several weeks, sometimes months.
Costs follow: export fees, occasional charges for "urgent" handling, development time to remap tokens, and the risk of failed recurring payments if the cut-over is not clean. Meanwhile, the operator keeps paying for the old processor and cannot fully use the new one for existing customers.
How does universal tokenization change the migration?
A universal token sits above the processors. The operator and its merchants store one token per payment method, issued by the infrastructure, and the infrastructure maps it to the right processor token behind the scenes. On NORBr, that token can represent a card, an Apple Pay or Google Pay credential, or a PayPal account.
The effect on migration is direct. The new processor can be used immediately for new customers and new subscriptions. Existing subscriptions keep being billed with the old processor's tokens, which NORBr maps without any change for the operator or its merchants, until the migrated data arrives. The tokenization article details how universal tokens work.
How do network tokens and recurring payments fit in?
Network tokens, issued by card schemes such as Visa and Mastercard, are not tied to a processor and are updated automatically when a card is renewed or replaced. Stored as network tokens, cards are easier to move between providers and fail less often on recurring charges.
On NORBr, the network tokenization layer and the recurring payment infrastructure work together, so subscriptions survive both card renewals and processor changes. For operators replacing an older stack, the legacy platform upgrade page describes the wider migration.
What should a PayFac or PSP check before migrating tokens?
A short checklist avoids most surprises:
- Contract terms: what the outgoing processor's agreement says about data portability, notice and fees.
- Compliance: the receiving side's PCI DSS attestation, ready to share.
- Scope: which cards, merchants and payment methods move, and which can expire.
- Format and encryption: the file specification and keys agreed in writing.
- Differential and cut-over: a date for the final transfer and a plan for cards updated in between.
- Continuity: how recurring payments are billed until the migration completes.
The Apple Pay integration article covers the wallet side, where device tokens follow different rules.
_%2520a%2520game%2520changer%2520for%2520digital%2520transactions_-Cover.webp){kind=spacer}
