Every subscription platform eventually faces the same hidden cost: the moment you need to switch or add a payment provider, your stored credentials may not travel with you. If your tokenization approach is tied to a single processor, those tokens are that processor's asset, not yours. The credential portability problem is live, expensive, and almost never visible until a migration is already underway.
This post is about the architectural gap between a card vault and a true tokenization platform built on network tokens. The gap looks technical. The financial exposure is not.
Key Takeaways
- PSP tokens are gateway-scoped: they are invalid outside the issuing processor's vault, making multi-acquirer routing on stored credentials impossible without re-tokenization.
- Network tokens, issued by Visa or Mastercard directly, are portable across any acquirer and auto-update when cards are reissued, eliminating the primary cause of recurring payment declines.
- Subscription platforms that migrate off a PSP without network tokens typically recover only a fraction of stored credentials before involuntary churn accelerates.
- Yuno's tokenization platform holds network tokens independently of any acquiring relationship, so smart routing can present the same token to whichever PSP offers the best approval rate at that moment.
- The authorization rate advantage from network tokens on recurring transactions is structural, not incremental: issuers treat network tokens as higher-confidence credentials than static PANs or gateway tokens.
What Is a Card Vault, and Where Does It Stop?
A card vault is a secure storage layer that replaces raw card numbers with a reference token, reducing PCI scope for the merchant. It solves a compliance problem elegantly, and for merchants processing one-time transactions through a single processor, it solves enough.
The architecture works like this. A customer enters their card at checkout. The vault encrypts the PAN, stores it, and returns a gateway token. That token is an alias that only the vault provider can resolve back to a real card number. Every subsequent charge presents the token, not the PAN.
The limit is embedded in that last sentence. The token resolves only inside the vault provider's system. Present it to a different acquirer and it means nothing. The credential is effectively owned by the processor, not the merchant.
For a business running a single PSP relationship with low recurring volume, this trade-off is invisible. For a SaaS or subscription platform processing millions in recurring revenue across multiple markets, it is a structural liability.
How Does PSP Token Lock-In Actually Hurt Subscription Revenue?
PSP token lock-in creates two distinct revenue risks: authorization rate decay and migration cost. Both scale with the size of the stored credential base.
Authorization rate decay happens because PSP tokens represent a static card number at the moment of initial tokenization. Cards get reissued. Numbers change after fraud events. Expiry dates pass. The token does not update. Each of these events creates a potential false decline on the next billing cycle, and the merchant has no automated path to recover the credential short of contacting the cardholder.
Migration cost is the more acute risk. When a subscription platform needs to add a second acquirer for geographic coverage, or exit a PSP relationship for cost or performance reasons, PSP tokens cannot transfer. The practical outcome is that the merchant must either stay with the underperforming processor to preserve stored credentials, or accept significant subscriber churn during a forced re-enrollment campaign. Neither is a good option at scale.
We have seen this play out consistently in our work with enterprise subscription platforms. The decision to evaluate a new PSP gets made at the commercial level. The token lock-in issue surfaces during technical due diligence, often too late to change the migration timeline. The result is that commercial optionality and tokenization strategy end up in direct conflict.
What Makes Network Tokens Architecturally Different?
A network token is issued by the card scheme itself, Visa or Mastercard, rather than by the payment gateway. Because the issuing authority is the network, the token is recognizable to any acquirer that connects to that network.
The portability implication is fundamental. A network token can be presented to any acquirer in Yuno's routing layer. When smart routing selects a different PSP for a recurring charge, because approval rates are higher for a given BIN range or because the primary processor is experiencing latency, the same token travels with the transaction. No re-tokenization. No credential gap.
The lifecycle management implication is equally important. Visa and Mastercard operate token service providers that maintain a real-time mapping between the network token and the current underlying PAN. When a card is reissued after a fraud event, the token service provider updates the mapping automatically. The merchant sees continuity. The billing cycle fires without a decline. The cardholder never needs to re-enter their card.
Independent analysis of merchants operating network tokenization at scale consistently shows 3-8% higher approval rates on recurring transactions compared to static PSP tokens, driven by the issuer's recognition of updated credentials and the network's cryptographic authentication signal (thefinrate.com, May 2026). That is not a marginal optimization. For a platform billing $200M annually in recurring revenue, a 3% authorization rate lift translates to recovered revenue that compounds every billing cycle.
Card Vault vs Tokenization Platform: The Structural Comparison
The distinction between a card vault and a full tokenization platform is a question of token scope, lifecycle management, and acquirer portability. A vault is one component of a tokenization platform, not the whole architecture.
Consider the key differences across the dimensions that matter for multi-PSP operations:
- Token issuer. A gateway vault issues proprietary tokens scoped to one processor. A tokenization platform issues or proxies network tokens from Visa or Mastercard, making them scheme-recognized and acquirer-portable.
- Lifecycle updates. Gateway tokens do not self-update. Network tokens receive automatic updates when cards are reissued, expiry dates change, or account numbers rotate after fraud.
- Multi-acquirer routing. Gateway tokens cannot be presented to a different acquirer. Network tokens can be routed to any acquiring relationship without re-tokenization.
- Migration risk. Exiting a PSP that holds gateway tokens means losing access to credentials stored in that vault. Exiting a PSP relationship when tokens are network-issued and held independently carries no credential risk.
- Authorization rate signal. Issuers treat network tokens as higher-confidence credentials. The cryptographic authentication that accompanies a network token transaction is a positive signal that static PANs and gateway tokens cannot replicate.
- PCI scope reduction. Both approaches reduce PCI scope. Network tokenization eliminates the PAN from the merchant environment more completely because the token cannot be reverse-engineered outside the scheme's token service provider.
The practical consequence for a SaaS platform is this: a card vault gives you security. A tokenization platform that operates on network tokens gives you security plus the freedom to optimize your acquiring stack without destroying your recurring revenue base.
Why Most Merchants Do Not Know They Are Locked In
PSP-native token lock-in is invisible during normal operations, which is exactly why it persists. The merchant processes charges, approval rates look acceptable, and nothing surfaces the architectural constraint until a migration becomes necessary.
The market is moving toward greater merchant awareness of this issue. Recent research suggests that while the majority of enterprise merchants use tokenization in some form, a small fraction operate with a fully interoperable, acquirer-independent vault (based on publicly available market analysis). The gap between "we use tokens" and "we own portable tokens" is where lock-in lives.
A competitor currently educating the market on card vaults frames portability as a feature of their specific vault product. That framing obscures the underlying architectural question: where does the token resolve, and under whose authority? A vault product operated by a payments SaaS vendor is still a proprietary token namespace. The merchant is trading PSP lock-in for a different vendor's lock-in, unless the vault explicitly proxies network tokens from Visa and Mastercard.
The right question for any head of payments evaluating a tokenization approach is not "do we have a vault?" It is "can our stored tokens be presented to any acquirer, today, without calling our current PSP?"
How Yuno's Tokenization Platform Removes the Lock-In Constraint
Yuno holds network tokens independently of any acquiring relationship, so the token layer is never bound to a single PSP. This is a deliberate architectural decision, not a feature add-on.
Yuno does not sell acquiring. That neutrality matters here. A financial infrastructure platform with its own acquiring rails has a structural incentive to keep tokens inside its own vault. Yuno's routing recommendations and token management are unaffected by that incentive because there are no proprietary rails to protect.
In practice, this means a subscription platform using Yuno can route a recurring charge to whichever of its connected PSPs offers the best approval rate for that specific BIN, currency, and card brand, using the same network token every time. Smart routing lifts authorization rates by 8% on average across our platform (Yuno platform data). When that routing operates on portable network tokens rather than gateway tokens, the improvement compounds: better routing logic plus better credential quality plus issuer-side lifecycle updates.
Arcos Dorados, the world's largest McDonald's franchisee, unified payment operations across 21 countries on Yuno's infrastructure, with network tokenization strengthening recurring payment performance across key markets. The scale required a tokenization architecture that could operate across multiple acquirers in each country simultaneously, which a single PSP vault architecture could not support.
inDrive expanded into 10 new countries using Yuno's infrastructure and reached a 90% payment approval rate, operating across 300+ payment methods with routing that depends on tokens traveling cleanly across acquirer relationships (Yuno customer data).
What Should a CTO or Head of Payments Do Right Now?
Three audits are worth running before the next PSP negotiation cycle starts:
- Token ownership audit. Ask your current tokenization provider: do our stored tokens resolve outside your vault? If the answer is no, or involves a conversion process, you have gateway tokens, not network tokens. Quantify the stored credential base to understand the migration exposure.
- Authorization rate by token type. If you have any network tokens in circulation alongside gateway tokens, compare approval rates on recurring charges by token type. The authorization rate signal is measurable and typically visible within two billing cycles.
- PSP switch scenario planning. Run a thought experiment: if you needed to move 30% of recurring volume to a new acquirer tomorrow, what percentage of stored credentials would transfer without re-collection? If the answer is not 100%, that gap is your actual lock-in exposure.
The tokenization platform conversation is not a compliance conversation. It is an optionality conversation. Subscription platforms that solve it before a migration becomes urgent retain the ability to optimize their acquiring stack on commercial and performance terms. Those that solve it during a migration negotiate from weakness.
Yuno connects to 1,000+ payment methods across 200+ countries through a single API. Network token portability is built into the routing layer, not bolted on. If your current architecture limits where your stored credentials can go, that is worth fixing before the next PSP contract renewal lands on your desk.
