A better authorization rate. Lower processing fees. Stronger coverage in a key market. Enterprise merchants have plenty of reasons to consider switching payment service providers (PSPs). But what happens when the customer payment credentials you’ve spent years collecting can't move with you?
Oftentimes, the problem only becomes apparent during a contract renegotiation or when a more competitive provider enters the picture. At that point, you may notice that your saved payment credentials are tied to an existing PSP — and moving transactions elsewhere may require a costly migration, cooperation from the incumbent provider, or even renewed customer involvement.
Suddenly, a decision that should be driven by payment performance and cost is constrained by your existing tokenization setup.
Planning for token portability means considering both token type and where the token vault sits in the payment architecture. This article explores why both matter — and how enterprises can preserve control over stored credentials as their provider strategy evolves.
What is a Vault Token, and How Does it Work?
A vault token—also known as a PCI or PSP token —is usually what merchants mean when they talk about payment tokens. These proprietary, vendor-specific identifiers replace a customer's primary account number (PAN) with an internal reference that’s stored in the PSP's secure vault.
Vault tokens allow merchants to support recurring billing and saved-card payments without storing sensitive card numbers themselves. They can also reduce PCI DSS compliance scope within the PSP’s ecosystem.
However, a proprietary vault token is essentially a record in someone else's database. This creates three important limitations:
Provider-specific: Only the issuing PSP can match the token to the underlying card number. Another provider cannot use that token to process payments.
Not portable: Switching PSPs requires transferring the underlying card credentials rather than simply moving the existing tokens.
PSP-controlled exports: The issuing PSP controls access to the stored credentials. Merchants depend on its cooperation to transfer them, and contracts may not clearly specify export rights or migration procedures.
What is a Network Token?
Network tokens are payment credentials issued through card network tokenization services. Like vault tokens, they replace sensitive card details — but they also offer additional benefits for payment security, authorization performance, and card lifecycle management:
Enhanced security: Built-in controls restrict token use to approved merchants and transaction channels, while transaction cryptograms provide additional protection for supported transactions.
Cross-provider portability: Network tokens can be used across participating acquirers within the relevant card schemes.
Improved authorization performance: Issuers have greater confidence in network-tokenized transactions, resulting in fewer soft declines on recurring billing.Â
Automatic card updates: Network token lifecycle management can keep stored credentials current when cards expire or are reissued, without requiring customers to reenter their payment details.
Why Token Vault Architecture Matters
Network tokenization alone doesn't guarantee portability. A merchant can use genuine network tokens but still depend on its PSP to access them. Where those tokens are stored — and who controls access to them — can be just as consequential.
A token vault is an encrypted database that securely stores payment credentials and maps them to tokens. Two common approaches have different implications for merchant flexibility:
Provider-Specific Token Vaults
Provider-specific vaults sit within a PSP's infrastructure, keeping credential storage and payment processing under the same provider. While convenient, this arrangement can create two important dependencies:
PSP-controlled provisioning: The PSP may provision network tokens under its own token requestor ID (TRID), an identifier used by the card networks to identify the entity requesting tokens. This can make merchants dependent on the PSP's tokenization arrangement.
Restricted token access: The PSP may retain the actual network tokens in its vault and provide merchants only with proprietary references. Even though the underlying credentials are genuine network tokens, transferring or using them elsewhere may require the PSP's cooperation.
Merchant-Owned Token Vaults
Merchant-owned token vaults allow merchants to maintain control over stored payment credentials independently of individual PSPs. They are often managed by third-party tokenization providers or payment orchestration platforms, and they typically use provider-agnostic tokens like IXOPAY's universal tokens.Â
Together, this independent tokenization and vault setup enables merchants to reuse stored credentials across compatible payment providers — without having to re-tokenize customer card data or maintain separate copies of sensitive card numbers (PANs).
Depending on their capabilities and contractual arrangements, these vaults can also offer:
Merchant-assigned TRIDs: Network tokens provisioned under a dedicated TRID can reduce dependence on a single PSP's tokenization arrangement.
Independent token access: Merchants can access the actual network tokens rather than relying on their processing provider to retrieve them.
The Switching Cost CalculationÂ
Limited token portability can increase PSP switching costs, disrupt recurring revenue, and prevent merchants from acting on better processing opportunities.
The difference between vault tokens and network tokens can be easy to overlook when payments are running smoothly. Both support secure transactions, but they don't give merchants the same control over their stored payment credentials. That distinction becomes particularly important when merchants want to change providers, diversify their processing strategy, or negotiate better terms.
The commercial impact of token lock-in often accumulates over time — well beyond upfront migration costs. Every month a merchant remains tied to an underperforming processor, they miss out on lower transaction fees or authorization improvements available elsewhere. These ongoing costs include:
Missed optimization opportunities: Merchants can't easily test a competing acquirer's authorization performance using their existing card-on-file volume without first arranging access to the stored credentials.
Limited outage protection: Even with a backup PSP in place, merchants may be unable to reroute saved-card or recurring transactions if that provider cannot access the credentials needed to process them.
Weaker negotiating leverage: A merchant may find better processing rates elsewhere but struggle to act on them when moving its recurring billing volume requires a major migration rather than a routing change.
Revenue disruption: For subscription businesses and marketplaces, migration-related payment failures or requests for customers to update their card details can lead to lost transactions and involuntary churn.
Consider a subscription merchant with 500,000 stored cards. Switching PSPs may require coordinating a secure credential export, importing the data into the new provider's vault, updating customer records with new token references, and testing recurring payments. Each step requires time and technical resources, potentially alongside provider migration fees.
Ultimately, the cost of limited token portability isn't just what merchants spend to switch PSPs. It's the opportunities they lose when changing providers becomes too difficult.
The Token Portability AuditÂ
Your token vault should be a business asset — not a liability that limits your payment strategy.
Whether you're evaluating a new PSP, choosing a token vault provider, or planning a migration, these five questions can help you understand who controls your stored payment credentials — and how much flexibility you have to use them across providers.
1. Who issued the tokens?
Ask whether your tokens are proprietary PSP references or network tokens provisioned through the card networks. For network tokens, confirm who controls the token requestor ID (TRID) and access to the credentials.
2. What are your export rights?
Review your PSP contract for credential export rights, applicable fees, and migration procedures. If these terms aren't explicit, you may not have rights. Confirm in writing whether the provider supports secure bulk transfers of underlying payment credentials to another PCI DSS-compliant provider.Â
3. Are these actually network tokens?
If your PSP supports network tokenization, ask how it confirms successful provisioning and reports whether payments use a network token or fall back to the PAN. The reference you receive may still be a vault token that maps to a network token behind the scenes. Vault tokens and network tokens can work together, combining secure credential storage with network token benefits.
4. Can your target acquirer accept imported credentials?
Some acquirers require every customer to re-enter their payment details or complete additional authentication during migration. If customer action is required, be sure to assess the potential impact on your recurring revenue and churn rate.
5. Where does the vault sit?
Determine whether your tokens are stored within your PSP's infrastructure or in an independent provider-agnostic vault. If the vault sits at the payment orchestration layer rather than within an individual PSP, your stored tokens can remain accessible when you change providers.
How IXOPAY Supports Token Portability
The value of a token vault lies not only in future revenue tied to stored payment credentials, but also in its ability to optimize those future transactions.
That's where payment orchestration comes in. By connecting merchants to multiple payment service providers (PSPs) through a single platform, orchestration makes it easier to route transactions to the providers best suited to process them. Merchants can pursue higher approval rates, manage costs, and maintain payment continuity without depending on one PSP.
IXOPAY brings tokenization and orchestration together through a merchant-owned token vault that operates above the acquirer layer. Our universal tokens are independent of the PSP processing the transaction — so merchants can change routing decisions, add providers, or shift transaction volume without changing their stored credentials.
At the platform level, we provision network tokens through Visa Token Service (VTS), American Express Token Service (AETS) and Mastercard Digital Enablement Service (MDES) using merchant-assigned token requestor IDs (TRIDs). Merchants can request access to the underlying network tokens, helping reduce dependence on individual processors as their payment strategy evolves.
You shouldn’t have to choose between payment data ownership and performance. Our approach makes tokenization central to checkout strategy — enabling smarter routing, seamless PSP transitions, and continuous optimization without sacrificing control of stored credentials.
Learn more about IXOPAY's tokenization solutions.
The Right Time to Ask These Questions
Token vaults are more than a security and compliance consideration. With the rise of subscriptions, one-click checkout, and in-app payments, merchants today are sitting on substantial volumes of stored payment credentials that support recurring revenue.
The question is whether merchants have structured their tokenization strategy to protect that value. If changing payment providers or optimizing routing means rebuilding stored customer payment relationships, the vault becomes a barrier to growth rather than an asset that supports it.
The right time to assess token portability is before signing a PSP or vault agreement — not during renegotiation or migration. That means understanding who issues your tokens, what export rights you hold, and whether you can access genuine network tokens. It also means identifying where your vault sits in your payment architecture.
By combining a smart tokenization strategy with a provider-agnostic vault at the orchestration layer, merchants can pursue better processing terms, higher authorization rates, and greater resilience — all essential in today’s competitive payments landscape.
Explore IXOPAY's tokenization solutions to see how a provider-agnostic vault could improve your current stored credential position.
