Chapter 25 — Vaulting, Encryption & Tokenization

Where Do All Those Saved Cards Actually Live?

Pick up your phone and count. The food delivery app. The ride-hailing app. The streaming service. The airline. The online grocer. Each one cheerfully shows you "Visa ending in 4242" and offers to charge it with one tap.

By any reasonable guess, your card number is sitting in a dozen company databases right now.

Here's the twist: it almost certainly isn't. Most of those companies have never seen your card number, couldn't produce it if you asked, and would fail a court order demanding it. What they hold is a claim ticket — a token that points at your card, redeemable only through one specific counterparty. The card number itself lives in a small number of heavily fortified systems called vaults, run by people whose entire business is guarding them.

In Chapter 24 we covered the rules that make storing card data expensive. This chapter is about the machinery that lets almost everyone avoid doing it — and the engineering trade-offs hiding behind the word "vault."

What a Vault Actually Is

Strip away the vendor branding and a card vault is three things working together.

A hardened datastore. The PANs live encrypted in a database that accepts connections from almost nothing, logs everything, and sits on an isolated network segment. This is the Cardholder Data Environment from Chapter 24, shrunk to its smallest possible footprint and defended like a bank branch.

A key-management system. Encrypted data is only as safe as its keys, so serious vaults keep encryption keys inside Hardware Security Modules (HSMs) — physical devices built so that keys can be used but never extracted. The application can ask the HSM to decrypt a PAN; it can never ask for the key itself.

A mapping service. The vault's public face. Hand it a PAN, get back a token. Hand it the token (with the right credentials), and the vault either returns the PAN or — more commonly — uses the PAN on your behalf and never shows it to you at all.

Technical note — HSMs are certified against standards like FIPS 140-2/140-3, and key custody follows formal ceremonies: keys are generated inside the device, split into shares held by different officers, and rotated on a schedule. When a vault provider says "even we can't read your card data without the HSM," this is the machinery they're describing.

That's it. Everything else — dashboards, APIs, compliance paperwork — is packaging around those three parts.

Encryption and Tokenization Are Not the Same Thing

People use these words interchangeably. They shouldn't, because the difference decides what an attacker gets when things go wrong.

Encryption is reversible math. The PAN goes in, ciphertext comes out, and anyone holding the key can run the process backward. Encryption protects data if and only if the key stays safe — which means the key becomes the new thing you have to protect. Steal the database and the key, and you have every card.

Tokenization removes the data entirely. The token is a random stand-in with no mathematical relationship to the PAN; the only way back is the vault's lookup table. Steal a million tokens and you have a million meaningless strings — the secret isn't traveling with the data at all.

A useful mental model: encryption is writing your diary in a code that a clever enough thief could crack with the key; tokenization is leaving your diary at home and carrying a note that says "diary, page 34." The note is useless without access to your house.

Two refinements matter in practice:

Format-preserving tokens. Many vaults issue tokens shaped like card numbers — 16 digits, valid checksum, often preserving the first six and last four digits of the real card. Why? Because decades of merchant software expects a 16-digit number in that field. Format-preserving tokens let you swap tokenization into an existing system without rewriting every validation rule, database column, and receipt template. The last four digits surviving is also what lets your app display "Visa ending in 4242" without holding the card.

Both, layered. Real vaults tokenize outward (that's what you receive) and encrypt inward (that's how the PAN rests inside the vault). It's not either/or — it's tokenization as the interface, encryption as the storage.

The Three Places a Vault Can Live

Every merchant that stores cards makes a choice — sometimes deliberately, usually by default — about where the vault sits. There are exactly three options, and the differences compound for years.

Diagram: The Three Vault Homes. Same customer, same card — radically different compliance scope and switching costs depending on who holds the PAN.

Option 1: Build Your Own (Almost Certainly Don't)

Running your own vault means the full weight of Chapter 24 lands on you: SAQ D, the complete control set, HSMs, key ceremonies, segmented networks, annual assessments, and a security team that never sleeps. You've become a small, unlicensed version of the companies whose entire business is doing this.

Who actually does it? Payment processors themselves, large PSPs, some airlines and hotel groups with decades-old central reservation systems, and a handful of retailers big enough to employ serious security organizations. For them the economics can work: at sufficient volume, owning the vault means owning routing freedom and shaving processor fees.

For everyone else the math is brutal. You take on open-ended liability and a permanent compliance program to save a fee that a vault provider charges as a rounding error. The question to ask isn't "can we build it?" — of course you can — it's "do we want to be in the business of guarding card numbers?" Almost nobody does.

Option 2: Your PSP's Vault (The Default)

When you save a card with Stripe, Adyen, or Braintree, the PAN lands in the PSP's vault and you receive their token. This is what most businesses do, because it arrives free with the integration and shrinks your PCI scope dramatically — as we saw in Chapter 24, your systems hold tokens, not card data.

The catch is a single word: lock-in. A PSP token means something only to the PSP that issued it. tok_1abc2def is a Stripe fact, not a portable fact. Your saved-card relationships — every subscription, every one-click checkout — exist inside one vendor's walls.

This is not an accident of engineering. The vault is the PSP's best retention tool. Leaving means moving the cards, and moving the cards means a migration project (more on that below). The more card-on-file business you do, the stronger the gravity gets. It's a fine trade for most companies — but make it consciously, understanding that your card portfolio is becoming part of someone else's moat.

Option 3: The Independent Vault (Portability as a Product)

The third pattern — pioneered by providers like VGS and Basis Theory — inserts an independent vault between you and your processors. We saw its proxy mechanics in Chapter 24: card data flows through the vault's proxy on the way in (you receive a token) and the vault re-injects the real PAN on the way out to whichever processor you name.

Read that last clause again, because it's the whole product: whichever processor you name. The token isn't locked to Stripe or Adyen — it's locked to the vault, and the vault will happily fire the PAN at any endpoint you configure. Add a second processor for redundancy? Same tokens. Negotiate better pricing and switch acquirers? Same tokens. Route European cards to a European acquirer? Same tokens.

The costs are real: another vendor in your critical path (if the vault proxy is down, you can't charge anyone), another contract, per-call fees, and some added latency on every transaction. And you've centralized trust in the vault provider itself — so their certifications, uptime record, and financial health become your due diligence problem.

The rule of thumb: single processor, standard needs — the PSP vault is fine. Multi-processor ambitions, heavy card-on-file business, regulated industry, or serious negotiating leverage on your roadmap — the independent vault pays for itself. (This choice reappears at full strength in Chapter 31, because vault independence is what makes payment orchestration possible at all.)

Table 1: Choosing a Vault Home. The PSP vault wins on convenience; the independent vault wins on freedom; building your own wins almost never.

Wait — Isn't This What Network Tokens Do?

If you're thinking back to Chapter 12, a fair question: the card networks already run a tokenization system. Visa and Mastercard issue DPANs that stand in for real cards, update themselves when cards are reissued, and work across processors. Why does anyone need a merchant-side vault?

Because the two systems solve different problems, and they stack rather than compete.

Network tokens (Chapter 12) are the networks' vault — they protect the credential inside the card system itself, bind tokens to a specific merchant, and shine at keeping card-on-file credentials fresh. But you still need somewhere to keep the network token, the cryptogram plumbing, and every other payment credential you hold — bank account numbers for direct debit (Chapter 20), wallet references, and cards in markets where network tokenization isn't available.

Merchant-side vaults (this chapter) are your credential store — one place that holds whatever payment instruments your customers give you, whatever rail they belong to, and hands you back uniform tokens your systems can treat as ordinary data.

In a mature setup they compose: your vault stores the PAN, requests a network token from Visa for the recurring relationship, stores that too, and your billing system holds a single vault token pointing at the whole bundle. Belt, suspenders, and a coat.

Breach Economics: Why the PAN Is Toxic Inventory

Here's the reframe that makes every architecture decision in this chapter obvious: stored card numbers are not an asset. They're inventory that can explode.

A warehouse full of PANs earns you nothing extra day to day — tokens process payments just as well. But its downside is spectacular. When card data leaks, the bill arrives from every direction at once: forensic investigators (mandatory, at your expense), card network fines flowing through your acquirer (Chapter 24), the cost of reissuing every exposed card (which issuers push back onto you), class-action exposure, breach notification obligations in every affected jurisdiction, mandatory reclassification to PCI Level 1 with years of QSA audits — and the quiet, permanent tax of customers who no longer type their card number on your site.

The TJX and Heartland stories from Chapter 24 put dollar figures on this in the hundreds of millions. The exact numbers vary by breach; the shape never does. The liability is concentrated, sudden, and wildly disproportionate to whatever convenience storing the PAN bought you.

Now run the same ledger for a company that vaulted everything: the attacker who compromises your systems finds tokens. Tokens locked to your merchant account, useless on the dark web, individually revocable with an API call. The breach is still bad — customer emails and order history hurt — but the card dimension of the disaster simply isn't there. Nothing was stored, so nothing was stolen.

That's the entire logic of this chapter compressed to one line: you cannot leak what you do not hold. Security teams call the broader principle data minimization. CFOs should call it what it is — liability that never lands on your balance sheet.

The Exit Door: Vault Migration and Portability

Everything above assumed you're choosing a vault. One more scenario matters — the one nobody thinks about until it's urgent: leaving.

Say you've been on one PSP for five years. Forty thousand active subscriptions, every card in their vault, and their new pricing proposal is insulting. You want to switch. What happens to the cards?

The good news: you are not actually trapped. Card networks require that merchants be able to take their cardholder data to a new provider, and reputable PSPs support PAN export — a formal migration where your old PSP transfers the vaulted card data directly to your new PSP's vault (or an independent vault) through an encrypted, PCI-controlled channel. The data never touches your systems, so your scope stays clean.

The realistic news: it's a project, and the friction is asymmetric by design.

• It takes weeks, sometimes months. Export requests go through security review on both sides, key exchange between the two vaults, batch transfer, and validation. Your old PSP has no commercial incentive to hurry.
• CVVs don't come along — ever. As Chapter 24 explained, security codes can't be stored after authorization, by anyone. Post-migration charges are merchant-initiated transactions on stored credentials, which is fine — but only if your mandate and stored-credential flags (Chapter 16) are set up correctly on the new side.
• Not everything maps cleanly. Expired-card updates the old PSP applied, network tokens provisioned under their relationships (those need re-provisioning — Chapter 12), and metadata like your subscription-to-card links all need careful re-stitching. The PANs migrate; the history often doesn't.
• Some data may simply be missing. If cards were captured through certain wallet flows, the vault may hold a DPAN rather than a real PAN, and what you can export depends on scheme rules.

Three habits turn this from a crisis into a chore. Negotiate the exit before you enter — put data portability, export cooperation, and timelines in the contract while you still have leverage; a PSP's answer to "how do I leave?" tells you more than any sales deck. Keep your own map — even with zero card data, you can safely store which token belongs to which customer and subscription, so migration is a re-pointing exercise instead of archaeology. Or opt out of the problem entirely — the independent-vault pattern above exists precisely so that switching processors never again involves moving a single card.

What Comes Next

We've now covered the defenses around card data: the rules (Chapter 24) and the machinery (this chapter). But payment security has a second front that has nothing to do with storage. Every transaction — even one flowing through a perfect vault — carries a different kind of risk: is this purchase fraud? Is this customer laundering money? Is this merchant about to be off-boarded by its own PSP?

In Chapter 26, we turn from protecting the data to policing the flow — fraud engines, velocity rules, KYC, sanctions screening, and the monitoring systems that decide, hundreds of times a second, whether money is allowed to move.

Sources

• PCI Security Standards Council — PCI DSS v4.0.1 and Tokenization Product Security Guidelines
• NIST — FIPS 140-2 / 140-3, Security Requirements for Cryptographic Modules
• EMVCo — EMV Payment Tokenisation Specification (network token context)
• Visa and Mastercard rules on cardholder data portability between acquirers/PSPs
• Stripe, Adyen, and Braintree documentation on PAN import/export and card migration
• VGS and Basis Theory technical documentation on vault proxy architecture
• Verizon Data Breach Investigations Report (breach cost and pattern context)