Token Vaults: Why Your Customer Cards Shouldn't Live Inside Your PSP

Ask a subscription merchant what their most valuable asset is and they will say the customer file. Then ask where the payment credentials for that customer file actually live. For most merchants the honest answer is: inside a processor that can terminate them with an email. If Stripe shuts you down tomorrow, your customers still love you, your product still works, and you still cannot charge anyone. The cards are gone, locked in a vault you never controlled. A token vault that sits outside your PSP is how you make sure a processor decision never becomes an extinction event. Here is how tokenization actually works, why PSP-held tokens are a trap for high-risk merchants, and what your realistic options look like at around $100K/month.

What Tokenization Actually Is

Tokenization replaces a card number (PAN) with a substitute value, the token, that is useless to anyone who steals it. The real PAN lives in a secured vault; your systems only ever touch the token. There are three distinct flavors, and conflating them causes expensive mistakes.

Gateway and PSP tokens

When you save a card in Stripe, Braintree, or Authorize.net, the PSP stores the PAN in its vault and hands you back its proprietary token. That token only works when submitted back to the same PSP. This is the default for almost every merchant, because it is free and automatic.

Network tokens

Visa and Mastercard operate their own tokenization services. A network token is issued by the card network itself, is tied to the specific merchant, and updates automatically when the underlying card is reissued. Network tokens can improve authorization rates and reduce declines from expired or reissued cards. But a network token is provisioned through a token requestor, and if your only requestor is your PSP, you still have a portability problem.

Vault-agnostic tokens

An independent vault provider stores the PAN and issues you a token that is not tied to any processor. When you want to charge the card, the vault injects the real PAN (or a network token) into an API call to whichever gateway or acquirer you choose. This is the architecture that matters for high-risk merchants, because it decouples where cards are stored from where transactions are processed.

The PSP Lock-In Problem

PSP tokens are convenient right up until the moment you need them most.

When an aggregator terminates a high-risk account, three things typically happen at once: processing stops, payouts freeze for a trailing chargeback window, and your saved cards become inaccessible for new charges. We walk through that sequence in why processors shut down high-risk accounts, but the token angle deserves its own emphasis.

Most large PSPs do support PCI-compliant data portability. Stripe, for example, will export card data to another PCI DSS Level 1 processor on request. But there are real catches for a terminated high-risk merchant. The export goes processor-to-processor, so you need the receiving compliant environment already stood up. The process takes time you do not have when revenue is stopped, and timelines are at the PSP's discretion, not yours. Some processors and billing platforms are far less cooperative than Stripe, and terms vary. And subscription metadata (billing schedules, retry state, dunning history) often does not travel with the cards, so even a successful export can mean rebuilding your billing logic from scratch.

For a subscription or continuity business, the math is brutal. Every card you cannot rebill is churn you did not earn. An asset you cannot move on your own timeline is not really your asset.

What an Agnostic Vault Changes

Moving credentials into an independent vault changes three things structurally.

PCI DSS scope

Storing PANs yourself puts you in the deepest tier of PCI DSS compliance, which is a serious ongoing engineering and audit burden. Vault providers solve this the same way PSPs do: card data flows from the customer's browser directly into the provider's certified environment via hosted fields or iframes, so raw PANs never touch your servers. You keep the reduced compliance scope you had with your PSP, typically validating with a short self-assessment questionnaire rather than a full audit, while gaining control over the credentials.

Portability

The vault token works with any endpoint the vault can reach. Add a new gateway, and your entire card file can transact through it the same day, with no migration. Leave a provider, and most independent vaults will export your data to another PCI-compliant environment, because portability is their selling point rather than a retention lever.

Migration is a one-time cost

Getting existing cards out of your current PSP means requesting a PCI-compliant transfer into the vault provider's environment. Vault providers handle these imports routinely and will run the process with your PSP. Do this while your account is in good standing. A migration that takes a few weeks when you are healthy becomes a crisis project when you are terminated.

How a Vault Enables Routing and Failover

Once credentials live above your processors, the vault becomes the foundation for everything we describe in our MID load balancing guide.

Routing: a transaction can be sent to any of your merchant accounts based on rules (volume caps, ticket size, geography, BIN), because every MID can reach the same stored credential.

Cascading: when one route declines with a retryable code, the same token can be retried on a different acquirer within seconds. Knowing which decline codes are safe to cascade is what separates smart failover from attempt-count abuse.

Failover: if a processor freezes you, you repoint traffic at your backup MID by changing a routing rule. Recurring billing continues. Your customers never know.

Without a vault, every one of those capabilities is impossible, because the credentials are captive to a single processor.

Practical Options at $100K/Month

At around $100K/month you are big enough to justify real infrastructure and small enough that enterprise pricing hurts. The market breaks into three categories.

Category	What it is	Examples	Best for	Trade-offs
Universal token vault	API-first vault; you build routing on top	Basis Theory, VGS, TokenEx	Teams with engineers who want maximum control	You write and maintain the routing logic
Orchestration layer	Vault plus routing, cascading, and retries in one platform	Spreedly, Primer	Merchants who want failover without building it	Less flexibility; platform fees on top of processing
High-risk multi-MID gateway	Gateway built for high-risk with vaulting and MID cascading	Common in the high-risk ISO channel (e.g., NMI-based gateways)	Merchants already working with high-risk providers	Quality varies widely; vet token portability terms first

We are deliberately not endorsing a vendor here, because the right answer depends on your stack, your industry's risk profile, and your engineering capacity. Whatever you evaluate, ask three questions before signing. Who legally controls the tokens, and what does offboarding look like in the contract? Does the provider support network tokens with itself as the token requestor, so network-token benefits travel with you? And can it reach the specific high-risk acquirers you are likely to use, not just the mainstream PSPs?

Practical Takeaway

If your saved cards live only inside your PSP, you are one risk-team decision away from losing your recurring revenue, and the time to fix it is while your account is healthy. The order of operations: pick a vault or orchestration provider, stand up hosted fields so new cards flow into the vault from day one, then run a PCI-compliant migration of your existing card file from your PSP. From that point on, your PSP is a route, not a landlord. Processors will keep making processor decisions. Your customer file should not be collateral when they do.