Most payment architecture conversations start with the processor. Merchants spend considerable time evaluating authorization rates, pricing, and feature sets across Adyen, Stripe, Braintree, and others. The question of where credentials live tends to come later.
That’s understandable. PSP vaults are easy to adopt: your processor stores the card, returns a token, and the integration is done. For many early-stage businesses, that convenience is exactly what they need. But for merchants operating at scale across multiple brands, geographies, or payment methods, the decision about credential storage carries consequences that compound over time.
This piece is an attempt to lay out the tradeoffs clearly, without a predetermined answer. The right choice between a PSP and an independent vault depends on where you are and where you’re going.
Key Takeaways
- A PSP vault is simpler to set up and works well with a single processor in a single market.
- An independent (neutral) vault gives merchants full control over credential portability, multi-processor routing, and network token lifecycle management.
- The decision shifts toward a neutral vault as merchants add processors, brands, geographies, or other payment methods (like Apple Pay / Google Pay).
- Credentials stored in a PSP vault can create structural leverage for the PSP during migrations, renegotiations, or outages.
Why credential storage is an important strategic decision
Payment cards, network tokens, bank accounts, and wallet payloads are the foundation of every card-on-file transaction. Whoever controls those credentials has meaningful leverage over your payment relationships. That leverage is mostly invisible until you need to use it: when you want to add a second processor, renegotiate rates, expand into a new market, or recover from an outage.
The question isn’t simply “which vault is more secure” or “which integration is faster.” It’s: who should hold this strategic asset, and what are the implications of that choice over a three-to-five-year horizon?
What is a PSP vault?
First, let’s understand what a PSP vault is. A PSP vault is a tokenization and storage service provided by a payment processor such as Stripe, Adyen, or Braintree. When a customer enters their card details, the PSP encrypts the primary account number (PAN), stores it in its secure environment, and returns a processor-specific token to the merchant. That token can be used for future card-on-file transactions as long as the merchant continues using that PSP.
PSP vaults are included as part of the processor relationship and handle PCI DSS compliance for stored card data on the merchant’s behalf. They work well within a single-processor context and often integrate natively with the same provider’s dispute management, account updater, and network tokenization service.
What is an independent (neutral) token vault?
An independent token vault, also called a neutral vault or a service offered by an independent token service provider (TSP), like VGS, is a credential storage and secure proxy layer that sits between the merchant’s systems and any downstream payment processor. Customer PANs, network tokens, and wallet payloads are stored in the neutral vault under the merchant’s control. The merchant can forward to any PSP without PCI exposure.
PSP vault vs. independent vault: key differences
| Criteria | PSP Vault | Independent (Neutral) Vault |
|---|---|---|
| Ownership Model | Credentials owned and controlled by the processor | Credentials owned and controlled by the merchant |
| Processor Flexibility | Token only works with that PSP’s processing stack | Any PSPs can be added or swapped at any time |
| Network Token Control | Network tokens tied to PSP’s TSP ID, limiting portability | Network tokens managed by neutral vault TSP ID, enabling portability across PSPs |
| Routing & Forwarding | Forwarding to rival PSPs depends on PSP cooperation | Forwarding is processor-agnostic and reliable |
| Migration Complexity | Migration requires PSP engagement and timing | PSP migrations become a logistics event, not a negotiation |
| Wallet Support | Wallet credential forwarding typically limited | Unified handling of cards, tokens, wallets, and bank accounts |
| Operational Tradeoff | Lower integration overhead to get started | Additional integration investment required upfront |
When is a PSP vault the right choice?
A PSP vault is well-suited for merchants who meet most of the following criteria:
- Operating with a single primary payment processor and no near-term plans to add a second.
- Serving a single market or geography, where one processor covers the full transaction mix.
- Running a single consumer-facing brand without cross-brand credential sharing requirements.
- Not yet prioritizing mobile wallet acceptance at scale (Apple Pay, Google Pay).
- Seeking the fastest path to PCI compliance with minimal infrastructure investment.
When is an independent token vault the right choice?
The tradeoffs of a neutral vault become favorable when any of the following apply:
- Multi-processor routing: You route transactions across more than one PSP today, or expect to within 18 months.
- Network token portability*: You want network token lifecycle management, such as renewals, cryptograms, and updates, to survive a processor change.
- Multi-brand operations: Multiple consumer brands share customer relationships and need coordinated credential management.
- Global or regional expansion: Different markets require different processors, with consistent credential handling across all of them.
- Growing wallet volume: Apple Pay and Google Pay represent a material share of your transaction mix and are growing.
- Negotiating leverage: You want to add, swap, or pilot processors without triggering a credential migration event.
- Merchant partnerships: You can enable partner merchants to transact against stored credentials without sharing raw payment data or requiring customers to re-enroll.
- Seamless card-on-file experience: You can use a single credential to support both pay-ins and pay-outs, independent of processors that only handle one direction of fund flow.
*A note on network token portability: This is one of the least understood technical constraints in payment architecture. Network tokens issued by Visa, Mastercard, Amex, and Discover are provisioned via a Token Requestor ID (TRID). When a PSP provisions network tokens on a merchant’s behalf, that PSP acts as the Token Requestor Token Service Provider (TSP), responsible for webhook lifecycle events and cryptogram fetching. Even if the merchant uses their own TRID, they remain dependent on that PSP to receive token updates and cryptogram requests.
While network tokens can be exported to another provider, the new provider cannot support cryptogram fetch or lifecycle events on those network tokens. The merchant will need to export up-to-date card data to the new provider and that new provider would need to re-provision the network tokens so they can manage them on the merchant's behalf. At tens of millions of cards, this is a significant operational event that degrades authorization performance during the transition.
An independent vault provisions network tokens under a neutral TSP ID, making network tokens usable across any downstream PSP without needing to re-provision network tokens when adding new PSPs.
Questions to Evaluate Your Credential Architecture
- Migrating Tokens: If you moved 20% of volume to a new processor tomorrow, what would that require? How long would it take? Would your current PSP need to be involved, and would they have any incentive to cooperate quickly?
- Network Token Management: Where do your network tokens live, and what happens to them if you change processors? Who manages lifecycle events today, and who would manage them in a multi-processor scenario?
- Outage Response: If your primary PSP had a multi-hour outage during peak traffic, could you route to a backup? Or would cards-on-file be inaccessible until the primary PSP recovered?
- Expansion and Portability: If you added a new consumer brand, how would credential management work across brands? Would your vault support cross-brand routing, or would you be building a second silo?
- Auditability: What is your audit posture for stored credentials? Can you pull a complete access log for any given token? Do you have role-based controls over who can access credential data?
Making the Call
The credential storage decision is ultimately about control: how much of it do you need, and how much are you willing to invest in maintaining it?
For merchants at earlier stages, with a single processor and no near-term plans to change that, PSP vault simplicity is often the right trade. The overhead of a neutral vault, integration investment, an additional vendor relationship, and ongoing operational management doesn’t pay off until the complexity it manages actually exists.
For merchants at scale or scaling, particularly those with multiple brands, geographies, or processors in scope, the calculus shifts. The overhead of a neutral vault is fixed; the cost of credential fragmentation, forwarding friction, and migration events compounds over time. The merchants who are most constrained by PSP vault lock-in are rarely the ones who saw it coming; they’re the ones who outgrew the architecture before they thought to change it.
The best time to make this decision is before it becomes urgent. That’s when you have the clearest view of the tradeoffs and the most options available to you.
Own your credentials. Route to any processor. Avoid Vendor Lock-In. And Scale Your Business.
VGS is the independent vault built for enterprise merchants who need full control over their payment credentials, across processors, brands, geographies, and payment methods. One neutral vault for cards, network tokens, wallet payments, and bank accounts. No PSP dependencies. No lock-in.
