What is a credit card vault?
How card vaulting works — in plain English.

CARD VAULT GUIDES · PUBLISHED OCTOBER 2026 · 9 MIN READ

A credit card vault is a secure, PCI DSS compliant system that takes a customer's card number off your hands: it captures the card, encrypts and stores it, and gives your business a token to charge instead. The number lives in the vault; your team, your files and your software only ever see the token and the last four digits. This guide explains how a card vault actually works, the difference between tokenization and encryption, the three kinds of vault you can choose from, what vaulting does to your PCI scope, and what to look for before you pick one.

The one-paragraph definition

Every business that keeps a card on file — for a hotel deposit, a monthly membership, a retainer, a standing order — has to put that card number somewhere. A credit card vault is the purpose-built somewhere. It is a hardened service whose only job is to hold payment credentials safely and let you use them without touching them. You send a customer to the vault to enter their card (or embed the vault's fields in your own page); the vault stores the card and returns a token; from then on you charge, verify or retire the card by referring to the token. If the vault is doing its job, the card number never appears in your inbox, your spreadsheet, your CRM or your database again.

How a credit card vault works, step by step

1. Capture. The customer types their card into a surface the vault controls: a hosted page reached by a secure request link, fields embedded in your checkout through an isolated frame, or a direct API call from a system that is itself in scope. The point is that the digits travel from the customer's browser to the vault, not through your servers.

2. Encrypt and store. The vault encrypts the card number with strong, modern cryptography and stores it under keys that your business never holds. Good vaults separate the people who run the database from the people who can touch the keys, rotate keys on a schedule, and keep every access in an audit log.

3. Tokenize. The vault hands back a token: a reference that means "this card" to the vault and means nothing to anyone else. Your systems store the token where they would once have stored the number. A stolen token is useless outside the vault that issued it.

4. Charge by token. When it is time to bill, your team (from a virtual terminal) or your software (through the API) tells the vault to charge the token for an amount. The vault retrieves the credential, sends the charge to your payment gateway, and returns the result. The card number was decrypted inside the vault for the duration of the request and nowhere else.

5. Manage the lifecycle. Cards expire, get reissued and get cancelled. A vault tracks that for you: expiry handling, card verification before a billing run, signed webhooks when a card changes, and clean deletion when the customer leaves.

Tokenization is not encryption

The two words get used interchangeably, and they are not the same thing. Encryption transforms the card number into ciphertext that can be turned back into the number by anyone holding the key. If your database stores encrypted card numbers, the key exists somewhere in your environment, and every system that can reach the key can reach the cards. Tokenization replaces the number with a reference that has no mathematical relationship to it at all. There is no key to steal; the only way back to the card is to ask the vault, and the vault decides who is allowed to ask.

The three kinds of credit card vault

Your payment processor's vault. Most gateways offer a "customer vault" or "stored cards" feature. It is convenient and often bundled in. The catch is that the token belongs to the processor: it only works for charges through that processor, and if you ever change gateways, every card has to be re-collected from every customer. The convenience is real; so is the lock-in.

A vault you build yourself. Technically possible, and the most expensive option by a wide margin. Storing card numbers makes your whole environment subject to the full PCI DSS standard: network segmentation, key management, quarterly scans, penetration tests, logging, access reviews and an annual assessment under the 250-plus question SAQ D. That is a permanent operating cost, not a one-time build.

An independent, processor-agnostic vault. A vault operated by a company whose only product is custody of the credential. The vault holds the card and routes charges to whichever gateway you connect; the token belongs to the vault, not to any processor, so you can add a second gateway, switch entirely or negotiate rates with the cards already in hand. It is the option that separates where the card lives from who processes the payment, and that separation is the whole point.

What a vault does to your PCI scope

PCI DSS scope is set by your riskiest workflow, not your average one. One emailed card form or one spreadsheet of client cards puts the computers, people and processes around it inside scope, and that usually means the full SAQ D. Moving capture, storage and transmission of card data into a vault takes the card data out of your environment entirely. Integrations that never let a card number touch your systems can qualify for SAQ A, the shortest self-assessment questionnaire there is, where the eligibility criteria are met. The plain-English guide to reducing PCI scope walks through exactly how that works and what still remains yours to do.

Two things a vault does not do: it does not make PCI disappear (how you integrate and operate still determines your final scope), and it does not need to keep the CVV to bill a card again. No compliant vault stores the security code; stored-credential billing was never built on it.

Card-on-file billing without the card

The reason a vault is worth having is what happens after the card is in it. Card networks distinguish the first, customer-present transaction — where the customer is at the keyboard and the CVV proves they hold the card — from merchant-initiated charges you run later against a properly stored credential. A vault manages that distinction for you: it records the customer's consent and the initial transaction, then lets you bill the token on schedule, on checkout, or when the invoice comes due, with no card number and no CVV in sight. The guide to recurring billing without storing cards covers the rules in detail.

Who needs a credit card vault

• Hotels, resorts and property managers holding cards for incidentals, deposits and owner billing — today often read across the front desk or over the phone. Card Vault for hospitality.
• Law firms, agencies and professional services charging retainers and recurring invoices from a card the client gave them once — today often in a spreadsheet. Card Vault for firms.
• Memberships, clinics, utilities and insurers — anywhere a card stays on file for monthly billing.
• Call centers and phone-order businesses, where card numbers end up on desks and in call recordings unless agents can send a capture link instead.
• E-commerce and SaaS platforms that want one-click repeat purchases and saved cards without taking on the PCI burden of storing them. Card Vault for developers.

What a credit card vault costs

Processor vaults are often bundled into the gateway fee, which is the honest reason they are popular. Independent vaults are usually priced by capacity: how many cards you keep on file, plus small per-call rates for metered operations such as card verification or API calls. Card Vault, for example, starts free for up to five cards and scales by vault size from there, with pricing on the home page. Compare any of those numbers with the cost of building and assessing your own: a full SAQ D programme runs to tens of thousands of dollars a year in staff time, scanning and assessment before a single card is stored.

How to choose a credit card vault

Whatever vendor you look at, ask these questions and get the answers in writing:

• Is the vault itself assessed as a PCI DSS service provider, and will they give you the Attestation of Compliance? A vendor that cannot produce an AOC is asking you to carry their risk.
• Who owns the token? If it only works with one processor, you are buying a processor's vault with extra steps.
• How do you get the cards out? A real vault supports a secure, PCI-compliant migration of your stored cards to another compliant vault or processor if you leave. No exit path means no independence.
• How does the card get in? Secure request links by email and SMS, hosted pages, embedded fields and an API — your least technical workflow is the one that decides whether the vault actually removes card numbers from your office.
• Who holds the keys? Look for segregated key custody, scheduled rotation and multi-tenant isolation, not just "AES-256" on a brochure.
• Can you prove what happened? Every token operation — create, use, update, delete — should be logged and reportable, so the vault supports your evidence collection instead of adding to it.
• Does it fit how you operate? A virtual terminal for the team, segments for multiple locations or properties, webhooks for your software, and a cardholder-agreement step that replaces the paper authorization form.

Frequently asked questions