To store credit card information securely, a business captures cards through a secure form or phone system, replaces each card number with a token, keeps the real number in a PCI-certified vault and never stores the CVV.
Plenty of businesses need a customer's card long after the first conversation.
A travel agent books an independent hotel three weeks after the client approves the trip. A private club charges dues every month, and a law firm draws down a retainer. A clinic runs a patient's payment plan, while a property manager holds a card for a security deposit.
The card has to be usable later. Keeping it safe in the meantime is where most teams get stuck.
Card photos arrive on WhatsApp. Authorization forms pile up in an inbox. Numbers get typed into CRM notes or read aloud on recorded calls. Owners building their own booking app don't want a card number anywhere near their server, yet staff still need the card when a supplier asks for it.
We hear these questions regularly, from small travel agencies to growing software platforms. In this guide, we'll cover what PCI DSS lets you store, where cards should never sit and how to keep cards usable without letting them touch your systems.
What Credit Card Information Can a Business Store?
A business can store the card number, cardholder name, expiration date and service code if they're protected under PCI DSS, but it can never store the CVV, PIN or full magnetic stripe data after authorization.
PCI DSS splits card data into two groups. Cardholder data can be stored when it's protected. Sensitive authentication data can't be stored at all once a payment is authorized, even in encrypted form.
| Data element | Can it be stored? | What PCI DSS requires | How it works in practice |
|---|---|---|---|
| Card number (PAN) | Yes | Must be made unreadable wherever it's stored, and shown with no more than the first six and last four digits | A booking app keeps tok_c7Rn4Wz1Hd and "Visa ending 1111" while the real number sits in a vault |
| Cardholder name | Yes | Needs protection when it's kept together with the card number | A club's member record shows the name, and only the vault links that name to a card |
| Expiration date | Yes | Falls under the same protection as the card number it belongs to | The vault keeps the date so next month's dues charge goes through without asking the member again |
| Service code | Yes | Protected alongside the card number, though few merchants ever need it | Most phone and online businesses never collect it at all |
| CVV or CVC | No | May be held only until the payment is authorized, then removed, even if it was encrypted | A vault can keep the code for the first charge and delete it within minutes |
| PIN or PIN block | No | Never kept by the merchant under any circumstances | Phone and online businesses don't handle PINs, since they're entered on card-present terminals |
| Full magnetic stripe or chip data | No | Can't be retained once the transaction is authorized | A store's terminal passes it to the processor, and nothing is saved on the merchant's side |
Two more rules shape every storage decision. A displayed card number can show the first six and last four digits at most. Stored card data also needs a defined retention period, so nothing stays longer than the business needs it.
The full requirements sit in the PCI SSC document library.
Where Should Credit Card Information Never Be Stored?
Credit card information should never be stored in paper forms, email, spreadsheets, CRM notes, call recordings, chat tools or a company's own application database, because none of them is built to protect card data.
Most card leaks start with a shortcut. Someone needs the card later, so it gets saved wherever is quickest. Here's where cards usually end up, what that causes and how tokenizing the card changes the picture.
| Where it gets stored | Real-world example | What happens because of it | How tokenizing the card fixes it |
|---|---|---|---|
| Paper authorization forms | A hotel's front desk keeps signed forms from corporate travel bookers in a binder | Anyone near the desk can read, copy or photograph the card | The booker enters the card on a secure link, and the hotel keeps a token with the signed record |
| Email inboxes | A travel agency's clients email card details for each trip | The number sits in inboxes, sent folders, backups and forwarded threads for years | The client enters the card once on a hosted form, and only the token reaches the agency |
| Spreadsheets | A private club tracks members' cards for monthly dues in a shared sheet | Files get downloaded, shared and synced to personal laptops | Each member's dues charge runs from a token, and the sheet holds only the last four digits |
| CRM or booking notes | A law firm pastes a client's retainer card into the matter notes | Every user who opens the record can read the full number | The matter record stores a token that's useless to anyone browsing it |
| Call recordings | A home services dispatcher repeats the card back to the caller | The number lands in audio files and transcripts that stay searchable | The caller types the card on their keypad, so nothing sensitive is spoken |
| Chat and messaging apps | A property manager receives a tenant's card photo for a deposit on WhatsApp | The image stays on a personal phone and in cloud backups | A secure link replaces the photo, and the tenant record holds a token |
| Your own app database | A small agency stores cards in the database behind its WordPress booking site | Servers, logs and backups all fall into PCI scope, and a breach exposes every card | The app stores tokens, while the cards sit in a vault outside your environment |
That last row surprises many owners. A small agency building its own booking platform on WordPress or Replit often assumes encryption in its own database is enough. It isn't, because the application still handles the card number, and that pulls the whole stack into PCI DSS.
The pattern is the same in every row. The card lives where people and tools can reach it. Tokenizing at the moment of capture moves the card into a vault built for it, and leaves your team with a reference that can't be misused.
How to Securely Store Credit Card Information: Step-by-Step
Securely storing credit card information means capturing the card outside your systems, tokenizing it instantly, encrypting it inside a vault, saving only the token and controlling how the card is charged, revealed and deleted.
Before any card is stored, confirm you actually need it for a later charge, and record what the customer agreed to. Then the card moves through a vault in eight steps. Here's how it works with Enigma's Card Vault.
Step 1: Capture the Card Through a Secure Channel
The card should go from the customer straight to the vault. There are three common ways to do that:
- Hosted or embedded form: A card form loaded from the vault sits inside your website or checkout as an iframe, so the number is typed into the vault's page, never yours.
- Phone keypad: For phone bookings, the caller types the card on their keypad through an IVR connector such as Twilio Pay, and agents never hear it.
- Server-side API: Platforms with their own capture flow send the card to the vault in one authenticated call.
A travel agency taking a cruise deposit by phone and a SaaS platform adding card-on-file to its checkout use different channels, but in both cases the card skips their staff and servers.
Step 2: Tokenize the Card the Moment It's Captured
As soon as the card reaches the vault, it's swapped for a token. With a hosted form, the token comes back to your page through a browser callback, so your backend only ever sees something like tok_c7Rn4Wz1Hd.
You can watch this happen yourself. Try the Card Vault live demo with the test card 4111 1111 1111 1111, and see the token come back in place of the number.
Step 3: Encrypt and Store the Card Inside the Vault
Here's where the card actually lives. Inside the vault, each card field is encrypted with AES-256, using a unique initialization vector per field. Every customer has its own encryption keys in a managed secrets store, rotated on a schedule and never shared with another customer.
Tenants are isolated from one another, and the vault runs in US and EU regions. Your team never manages a key, which removes one of the hardest parts of PCI DSS from your plate.
Step 4: Save Only the Token in Your Own Systems
Your CRM, booking tool or billing system stores the token, the card brand and the last four digits. That's enough for a clinic's front desk to confirm "the Visa ending 1111" with a patient.
If an older system rejects anything that doesn't look like a card number, a format-preserving token keeps the first six and last four digits and passes the same Luhn check, so nothing downstream breaks.
Step 5: Handle the CVV Separately and Let It Expire
The security code can help authorize the first charge, but PCI DSS forbids keeping it afterward. In Card Vault, the CVV is held encrypted for 30 minutes at most, then deleted.
When a supplier asks for the code on a later booking, a CVV-only hosted form collects it again at that moment.
Step 6: Charge the Card Without Touching It
When it's time to bill, your app sends a request with placeholders where the card number, CVV and expiry would go. The vault's payment proxy fills in the real values and forwards the charge to your gateway, whether that's Authorize.net, Stripe, Braintree or PayPal.
A property manager's monthly rent run works this way. The rent goes through, and no one in the office or the software ever sees the tenant's card.
Step 7: Control Who Can Retrieve or Reveal the Card
Every request to the vault uses OAuth2 credentials scoped to specific actions, and every request is logged. Most services only need to store cards and charge them.
When a person needs the full number, such as a travel agent typing a card into a hotel's portal, the reveal happens inside the vault's own interface, behind multi-factor sign-in, and each reveal is recorded. Pulling raw card numbers into your own app is possible, but it brings that app back into PCI scope.
Step 8: Set an Expiry and Delete Cards You No Longer Need
A card collected for one booking shouldn't stay on file for years. Each stored card can carry an expiry, from 60 seconds up to seven years, and cards can be deleted on request. Once this flow is in place, ask your acquirer or QSA which self-assessment questionnaire fits your setup. Treat any shorter questionnaire as something they confirm, whatever a vendor's marketing says, ours included.
Tokenization vs Encryption vs Truncation: Which Storage Method Is Best?
Tokenization is the best storage method for most businesses, because it removes the card number from company systems, while encryption keeps it in place and truncation or hashing make it unusable for later charges.
PCI DSS accepts four ways to make a stored card number unreadable. The easiest way to see the difference is to store the same card, 4111 1111 1111 1111, each way:
| Method | What sits in your database | What a stolen copy gives an attacker | Can you charge it later? |
|---|---|---|---|
| Encryption | Ciphertext such as 9f3a7c2e81b4d6f0, plus a key somewhere in your environment | The card, if the key leaks too | Yes, after decrypting |
| Tokenization | tok_c7Rn4Wz1Hd | A random string; the card sits in a separate vault | Yes, through the vault |
| Truncation | 411111******1111 | Partial digits only | No |
| One-way hashing | A fixed value such as a3c91f07be2d84e6c5f2 | A value attackers may crack by guessing, since card numbers follow known patterns | No |
Now picture a clinic's billing database being copied in a breach.
With encryption, the attacker holds ciphertext and goes looking for the key. That key often lives on the same server, in a configuration file or in the hands of the developer who set it up. Find it, and every card in the table opens.
With tokenization, the attacker holds tok_c7Rn4Wz1Hd and thousands like it. Each one is random, with no mathematical link to a card. The vault that holds the real numbers was never part of the breach.
That's the core difference. Encryption keeps the card and its key inside your environment, so every system and person near either one stays in PCI scope. Tokenization moves the card out entirely, which is why it suits businesses that need to charge cards again without running a full security program.
The same approach sits behind credit card tokenization more broadly.
How Different Industries Store Credit Card Information Securely
Businesses store credit card information securely by matching the capture channel to how cards arrive, whether that's a phone booking, an intake link or a checkout form, then keeping only tokens in their own systems.
Every industry collects cards a little differently. The storage pattern stays the same: capture outside your systems, tokenize, keep the token.
| Industry | How cards usually arrive | Where they end up today | Secure storage pattern |
|---|---|---|---|
| Travel agencies and tour operators | Phone calls, emails and booking forms | Inboxes, CRM notes and supplier portals | Hosted form or secure link, token on the booking, vault reveal for supplier portals |
| Hotels and hospitality groups | Third-party authorization forms from assistants and event planners | Email attachments and front-desk binders | Branded intake link with e-signature, token on the reservation |
| Private aviation, yacht charter and clubs | Cards collected over years for charters and dues | Spreadsheets and legacy systems | Bulk import into the vault, charges through the existing processor |
| Clinics and dental practices | Phone calls and paper intake forms | Practice notes and call recordings | Keypad capture or secure link, token for payment plans |
| Law firms and accounting practices | Retainer requests by email | Matter notes and billing inboxes | Secure link, token on the matter, charges through a proxy |
| Property management | Deposit and rent cards by text or form | Phones and property software notes | Secure link, token on the tenant ledger |
| Home services and field teams | Dispatcher calls and technician devices | Call recordings and job notes | Keypad capture or payment link, token on the job |
| Contact centers and collections | Agents taking cards on recorded calls | Audio, transcripts and agent desktops | IVR capture, token in the case system |
| SaaS platforms and marketplaces | Merchants adding cards on file for billing | The platform's own database | Embedded form, token in the app, proxy to any gateway |
A travel agency and a SaaS platform look nothing alike, but both end up in the same place: the card in a vault and a token everywhere else.
How to Store Credit Cards Collected by Phone, Email or Authorization Forms
Cards collected by phone, email or authorization forms should be captured through a phone keypad system, a pay-by-link page or a secure intake link that sends the number straight to a vault instead of to staff.
Remote card collection is normal in the US. Travel advisers, hotels, clinics and home services teams take cards by phone or form every day. These mail order and telephone order (MOTO) payments are legitimate, but the capture path decides how much risk follows.
Phone payments: When a customer reads a card number aloud, it lands in the agent's ears, the call recording and often the CRM. Keypad entry through an IVR keeps the number away from all three. Enigma's Twilio Pay connector works this way, sending the card to the vault and the token back to your system.
Emailed cards and photos: Ask customers to stop emailing cards, and send a secure link instead. A hosted payment page captures the card and returns a token.
Card authorization forms: Hotels often receive these from assistants or corporate travel teams booking for someone else. A signed PDF with the card written on it is still a card in an inbox. A branded intake link lets the client enter the card and sign the authorization in one place, with no account to create, so the signed record and the token sit together. It's the same model behind secure client intake forms.
Manual entry: Typing a card into a general-purpose browser or CRM doesn't reduce PCI scope just because it's manual. Only an approved, isolated setup changes that, and your acquirer or QSA confirms it.
How to Store Cards on File for Recurring and Future Charges
Cards on file for recurring and future charges should be stored as tokens with recorded customer consent, charged without the CVV and kept current when banks reissue them.
Storing a card for later is common, but card network rules expect a clear record of what the customer agreed to.
- Consent first: Record the amount or billing terms, the schedule and how the customer can cancel.
- Charge type: Flag whether the customer started the charge, such as approving a booking deposit, or the business did, such as a monthly dues run.
- CVV rules: The PCI Security Standards Council is direct about this in its FAQ on card-on-file and recurring transactions: "These values are not needed for card-on-file or recurring transactions," and "storage for these purposes is prohibited under PCI DSS Requirement 3.2." Customer consent doesn't change that.
- Card updates: Reissued or expired cards break stored payments, so plan for a card update process or network tokens.
A dental group running payment plans shows why consistency matters too. When the same card always maps to the same token, the billing team can spot duplicate signups and keep a patient's charges linked without anyone seeing the number. Deterministic tokens like these are a core part of card vault tokenization.
How Can Staff Use a Stored Card Without It Touching Your Servers?
Staff can use a stored card without it touching company servers by charging through a payment proxy that fills in the card inside the vault, or by viewing it in a vault-hosted screen that logs every reveal.
This is the question we get most often from travel agencies. A client authorizes the agency to book an independent hotel or a cruise line on their behalf. The supplier has no API, so someone has to type the card into the supplier's portal.
The owner wants two things at once: staff who can use the card when needed, and an app that never sees it.
There are two safe paths.
Path 1, charge through a proxy: When the payment goes to a gateway such as Stripe or Authorize.net, nobody needs to see the card. Your app sends the token, and a payment proxy fills in the card details inside the vault before forwarding the request.
Path 2, reveal inside the vault: When a supplier needs the card typed in by hand, an authorized staff member opens it in a vault-hosted screen. In Enigma's Customer Vault, staff sign in with passkeys or an authenticator app, access is limited by role, and every reveal is logged against the person who made it. The card is shown in the vault's interface and never travels through your WordPress site or custom app.
Human access still needs house rules. Train staff never to copy a revealed card into email, chat or a screenshot, and tie each reveal to a booking, an amount and the client's authorization.
There's also a third option that looks tempting and usually isn't. Pulling raw card numbers into your own application through an API gives your developers control, but it also brings that application back into PCI scope, which is the outcome most small agencies are trying to avoid.
Can Stored Cards Work With More Than One Payment Provider?
Stored cards can work with more than one payment provider when they're held in an independent card vault, because processor-held tokens usually work only with the processor that issued them.
Many businesses start by saving cards with their payment processor. It works until they want a second processor, a better rate or a new market. Then they learn the tokens can't move, and every customer has to re-enter a card.
| Question | Processor's vault | Independent card vault |
|---|---|---|
| Who holds the card? | The payment processor | A separate vault provider |
| Can you use another gateway? | Usually not without a migration | Yes, through a gateway proxy |
| Switching processors | Every card has to move or be re-collected | A configuration change |
| Staff access to cards | Limited to the processor's tools | Controlled reveal and logging |
| Best fit | One processor, standard online checkout | Card-on-file, several gateways, staff bookings |
A processor's vault is often enough for a business with one processor and a standard online checkout. The independent vault earns its place once cards are reused across gateways, suppliers or staff workflows.
Network tokens from Visa and Mastercard are another option. They keep cards current when banks reissue them, and many businesses use them alongside a vault.
With Enigma Vault, your cards never live with the processor in the first place, so switching processors becomes a configuration change. Teams already storing cards with another tokenization provider can plan a card-on-file migration with us, and if those tokens are vaultless, the same phased steps apply as when you migrate from vaultless tokenization to a vault.
Which PCI SAQ Applies When You Store Credit Card Information?
The PCI SAQ that applies when you store credit card information depends on where cards are captured and stored, with SAQ A possible when a compliant vault handles every card function and SAQ D when your systems store card data.
Small businesses validate PCI DSS compliance with a self-assessment questionnaire (SAQ). The right one depends on your setup, and your acquirer or QSA has the final say.
| SAQ | Typical setup | What it means for card storage |
|---|---|---|
| SAQ A | Card-not-present merchants that fully outsource card capture and storage to compliant third parties | Your systems never store, process or transmit card numbers |
| SAQ A-EP | E-commerce sites that outsource payment but control the page that loads the payment form | Your website can affect card security, so more controls apply |
| SAQ B-IP | Standalone, PCI-approved payment devices that connect over IP and store no card data | Staff key cards into an approved device, never a computer |
| SAQ C-VT | Staff enter one card at a time into an isolated, third-party-hosted virtual terminal | Works only when the computer is kept apart from other business use |
| SAQ D | Businesses that store, process or transmit card data on their own systems | The broadest questionnaire, with every PCI DSS requirement |
Storing cards in your own database almost always lands a business in SAQ D. Capturing cards on vault-hosted forms and keeping only tokens is how most small businesses aim for a much shorter questionnaire.
PCI DSS Requirement 3 also asks for four things whenever card data is stored: a retention policy, no sensitive authentication data, masked display and card numbers made unreadable. Encryption adds key management duties on top.
Common Mistakes Businesses Make When Storing Credit Card Information
Common mistakes when storing credit card information include keeping the CVV, saving cards in CRM notes, emailing authorization forms, encrypting cards in a home-built database and tying every card to one processor.
- Keeping the CVV "just in case": A hotel saves the code to avoid calling the guest again. It's prohibited, consent or not.
- Saving cards in booking or CRM notes: A front-desk agent pastes a card into a reservation note, and every user with access can now read it.
- Emailing card authorization forms: A signed PDF with a card number sits in three inboxes and a backup.
- Encrypting cards in your own database: A platform team adds encryption and assumes it's compliant, but its servers, logs and keys are all in scope now.
- Locking every card to one processor: A subscription business can't add a cheaper gateway without asking thousands of customers for their cards again.
- Letting staff read cards over the phone: A clinic's billing calls end up in recordings that store card numbers for years.
- Skipping retention rules: Cards for a single booking stay on file long after the trip ends.
How Enigma Vault Helps Businesses Store Credit Card Information Securely
Enigma Vault gives small businesses and growing platforms one place to keep cards. You keep tokens and masked details, and we keep the card.
Capture and Tokenize Cards With Card Vault
Card Vault takes cards through hosted and embedded forms in 13 languages, a Twilio Pay phone connector or one API call, and returns a token in a single step. Tokens are random by default, and Luhn-passable or deterministic tokens are there when your systems need them.
Secure Staff Access With Customer Vault and Agent Vault
Here's how a booking works in Customer Vault:
- The client opens a branded intake link, enters the card and signs the authorization.
- Your booking app stores the token, while the card stays in the vault.
- A staff member signs in with a passkey, reveals the card for the supplier and the reveal is logged.
Operators with thousands of cards on file can add Agent Vault, which brings bulk import, a branded card-management experience for account holders and enterprise single sign-on for staff.
Charge Through the Gateway You Already Use
Our payment proxy forwards charges to Authorize.net, Stripe, Braintree, PayPal or any REST-based gateway. For gateways with strict signing rules, requests can be signed with HMAC-SHA256 or OAuth 1.0a.
Move Cards From Your Current Provider
In one private aviation deployment, existing cards were imported into the vault in bulk and every charge kept running through the operator's processor. The cards moved into certified custody, and the operation didn't change. If your cards sit with a processor or another vault today, talk to us about card-on-file migration.
Enigma Vault Solution and Pricing
| Card Vault plan | Monthly price | Included requests | Overage per request | Includes |
|---|---|---|---|---|
| Lite | $0, free forever | 1,000 per month | $0.08 | Tokenization, gateway proxy and community support |
| Plus | $49.99 | 20,000 (roughly 200 to 300 daily transactions) | $0.04 | Ephemeral key sharing and email support |
| Premium | $249.99 | 250,000 (roughly 2,000 daily transactions) | $0.02 | Highest request volume and priority support |
Our platform runs on PCI DSS Level 1 and SOC 2 Type II certified infrastructure. Plans are billed through AWS Marketplace, and Customer Vault is priced by engagement. See the pricing page or request a demo to walk through your workflow with our team.
