Payment Vault

What Is a Payment Vault?

A payment vault is a secure, isolated system that stores sensitive payment credentials: primary account numbers (PANs), expiration dates, and other cardholder data. When a customer's card is first captured, the vault encrypts and stores the real data, then returns a surrogate value called a token. The merchant's systems store and transmit only the token, never the underlying card number.

The core purpose is isolation. By keeping raw card data in a hardened, access-controlled environment separate from the merchant's application infrastructure, the vault limits the damage a breach can cause. If an attacker compromises the merchant's database, they obtain tokens that are useless outside the vault's ecosystem. The real card numbers remain protected behind the vault's security boundary.

Payment vaults are operated by payment processors, gateways, and dedicated vault providers. Major examples include Stripe's built-in vault, Braintree's vault, and standalone services like Basis Theory and Spreedly that offer vault-only products decoupled from payment processing.

How It Works

The vault sits between the customer's card data and the merchant's systems. Here is the typical flow for storing and using a card:

1. The customer enters their card number on a checkout page. In modern implementations, the card data is captured via a hosted payment field or iframe that sends it directly to the vault provider, so the merchant's servers never see the raw PAN.
2. The vault encrypts the PAN and other sensitive fields using strong cryptography and stores them in a PCI DSS-compliant database.
3. The vault generates a token: a non-sensitive reference string that maps to the stored credential. This token has no mathematical relationship to the original card number and cannot be reversed without vault access.
4. The merchant stores the token in their own database, associated with the customer record.
5. For future transactions (recurring charges, one-click checkout, or refunds), the merchant sends the token to the vault or payment processor. The vault detokenizes internally, substituting the real PAN for authorization with the card network.
6. The authorization response flows back through the processor to the merchant. The merchant never handles the real card number at any point.

Token Format

Vault tokens come in different formats depending on the provider. Some preserve the last four digits of the card and maintain the same length as the original PAN, which lets merchants display partial card information and route transactions through existing systems without schema changes. Others use entirely random alphanumeric strings.

// Example: storing a card in a vault via API
const response = await vaultClient.createToken({
  type: "card",
  data: {
    number: "4242424242424242",
    exp_month: 12,
    exp_year: 2028,
    cvc: "123"
  }
});

// Response contains a token, not the card number
// token: "tok_8a7f3b2c1d4e5f6g"
// last_four: "4242"

// Use the token for future charges
await paymentClient.charge({
  amount: 5000,
  currency: "usd",
  token: response.token
});

PCI DSS Scope Reduction

The primary business driver for payment vaults is PCI DSS compliance. Any organization that stores, processes, or transmits cardholder data must comply with the Payment Card Industry Data Security Standard. Full compliance requires meeting hundreds of security controls and undergoing annual assessments.

By offloading card storage to a vault, merchants remove raw card data from their own environment. Under PCI DSS v4.0, this can qualify a merchant for a simpler Self-Assessment Questionnaire (SAQ A) covering fewer requirements, rather than the comprehensive SAQ D or a full Report on Compliance (ROC). The scope reduction depends on how the payment page is built:

• Redirect to hosted checkout (card data never touches merchant domain): eligible for SAQ A, the lightest assessment
• Hosted fields or iframe on merchant page (card data captured by vault provider's JavaScript, but rendered on merchant domain): typically requires SAQ A-EP, which covers more requirements
• Server-side card handling before vaulting (merchant server briefly touches PAN): full SAQ D scope, negating most vault benefits

Scope reduction does not eliminate all PCI obligations. Merchants must still secure their checkout pages against script injection, train employees on data handling, and maintain endpoint security. Under PCI DSS v4.0, even merchants using hosted fields must inventory and monitor all JavaScript on their payment pages.

Gateway Vaulting vs. Network Tokenization

Payment tokenization comes in two distinct forms, and the difference matters for portability, approval rates, and lifecycle management.

Gateway or PSP Vaulting

When a payment processor or gateway operates the vault, the tokens it issues are proprietary to that provider. These gateway tokens can only be detokenized by the provider that created them.

• Tokens work only within the issuing provider's system
• If a card is reissued (new expiration date or replacement card number), the token does not automatically update: the merchant needs to use an account updater service to refresh stored credentials
• The vault provider controls access, creating vendor dependency

Network Tokenization

Network tokens are issued by the card schemes themselves (Visa Token Service, Mastercard Digital Enablement Service, American Express Token Service). These tokens are provisioned at the network level and have several advantages over gateway tokens:

• Automatic lifecycle management: when a card is reissued, the network token updates automatically, reducing failed recurring payments
• Higher authorization rates: issuers can verify that the token was provisioned legitimately, increasing trust in the transaction
• Domain restriction: network tokens can be bound to a specific merchant, so a stolen token cannot be used elsewhere

Many modern vault providers support both: they store the original PAN, provision a network token from the card scheme, and issue their own gateway token to the merchant. This layered approach gives merchants the approval-rate benefits of network tokenization while keeping the vault's interface consistent. For a detailed comparison, see the research article on payment network tokenization.

Use Cases

Card-on-File and Recurring Billing

The most common vault use case is card-on-file storage for returning customers and recurring billing. E-commerce platforms, subscription services, and SaaS companies vault a card during the first purchase, then charge the token for subsequent transactions. This enables one-click checkout without the merchant ever re-handling the raw card number.

Multi-Processor Routing

Merchants using payment orchestration route transactions across multiple acquirers or processors to optimize approval rates, fees, or regional coverage. A processor-agnostic vault stores the real credential once and presents it to whichever processor the orchestration layer selects, without each processor needing its own copy of the card data.

Omnichannel Payments

Retailers operating across web, mobile app, and in-store channels can vault a card once and reuse the token across all channels. A customer who saves their card online can use the same stored credential for a phone order or an in-app purchase.

Payment Method Migration

When merchants adopt new payment processors, a portable vault lets them carry existing stored credentials to the new provider without asking customers to re-enter their card details. This preserves conversion rates and avoids the churn that comes with a "please update your payment method" campaign.

Vault Portability Challenges

Vault lock-in is one of the most significant hidden costs in payment infrastructure. When a merchant stores millions of tokens with a single processor, switching providers becomes a high-stakes migration project.

• Provider-specific tokens are useless outside the issuing provider's system: the new processor cannot detokenize them
• Migrating real card data requires cooperation from the old provider, which may have limited incentive to facilitate a departure
• PCI DSS requirements apply to the migration itself: card data must be transferred via secure, compliant channels between two Level 1 PCI-certified entities
• Network tokens add complexity: migrating Visa or Mastercard tokens may require involvement from the card scheme to re-provision tokens under the new provider
• Transaction history and metadata may not transfer with the credentials, limiting the new provider's ability to optimize routing or fraud scoring

To avoid this lock-in, some merchants choose processor-agnostic vaults (Basis Theory, Spreedly, or Gr4vy) that store credentials independently and can route to any downstream processor. The tradeoff is an additional vendor in the payment stack and potentially higher per-transaction costs.

Risks and Considerations

Single Point of Failure

A vault concentrates all stored credentials in one system. If the vault experiences downtime, every stored-credential transaction fails: recurring charges decline, one-click checkout breaks, and refunds to original payment methods may be delayed. Vault SLAs should be evaluated as carefully as gateway and acquirer SLAs.

Vault Breach

While vaults are hardened environments, they represent a high-value target. A breach of the vault itself exposes all stored credentials at once. Defense in depth (encryption at rest with hardware security modules, strict access controls, tokenization within the vault itself, and audit logging) mitigates but does not eliminate this risk.

Tokenization Is Not Encryption

Tokens and encrypted values serve different purposes. Encryption is mathematically reversible by anyone with the key. Tokenization replaces data with a reference that has no mathematical relationship to the original: there is no key that can reverse a token without querying the vault's lookup table. This distinction matters for PCI DSS scope: encrypted card data still counts as cardholder data under the standard, while properly tokenized data does not.

Compliance Is Not Eliminated

Vaulting reduces PCI scope but does not remove it entirely. Merchants must still secure their payment pages against cross-site scripting, monitor third-party scripts, implement access controls, and maintain incident response plans. Under PCI DSS v4.0, requirements around script integrity and subresource monitoring on payment pages apply even to merchants using fully hosted solutions.

Why It Matters

Payment vaults are foundational infrastructure in traditional card payments, solving a problem that blockchain-native payment systems approach differently. In the card world, merchants must store sensitive credentials to enable repeat purchases, creating a custody and compliance burden. In crypto and stablecoin payments, there is no equivalent of a PAN to vault: payment credentials are public addresses, and authorization comes from private key signatures rather than stored card numbers.

This architectural difference is one reason stablecoin rails can reduce compliance overhead for recurring payments: there is no sensitive credential to store, no vault to maintain, and no PCI scope to manage. For businesses evaluating whether to add crypto payment rails alongside traditional card acceptance, understanding the vault layer and its costs provides useful context for comparing infrastructure requirements across payment rails.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.