Most enterprise merchants start their tokenization journey with PSP tokens, because that is the default option every payment service provider offers out of the box. The integration is fast, the vault is managed by the provider, and the immediate security and PCI scope benefits are real. The trade-off is vendor lock-in. Once millions of stored credentials sit inside one PSP’s vault, switching providers, adding a second one, or capturing the 2-7% authorization rate lift from network tokens becomes operationally complex and easy to defer.
This guide is for merchants who have decided to migrate. It covers what to audit before starting, the five stages of a typical PSP-to-network-token migration, how to handle the operationally sensitive credential migration step, common pitfalls, expected timelines and resource requirements, and how to measure ROI as the migration proceeds.
For a foundational understanding of how PSP tokens and network tokens differ before reading this guide, our overview of PSP tokens vs network tokens covers the basics.
Token migration is significant engineering work. Merchants typically commit to it when one or more of the following business pressures becomes acute:
1. Adding a second PSP. The single most common trigger. The moment a merchant decides to operate with more than one PSP (for redundancy, regional coverage, cost optimization, or specific payment method support), PSP-locked tokens become a structural problem. Cards stored with the existing PSP cannot be charged through the new one without either re-collecting from customers or migrating the underlying credentials.
2. Subscription decline rates climbing. PSP tokens do not auto-update when underlying cards are reissued. Subscription businesses typically see 5-8% involuntary churn from expired or reissued cards, with most of that loss preventable through network tokenization. Network tokens automatically refresh at the network level, removing this source of churn entirely.
3. Cross-border expansion. Merchants expanding into new geographies often discover their current PSP’s coverage is weakest in exactly the markets they need most. Local acquirers typically deliver 10-16% higher authorization rates than foreign processors for in-market cards, but unlocking those acquirers requires moving stored credentials out of the PSP-locked vault.
4. Acquisition or merger integration. Post-acquisition integration almost always surfaces incompatible PSP token stores. The acquiring company runs Stripe, the acquired company runs Adyen, and unifying the customer book requires either dual-running both stacks indefinitely or migrating one set of tokens to a common provider-agnostic layer.
5. Pricing renegotiation power. Merchants with PSP-locked tokens negotiate from a position of weakness. The PSP knows the cost of switching is high, and pricing conversations reflect this. Merchants with portable tokens negotiate from parity, which typically translates to meaningfully better pricing terms within the first negotiation cycle.
6. PCI DSS 4.0.1 audit pressure. The current PCI DSS standard tightens requirements around stored cardholder data. Some merchants find that consolidating onto network tokens through a single PCI Level 1 vault simplifies their audit posture substantially compared to maintaining cardholder data across multiple PSP integrations.
If any two of these apply to your business, the migration math typically works in the first year. If three or more apply, deferring the migration becomes the more expensive option.
Before any technical work begins, the migration project needs answers to ten questions. The answers determine timeline, complexity, and which providers need to be involved.
The audit typically takes 1-2 weeks for a mid-market merchant and 3-4 weeks for an enterprise with multiple PSPs. It is time well spent, because every downstream stage assumes these answers.
A typical PSP-to-network-token migration runs through five stages. The stages are sequential, but several can be partially overlapped to compress the timeline.
The first technical step is implementing the destination vault. This is the PCI DSS Level 1 certified environment that will hold the underlying PAN data after migration. There are three common approaches:
Approach A: Use a third-party vault provider. Provider-agnostic vaults from Basis Theory, VGS, or Gr4vy’s Cloud Vault handle the certification, infrastructure, and ongoing PCI scope. Most enterprise merchants choose this path because the build-versus-buy math rarely favors building.
Approach B: Use an orchestration platform with vaulting built in. This is the option that simplifies the entire architecture, because the vault and the routing layer share a single integration. The orchestration platform handles vault storage, network token provisioning, and PSP routing through one API.
Approach C: Build an in-house vault. Some very large merchants with specialized requirements run their own PCI Level 1 vault. This is significant engineering work (typically 9-18 months and multi-million-dollar investment) and ongoing compliance burden, but provides maximum control.
Whichever path is chosen, the vault must be operational, certified, and integrated with the merchant’s checkout before stage 2 begins.
Once the vault is live, the merchant’s checkout starts writing every new card to both the existing PSP vault (for backward compatibility) and the new vault (for forward compatibility). The PSP token continues to be used for transactions during this stage; the new vault is populated in parallel but not yet active.
This dual-write phase is the single most important risk-mitigation step in the entire migration. It allows the merchant to validate that the new vault is capturing data correctly, that the integration is stable, and that the operations team is comfortable with the new system before any production transactions depend on it.
Dual-write typically runs for 2-4 weeks. During this period, the merchant’s payments analytics should be checking that every new card written to the PSP also gets a corresponding entry in the new vault, with no data loss or mismatch.
This is the operationally sensitive step. The stored cards that live inside the current PSP’s vault need to be moved into the new vault. There are three primary methods, each with different trade-offs:
Method 1: PSP-supported export. Most major PSPs support credential export procedures for departing merchants. Stripe’s Data Migration program, Adyen’s tokenization export, and similar processes at Braintree and Worldpay all exist, though the specific terms vary by contract. The export typically takes 4-12 weeks of coordinated work between the merchant, the current PSP, and the destination vault.
Method 2: Network token re-provisioning. Visa, Mastercard, and American Express can provision network tokens directly against the underlying PAN without requiring the PAN to leave the PSP’s vault, in some implementation patterns. This approach works particularly well when both the current PSP and the destination vault are integrated with the same network tokenization services. The migration becomes a metadata operation rather than a full credential transfer.
Method 3: Card-on-file re-authorization. For active customers, a hybrid approach involves issuing a $0 or $1 authorization request to refresh the credential, capturing the response, and storing it in the new vault. This works for active customers but does nothing for dormant accounts.
The right method depends on the PSP, the merchant’s contract, and the network tokenization partners involved. Most enterprise migrations use a combination: PSP-supported export for the bulk of the credentials, network re-provisioning where it is faster, and re-authorization for any remaining edge cases.
This stage is also where data loss or corruption risk is highest. The most defensible approach is to migrate in batches (typically 10% of the credential book per week), with reconciliation checks after each batch confirming that every credential migrated successfully and the resulting tokens authorize correctly.
Once cards live in the merchant-controlled vault, network tokens can be provisioned against them. The provisioning typically happens through the vault provider or orchestration platform, not directly by the merchant. The technical work involves:
For most enterprise vaults, this provisioning runs as a back-end batch process and takes 1-3 weeks depending on the volume of credentials. The credentials being provisioned can already be in active use through merchant tokens during this stage; network tokens are provisioned underneath without disrupting transactions.
A useful detail: not every card is eligible for network tokenization. Issuer participation varies, and certain card types (some commercial cards, certain co-branded cards) may not be tokenized at the network level. Plan for roughly 80-90% of the credential book to be eligible for network tokenization, with the remainder continuing as merchant tokens.
The final stage activates the new infrastructure. The orchestration layer (or routing logic, if no orchestration platform is being used) is configured to:
Once routing is active, the merchant can begin running A/B comparisons between transactions routed through network tokens and the legacy PSP-token-only flow. The authorization rate lift typically becomes visible within the first month, and the full revenue impact compounds across subsequent billing cycles for subscription businesses.
The migration of stored credentials (stage 3) is where most migration projects encounter unexpected issues. A closer look at what actually happens at this stage helps anticipate them.
The merchant’s current PSP holds the underlying PAN for every stored customer. The merchant typically does not have direct access to those PANs (they live inside the PSP’s PCI environment). To migrate, the PAN data needs to move from the source PSP’s vault to the destination vault, in a way that is PCI compliant at every step.
In practice, this means the source PSP exports the PANs into an encrypted file that is transmitted directly to the destination vault provider through a secure channel. Both parties verify the file integrity, the destination vault ingests the data and generates new tokens, and the merchant updates their customer records to reference the new tokens.
The merchant never sees the raw PAN data during this process. Both PSPs are responsible for maintaining PCI compliance at their respective ends.
Three failure modes account for most migration incidents:
Data integrity issues. Encrypted file transfers can drop, corrupt, or duplicate records. Reconciliation procedures need to verify that every credential in the source set appears exactly once in the destination set, with the correct customer mapping. Batching the migration helps catch issues early.
Customer record mismatches. If the merchant’s database uses different customer IDs than the PSP’s vault, or if there are duplicate customer accounts in the source system, the migration can produce orphan tokens (no customer to associate them with) or duplicate associations (one customer linked to two tokens). Pre-migration data cleanup prevents this.
Authentication failures during the transition. During the dual-write phase and the credential migration window, some customers may transact, update their card, or churn. The migration plan needs to handle these mid-flight changes without losing data or double-charging.
After every batch of credentials moves, reconciliation has to confirm three things:
Reconciliation typically runs the day after each batch. Any discrepancies are investigated and corrected before the next batch begins. Skipping reconciliation is how migrations produce silent data loss that only becomes visible months later when subscription renewals start failing.
A handful of patterns separate successful migrations from troubled ones:
Migrating active and dormant credentials with the same plan. Active customers (last transaction within 12 months) have valid cards that can be reauthorized as part of the migration. Dormant customers may have expired or replaced cards that will only become visible as failures. Plan separately for the two populations. For dormant customers, accept that some credentials will not migrate cleanly and that the next transaction (whenever it happens) may decline.
Underestimating the PSP cooperation requirement. The current PSP has to participate in the migration. They are not always eager to help a departing customer. Build the migration contract terms before any technical work begins, and make sure the PSP’s data export commitments are written into the agreement.
Skipping the dual-write phase. Some teams want to move fast and migrate directly from PSP tokens to network tokens without a dual-write period. The savings in calendar time are real, but the risk of an undetected failure mode taking down live transactions is also real. The conservative approach (dual-write for 2-4 weeks) catches issues before they reach production.
Failing to plan for cards that cannot be network-tokenized. Roughly 10-20% of cards in a typical book will not be eligible for network tokenization on day one. The migration plan needs to handle these gracefully, either by keeping them as merchant tokens in the new vault or by gradually re-attempting network tokenization as issuer participation expands.
Not measuring the right metrics. The migration’s success is measured in authorization rate lift, decline reduction on card-on-file transactions, and reduction in involuntary churn. Some teams measure migration success in operational metrics (credentials migrated, percent complete) and miss whether the migration is actually delivering the business outcomes. Both sets of metrics matter.
Treating it as a one-time event rather than a capability. Once the vault and orchestration layer are in place, adding new PSPs, switching primary processors, or running A/B tests across providers becomes routine. The migration is the hard part. The flexibility it unlocks is the lasting benefit.
For an enterprise merchant processing $100M in annual card volume, with 70% card-not-present and 30% card-on-file or subscription billing, the typical migration delivers:
Authorization rate lift on CNP volume. A 4.6% lift on $70M in CNP volume translates to roughly $3.22M in additional approved transactions per year that would have declined without network tokens.
Subscription churn reduction. On $30M in card-on-file volume with a baseline 5-8% involuntary churn rate, a 20% reduction in card-reissue declines recovers $300K-$480K per year.
Fraud reduction. A 30% reduction in fraud on a baseline 0.5% chargeback rate saves approximately $150K in chargebacks and associated fees.
Visa interchange incentive. The 0.10% incentive on eligible tokenized CNP transactions delivers an additional $50K-$70K per year.
Total annual recovery: $3.5M to $4M of recovered revenue.
Against this, the migration costs typically include vault provider fees, orchestration platform fees if applicable, internal engineering time (typically 2-4 engineering quarters), and any PSP transition fees. For most enterprise merchants, the migration recovers its costs within the first 6-9 months and compounds in every subsequent year.
The ROI math becomes more favorable as merchant volume increases, because the per-transaction costs are largely fixed while the per-transaction lift scales linearly with volume.
A typical PSP-to-network-token migration for an enterprise merchant runs 12-20 weeks from kickoff to live network token routing:
| Phase | Duration | Key deliverable |
|---|---|---|
| Pre-migration audit | 2-4 weeks | Inventory, contracts reviewed, plan approved |
| Stage 1 (vault setup) | 3-6 weeks | Vault live, certified, integrated with checkout |
| Stage 2 (dual-write) | 2-4 weeks | New cards writing to both vaults reliably |
| Stage 3 (credential migration) | 4-12 weeks | Existing credentials transferred and reconciled |
| Stage 4 (network token provisioning) | 1-3 weeks | Eligible cards have active network tokens |
| Stage 5 (routing activation) | 1-2 weeks | Live transactions routing through new infrastructure |
The phases can be partially parallelized. Stage 2 and the early parts of Stage 3 typically overlap, as do Stage 4 and Stage 5. The bottleneck for most projects is Stage 3, where PSP cooperation and reconciliation requirements set the pace.
Resource requirements for a mid-market enterprise:
For larger enterprises with multiple PSP relationships and tens of millions of credentials, double the timeline and resource estimates as a starting point.
A payment orchestration platform with built-in vaulting and network token support compresses several of the stages significantly. Instead of integrating separately with a vault provider, a network tokenization service, and a routing layer, the merchant integrates once with the orchestration platform and the underlying components are configured rather than built.
The practical impact:
Stages 2 and 3 (dual-write and credential migration) still require operational coordination with the current PSP, but the technical work happens through the orchestration platform’s existing connectors.
For a deeper view of how this works end-to-end, our overview of what a payment orchestration platform is covers the architecture, and Gr4vy’s collaboration with Mastercard details how Mastercard Merchant Cloud (network tokenization, Click to Pay, gateway services) is available directly through the orchestration platform.
For an enterprise merchant with a single existing PSP and a moderate credential book, a typical migration runs 12-20 weeks end-to-end. Merchants with multiple PSPs, tens of millions of stored credentials, or complex compliance requirements should plan for 6-9 months. Merchants using an orchestration platform that has the vault and network tokenization built in can typically compress the timeline by 30-40%.
If the migration is executed properly, customers should notice nothing at all. Their stored cards continue to work, their subscriptions continue to renew, and their checkout experience is unchanged. The only customer-visible impact should be the gradual improvement in transaction success rates as network tokens reduce expired-card declines and improve authorization rates.
Partially, but not completely. For the underlying PAN data to leave the PSP’s vault, the PSP has to participate in the export process. Most major PSPs have established procedures for this, though the specific terms vary by contract. Where PSP cooperation is limited, alternative approaches (network token re-provisioning where the network can identify the underlying card, or $0 reauthorization of active customers) can recover a meaningful portion of the credential book without full PSP support.
For dormant customers with expired or invalid cards, those credentials will fail to migrate cleanly. The standard practice is to remove them from active billing flows and treat the next customer engagement as a fresh card collection. For active customers whose cards cannot be migrated for any reason, the merchant typically prompts a card update during the next customer interaction.
No. The migration is from PSP-locked tokens to provider-agnostic tokens, not from one PSP to another. After migration, the merchant can continue using the same PSP, add additional PSPs without re-collecting card data, or switch primary processors based on performance. The point of the migration is to gain the option, not to force a specific PSP change.
Migration costs vary significantly by merchant size and complexity. For a typical enterprise migration, the major cost components are vault and orchestration platform fees (typically priced as a percentage of transaction volume or a tiered subscription), internal engineering time (2-4 quarters of engineering capacity), and any PSP transition fees. For most enterprise merchants processing $50M+ in annual card volume, the migration recovers its costs within 6-9 months from authorization rate lift alone.
The dual-write architecture is the rollback plan. During and immediately after the migration, the current PSP’s vault and the new vault both hold copies of the customer credentials. If a critical issue is detected, transactions can be routed back to the PSP tokens while the issue is resolved. Once the migration has been live and stable for 30-60 days, the dual-write can be wound down and the PSP-side vault becomes a true backup.
No, and most merchants do not. Batch migration (typically 10% of the credential book per week, with reconciliation between batches) is the standard pattern. This allows issues to be caught and corrected early without affecting the entire credential book. The full migration typically completes in 6-12 weeks of active credential movement.
PCI scope is typically reduced once the migration completes, sometimes significantly. The merchant’s environment no longer needs to be configured to handle cardholder data flowing to multiple PSP integrations; instead, cardholder data is centralized in a single PCI Level 1 vault, and the merchant interacts with tokens. During the migration itself, both the source and destination environments need to maintain PCI compliance, which is why working with a Level 1 certified destination vault is essential.
The migration itself should not change authorization rates during the transition, because transactions continue to flow through the existing PSP tokens until routing is activated in Stage 5. Once network tokens are live, authorization rates on tokenized CNP transactions typically lift by 2-7%, with the full benefit visible within the first 30-60 days.
Yes, but the migration unlocks less value. Moving from one PSP’s vault to another’s is technically possible if both PSPs cooperate, but the result is still a PSP-locked credential book, just in a different PSP. The strategic value of migration comes from moving to a provider-agnostic vault with network tokens layered on top, which is what unlocks the flexibility, authorization rate lift, and lifecycle resilience.
The migration ROI scales with volume. For merchants processing under $10M annually with no card-on-file or subscription billing, the return may not justify the engineering investment. The break-even point typically sits around $20-30M in annual card volume for merchants with meaningful CoF or subscription mix, and the math gets steadily more favorable above that threshold.
The merchants who have completed PSP-to-network-token migrations consistently report that the engineering work, while substantial, was the easy part. The harder part is committing to the project in the first place, because the costs are visible upfront and the benefits compound over time.
For merchants beginning to plan this work, the practical first step is the pre-migration audit. Answer the ten questions in the section above. The answers will tell you whether the migration is worth pursuing now, what your specific timeline looks like, and where your risks concentrate.
Gr4vy’s cloud-native payment orchestration platform was designed to compress the technical phases of this migration. Through a single integration, merchants get a PCI Level 1 vault, automatic network token provisioning across Visa, Mastercard, American Express, and Discover, and routing across more than 400 PSPs and payment methods. The migration becomes a configuration project rather than a multi-vendor integration project.
If you’re evaluating whether and when to migrate, or want a walkthrough of what your specific migration would look like, contact our team for a stack audit and migration plan tailored to your current setup.
The four major credit card networks process more than $27.7 trillion in consumer transactions worldwide…
Integration brings a consistent payments infrastructure across registrations, memberships, and competitions as PlayHQ expands internationally.…
Agentic commerce is a form of online commerce in which autonomous AI agents discover products,…
Agent-driven traffic across the web has grown more than 1,300% in the past nine months.…
Most businesses use the terms payment gateway, payment processor, and payment orchestration platform as if…
The average online checkout loses seven out of every ten shoppers. Across all industries, the…