A guest reads their card number to a reservations agent, who types it into the booking notes "just for the deposit." A finance team keeps cards in the billing tool so renewals go through. A customer emails a photo of their card because the payment link expired. None of these teams set out to store card numbers, yet every copy is one more place a breach can start.
The pressure is real. In the Federal Reserve's 2026 Risk Officer Report, 94% of financial institutions said they had experienced card-not-present fraud, and 26% said it was increasing.
Credit card tokenization is how you get card numbers out of your own systems without giving up saved cards or phone payments. In this guide, we walk through how it works, the token types you will come across, what it changes for PCI DSS and how to choose a provider.
What is credit card tokenization?
Credit card tokenization is a process that replaces a card number with a random token, keeps the real number in a secure vault and lets a business charge the card without ever storing it.
Picture a software company that bills 40,000 customers every month. Without tokenization, every one of those card numbers sits in its billing database, and that database sits inside PCI scope. With tokenization, the billing database holds only tokens, and the card numbers live in the provider's vault.
When a customer signs up, it looks like this:
Customer enters: 4111 1111 1111 1111, exp 09/29
Billing system saves: tok_8Hq2Lx9PvN4c, Visa ending 1111, exp 09/29
The vault holds: the full card number, encrypted, released only to process a payment
The company still renews the subscription every month and shows "Visa ending 1111" on invoices. If its billing database is ever breached, attackers find only tokens, which cannot be charged anywhere or turned back into card numbers.
What is a card token?
A card token is a stand-in for the primary account number (PAN), the long number printed on the card. It carries no value outside the system that issued it, so a stolen token cannot buy anything, and it usually travels with a few harmless details such as the card brand, last four digits and expiry date. Because the token is what your systems store, it is also what lands in exports and backups, the places where real card numbers most often leak.
Can a token be traced back to the card?
Not by anyone who steals it. A token has no mathematical relationship to the card number, so there is no formula to run and no key to crack.
The only way back is through the vault that issued it. The vault keeps the mapping between token and card and releases the real number only for approved requests, such as a charge on its way to your payment gateway.
What does a token look like?
There is no single format. Providers choose a shape that fits the systems that will store it:
| Token format | Example | When it fits |
|---|---|---|
| Random (UUID-style) | 3f9a2c7e-1b44-4d8e-9a61-7c52e0b8d913 | New systems that do not care what the value looks like |
| Prefixed | tok_8Hq2Lx9PvN4c | Developer-friendly, easy to spot in code and logs |
| Format-preserving | 4111 1183 7202 1111 | Older billing or reporting tools that expect a 16-digit card number |
| Network token | A 16-digit number from Visa's or Mastercard's token range | Payments sent through the card networks and digital wallets |
The format-preserving example keeps the first six and last four digits and even passes the Luhn check that payment forms use, though it belongs to no real account.
Why do businesses need credit card tokenization?
Businesses need credit card tokenization because card numbers spread into CRMs, inboxes, billing tools and call recordings, and every copy widens PCI scope and raises the cost of a breach.
If your business takes cards, you will likely recognize at least one of these six problems, and many businesses have all of them at once.
1. Card numbers leak into everyday tools: Card data rarely stays inside the payment system. It lands in booking notes, customer emails, chat transcripts, spreadsheets for manual billing runs and screenshots attached to help desk tickets. Each copy is unencrypted and easy to forget, which is exactly what attackers look for.
2. PCI scope grows with every system: Under PCI DSS, any system that stores, processes or transmits card data belongs to the cardholder data environment, along with the systems connected to it. One CRM holding card numbers can pull in its server and every tool that syncs with it. A single forgotten spreadsheet of card numbers on a shared drive can be enough to turn a short self-assessment into a far heavier one.
3. Raw card data sits in the billing database: Subscriptions and deposits need a card on file. Without tokens, the only way to charge a returning customer is to keep their full number in your database, usually one that many people and services can reach. One leaked backup or misconfigured query then exposes every customer on file at once.
4. Staff hear and type cards on phone orders: Agents listen to card numbers, key them in and sometimes jot them down, while call recordings capture the digits. That puts agents and recording platforms inside PCI scope, and it exposes the business to insider misuse even when every agent is honest.
5. Existing tokens are locked to one processor: Many businesses already have tokens from their payment processor, and those tokens work only there. Adding a second gateway or moving to a cheaper one can mean asking every customer for their card again.
6. A breach costs far more than the fraud: Chargebacks are only the first cost of stolen cards. The card brands can require a forensic investigation through the acquirer, fines and higher processing fees can follow, and in serious cases a merchant can lose the ability to accept cards. Customer notifications and lost trust come on top.
The common thread is simple: your business holds card numbers it does not need to hold. Tokenization removes that cause directly.
How does credit card tokenization work? A 6-step payment flow
Credit card tokenization works in six steps: capture the card, encrypt it and issue a token, store only the token, handle CVV separately, charge the token through a gateway and authorize the payment.
To see the flow end to end, follow one booking. Ana reserves a hotel room online, pays a deposit today and will pay the balance at checkout next month.
Step 1: Capture the card
Ana types her card into the payment form on the hotel's site. The form is an iframe served by the tokenization provider, so the digits go straight to the provider and never pass through the hotel's servers.
Phone bookings work the same way through IVR keypad entry, and server-side flows use a direct API call.
Step 2: Encrypt and issue a token
The provider encrypts Ana's card number, commonly with AES-256, and stores it in its vault. In return, the hotel gets a token plus the details it needs for daily work: Visa, ending 1111, expiring 09/29.
Step 3: Store only the token
The hotel's booking system saves the token on Ana's reservation:
| Field | Stored by the hotel |
|---|---|
| Reservation | RES-48213 |
| Card token | tok_8Hq2Lx9PvN4c |
| Card shown to staff | Visa ending 1111, exp 09/29 |
| Full card number | Not stored anywhere in the hotel's systems |
Step 4: Handle CVV separately
Ana's three-digit security code gets different treatment. PCI DSS never allows it to be stored after authorization, even encrypted, so a good provider holds it only briefly for the deposit charge and then deletes it. The balance next month runs on the token alone.
Step 5: Charge the token through your gateway
On checkout day, the hotel sends a charge request with the token where the card number would normally go. The request carries placeholders for the card number, expiry and CVV, and the provider fills them in inside its own environment before forwarding the request to the hotel's gateway, such as Stripe, Braintree or Authorize.net.
Step 6: Authorize without exposing the PAN
The gateway passes the payment through the card network to Ana's bank, which approves it. The hotel receives an approval code, the token and the last four digits. Ana's full card number never touched the hotel's systems or staff at any point.
After both payments, this is where everything sits:
| Data | Hotel's systems | Tokenization vault | Gateway and card network |
|---|---|---|---|
| Token | Yes | Yes | No |
| Full card number | No | Yes, encrypted | Yes, for each authorization |
| CVV | No | Briefly, then deleted | Used once, for the deposit |
| Last four and brand | Yes | Yes | Yes |
Where token service providers fit
A token service provider (TSP) is whoever issues tokens and keeps the link to the real card. In practice, a business can deal with three kinds:
- Card network TSPs, such as Visa Token Service and the Mastercard Digital Enablement Service (MDES), issue network tokens used in digital wallets and network transactions.
- Payment processors return their own tokens, which work only with that processor.
- Independent tokenization vaults sit in front of one or more gateways, so the same token can be charged through any of them.
These layers often work together. A vault can hold the card and request network tokens for the charges it sends.
What are the types of credit card tokens?
The main types of credit card tokens are merchant and network tokens, single-use and multi-use tokens, random and format-preserving tokens, and the device tokens that digital wallets use.
Each pair answers a different question about the same token, so one token can be a multi-use, format-preserving merchant token all at once:
| Question | Options |
|---|---|
| Who issued it? | Merchant token or network token |
| How many times can it be charged? | Single-use or multi-use |
| What does it look like? | Random or format-preserving |
| Can it be matched across orders? | Deterministic or non-deterministic |
| Where does it live? | In your systems, or on a customer's phone as a device token |
Merchant tokens vs network tokens
This is the distinction that matters most for payment performance.
| Feature | Merchant token | Network token |
|---|---|---|
| Issued by | A payment processor or tokenization vault | Visa, Mastercard and other card networks |
| Works with | That provider's systems | The card network, bound to one merchant or device |
| When a card is reissued | Needs an account updater or the customer | The network updates the details behind it |
| Extra protection | Keeps card numbers out of your systems | Adds a unique cryptogram to each transaction |
Many businesses use both. They keep cards in a vault for control and portability, then send network tokens to the card networks for better approval rates.
Single-use vs multi-use: A single-use token works for one transaction and then expires, which suits a guest checkout. A multi-use token can be charged again and again, which subscriptions and saved cards depend on. Some providers also let you set an expiry time on each token, so a token created for one booking stops working once that booking is over. The two often appear in the same flow: a payment form hands your server a short-lived single-use token, and your server exchanges it for a multi-use token only when the customer chooses to save the card.
Random vs format-preserving: Random tokens have no link to the card number at all, which makes them the safest default. Format-preserving tokens keep a card-like shape, often the first six and last four digits, so older billing and reporting systems keep working without code changes. The trade-off is that a few real digits stay visible, so those tokens deserve the same access rules as any other partial card data. Some providers can issue them from a custom BIN range, which keeps a token from ever matching a real card.
Deterministic vs non-deterministic: A deterministic token gives the same card the same token every time it is entered. That lets a business spot duplicate accounts or run fraud checks on one card across many orders without seeing the card number. A non-deterministic token creates a new value on every entry, which reveals less and rules out that kind of matching.
Digital wallet device tokens
When someone adds a card to Apple Pay or Google Pay, the card network issues a token for that one device after the bank approves it. The phone stores only the token, and each payment needs biometric or passcode approval before it goes through.
Every tap or in-app purchase then sends the device token plus a one-time cryptogram. A store that captured that data could not reuse it, because the cryptogram is already spent. For online merchants, the wallet passes the same token and cryptogram through the payment processor, so the merchant never handles the real card number either.
Two details surprise people. The last four digits on a wallet receipt can differ from the card's own last four, because they belong to the device token. And a lost phone can have its token suspended without cancelling the physical card.
Credit card tokenization vs encryption: what's the difference?
Tokenization replaces a card number with a random token that has no mathematical link to it, whereas encryption scrambles the number with a key so anyone holding that key can reverse it.
How each one works
Take the same card number through both:
Encrypted: 4111 1111 1111 1111 becomes a long string of ciphertext. Run it through the right key and the card number comes straight back out.
Tokenized: 4111 1111 1111 1111 becomes tok_8Hq2Lx9PvN4c. No key turns that back into a card number, because the token was never calculated from it.
That difference shapes everything else:
| Factor | Tokenization | Encryption |
|---|---|---|
| How you get the card back | A lookup inside the vault | Decryption with the key |
| If your database is stolen | Attackers get tokens they cannot use | Attackers get ciphertext, and the card numbers too if they also take the key |
| Format | Can match the card number or be any shape | Usually longer and a different shape |
| PCI DSS treatment | Token-only systems can often fall out of scope | Encrypted card numbers are still cardholder data |
| Who manages keys | The vault provider, inside its own environment | Your team, which has to rotate and protect every key |
| Best for | Card numbers stored for reuse | Data moving across networks, and data at rest inside the vault |
Is tokenization reversible?
Yes, inside the vault only. Detokenization, the step that turns a token back into a card number, happens inside the vault and only for authorized requests. Your application has no key to steal, because it never had one.
When to use both
Well-built payment setups layer the two:
- TLS encrypts the card on its way from the customer to the vault.
- The vault encrypts the stored card number, often with a separate key for each customer.
- Applications, databases, analytics and logs see only tokens.
- Card terminals in stores may add point-to-point encryption (P2PE) before the card ever reaches the network.
Encryption guards the card while it moves and while it rests in the vault. Tokenization keeps it out of everything else.
Where hashing fits
Hashing is a third method that often gets mixed up with the other two. A hash turns a card number into a fixed value that cannot be reversed by anyone, including the business that created it. That suits matching, such as checking whether a card has been used on another account. It cannot be used for charging, since there is no way back to the number.
Plain hashes of card numbers are also easier to guess than they look, since card numbers follow known patterns. PCI DSS expects keyed cryptographic hashes for that reason, and many businesses now use deterministic tokens for the same matching job instead.
What are the business benefits of credit card tokenization?
The business benefits of credit card tokenization are lower fraud risk, a smaller PCI DSS scope, safer recurring billing, fewer failed payments, higher approval rates and more gateway freedom.
| Benefit | What changes for you |
|---|---|
| Lower fraud risk | A breached database holds tokens that cannot be spent anywhere |
| Smaller PCI DSS scope | Systems that hold only tokens can often leave the cardholder data environment, which means fewer controls and a lighter audit |
| Safer recurring billing | Renewals and refunds run on the token, so a leaked billing export is no longer a card breach |
| Fewer failed payments | Network tokens and account updaters keep stored cards current when banks reissue them |
| Higher approval rates | Issuers approve network-tokenized payments more often |
| Gateway freedom | Tokens from an independent vault can be charged through more than one processor |
The first three benefits are about risk. A breach of a token-only database exposes nothing an attacker can charge, and the systems that hold tokens no longer need the full weight of PCI DSS controls. That frees security and engineering time for the few places where real card data still lives.
The last three benefits are where the numbers have moved most in 2026.
Network tokens carry a fresh cryptogram and up-to-date card details with every payment, which gives issuers more confidence to approve. On average, tokenized transactions see a 3 to 6 percentage point improvement in approval rates, and Checkout.com merchants using them cut fraud-related chargebacks by 49%, according to a May 2026 Mastercard and Checkout.com report. The same report puts the annual cost of false declines to merchants worldwide at $443 billion, which is why a few points of approval rate matter.
Gateway freedom pays off more quietly. If you can route payments to a second processor, you can add a region or recover from an outage without asking customers to re-enter their cards. That option exists only when the tokens are portable.
One benefit we see teams overlook is that the data stays useful. Finance can still report by card brand, and support can still find an order by the last four digits. Deterministic tokens also let fraud teams recognize a returning card. Your customers notice the other side of this: saved cards and one-click checkout work exactly as before, with nothing extra to type.
Where is credit card tokenization used? Common use cases
Credit card tokenization is used in recurring billing, e-commerce checkout, call centers, platforms, travel bookings and digital wallets, wherever a card is charged again or handled by people.
It is already mainstream. In Visa Acceptance Solutions' 2026 Global eCommerce Payments and Fraud Report, 72% of merchants said they use one or more forms of payment tokenization, and Visa alone has issued more than 12 billion tokens, up 44% in a year.
| Use case | Where the card enters | What tokenization replaces |
|---|---|---|
| Recurring billing and subscriptions | Sign-up page | A card number stored in the billing system for every renewal |
| E-commerce checkout | Checkout page and saved-card option | Card numbers kept for one-click repeat purchases |
| Platforms and marketplaces | The platform's payment form, on behalf of many merchants | Card numbers in a shared, multi-tenant database |
| Digital wallets | A phone or watch | The card number at the point of sale, swapped for a device token |
We'll take a closer look at two channels, because that is where card numbers most often slip into the wrong places.
Call centers and phone payments
Phone orders put card numbers in the agent's ears and in the call recording. Tokenized phone payments change the sequence:
- The agent starts a secure payment step during the call.
- The caller types the card number on their phone keypad or into a secure link sent by text.
- The digits go straight to the tokenization provider, and the agent sees only a token and the last four digits.
The agent stays on the line to help, and the recording never captures the card.
Travel bookings
Travel businesses charge the same card several times, often weeks apart: a deposit at booking, a balance before departure, a change fee if plans shift and incidentals after checkout. That is why card numbers so often end up in reservation notes and supplier emails.
With tokenization, the agency or hotel stores one token at booking and charges it whenever each amount is known. Staff work from the booking record and the last four digits, and the full card number stays in the vault.
Across every channel, the reason tokenization fits comes down to the same idea: the card is charged later or by someone else, without the number being kept in between.
| Use case | Why tokenization fits |
|---|---|
| Recurring billing and subscriptions | A stored token lets a business charge the same card monthly without ever holding the number between cycles. |
| E-commerce checkout | Tokenizing at capture keeps a card number from ever reaching the merchant's own servers during a normal purchase. |
| Call centers and phone payments | A token collected through an IVR flow removes the need for an agent to see, hear or transcribe a real card number at all. |
| Platforms and marketplaces | A token lets a platform charge a buyer's card on behalf of multiple sellers without every seller handling the card number. |
| Travel bookings | Reservations made months in advance can be charged later against a token instead of a stored, aging card number. |
| Digital wallets | Apple Pay and Google Pay tokenize at the device level, so a merchant processing a wallet payment never sees the underlying card at all. |
How does credit card tokenization reduce PCI DSS scope?
Credit card tokenization reduces PCI DSS scope by keeping card numbers in the provider's vault, so systems that store only tokens can fall outside the cardholder data environment and its audit.
What drops out of scope
A token that cannot be used to recover the card number is not cardholder data. Systems that handle only those tokens, and never see a real card number, can usually be taken out of the cardholder data environment.
| Usually drops out of scope | Usually stays in scope |
|---|---|
| CRMs and databases holding only tokens | The web pages that load your payment form |
| Billing, reporting and analytics on tokens | Any system that still receives real card numbers |
| Support tools and internal apps | Staff workflows that see full card numbers |
| Logs, as long as card data never reaches them | Your provider's environment, covered by its own PCI assessment |
How card capture affects your SAQ
Most merchants validate PCI DSS with a self-assessment questionnaire (SAQ). Which one you complete depends far more on how cards enter your business than on tokenization alone:
| How cards are captured | SAQ that often applies |
|---|---|
| Full redirect to, or iframe from, a PCI DSS compliant provider | SAQ A |
| Your own page controls parts of the payment flow, such as direct post or JavaScript forms | SAQ A-EP |
| Staff key cards into an isolated, third-party virtual terminal | SAQ C-VT |
| Your systems store, process or transmit card data | SAQ D |
One recent change is worth knowing. Since March 31, 2025, merchants using an embedded payment form under SAQ A must confirm that every element of the payment form comes directly from a PCI DSS compliant provider and that their site is protected from script attacks that target payment pages. Merchants who cannot confirm this move to SAQ A-EP.
Picture the hotel from earlier. Before tokenization, its booking system, CRM, call recordings and finance spreadsheets all held card numbers, so all of them, and the network they share, sat inside the cardholder data environment. After moving to an embedded form, IVR keypad capture and stored tokens, the list that still needs PCI DSS attention can shrink to the pages that load the form and the provider that holds the cards.
Your acquirer or a Qualified Security Assessor (QSA) has the final word on which SAQ fits your setup.
Does tokenization make you PCI compliant?
No. Tokenization shrinks the part of your business that PCI DSS applies to, and that remaining part still has to be assessed. You still need to:
- Complete and submit the right SAQ every year
- Keep the pages that host your payment form secure
- Train staff and keep card numbers out of email, chat and notes
- Confirm your tokenization provider holds a current PCI DSS Attestation of Compliance
What happens to a card token when a card expires or is replaced?
When a card expires or is replaced, a network token is usually updated by the network automatically, while a vault or processor token needs new card details via an updater service or the customer.
Cards change all the time. They expire or get reissued after fraud, and each change can break a stored card. What happens next depends on who issued the token:
| Token type | What happens when the card changes |
|---|---|
| Network token | The issuer and card network update the details behind the token, so the same token keeps working |
| Vault token | The token stays the same while the card behind it is refreshed through an account updater or by the customer |
| Processor token | Depends on the processor, and many run account updater programs for cards they store |
Visa Account Updater and Mastercard Automatic Billing Updater are the best-known updater services. Without either route, the next charge on an expired card is declined, and a subscriber who never meant to cancel quietly churns.
How an account updater refreshes a vault token
- The customer's bank reissues the card and reports the new number or expiry date to the card network's updater service.
- Before a billing run, the merchant's processor or vault checks its stored cards against that service, in a batch or one card at a time.
- The service sends back a new card number, a new expiry date, an account-closed response or a note to contact the cardholder.
- The vault swaps in the new details behind the existing token, so nothing changes in the merchant's own systems.
Network tokens skip these steps. The bank updates the network token directly when it reissues the card, and if an account is closed for fraud, the bank can suspend or delete the token so charges stop at once.
When neither route works
Not every bank takes part in updater programs, and some changes, such as a customer switching to a card from a different bank, are not covered at all. That is where a recovery flow earns its keep: an email or text with a secure link where the customer enters the new card, which is tokenized at capture and either replaces the old card behind the same token or creates a new one.
Before you choose a provider, ask three questions: does it support network tokens, how are stored cards refreshed, and does the token change when a customer enters a new card?
What are the challenges of credit card tokenization?
The challenges of credit card tokenization are legacy system integration, keeping tokens current, gaps across channels, vendor lock-in and controlling staff access to real card numbers.
Each one can undo part of the benefit if you ignore it.
| Challenge | Why it happens |
|---|---|
| System integration | Every system that used to store a real card number needs to be updated to work with a token instead, which touches more code paths than most teams expect going in. |
| Card updates | Merchant tokens don't update themselves when a card is reissued, so a business without network tokens or an account updater ends up handling failed recurring charges manually. |
| Gaps across channels | A business that tokenizes its web checkout but still takes card numbers over the phone or by email has only solved part of its exposure. |
| Vendor lock-in | A processor-issued token that can't move to a different gateway recreates the exact dependency tokenization was supposed to remove. |
| Staff access to real cards | Any step in the flow where a person still sees or types a raw card number, such as a phone order or a manual refund, undermines the rest of the architecture. |
Here is how we recommend handling each one:
Run a system inventory: List every system that reads the card field. Format-preserving tokens pass most legacy validation, so older tools keep working.
Layer card updates: Use network tokens first and an account updater for the cards they miss. A secure update link handles whatever is left.
Close every intake channel: Bring phone and email payments into the token flow with IVR capture and secure payment links.
Put exports in the contract: Pick a vault that works with more than one gateway, and get the card export process in writing before you sign.
Control who can reveal a card: Some tasks, like paying a supplier by phone, still need the real number. Limit reveals to a few approved users and log every one.
How to implement credit card tokenization: 5 best practices
Implementing credit card tokenization is a process of mapping where card data enters, tokenizing at capture, keeping CVV out of logs, choosing portable tokens and auditing every detokenization.
1. Map where card data enters
Before choosing any tool, list every door a card number can walk through. Most teams find more than they expect:
- Website checkout and saved-card pages
- Phone lines, IVR and call recordings
- Email, chat and messaging apps
- Paper and PDF forms
- Partner, supplier and marketplace feeds
- Old spreadsheets and exports nobody has deleted
Then follow each one to see where the number goes next.
2. Tokenize at capture
The earlier a card becomes a token, the fewer systems it touches. Hosted fields on the web and keypad entry on the phone send the card straight to the vault, so your servers only receive the token.
Watch for designs that tokenize later. If the card reaches your server first and is swapped for a token afterwards, the database ends up clean, yet the server and its logs have already handled a card number and stay in PCI scope. Ask your developers one question for each channel: what is the first system that sees the digits? The right answer is always the provider.
3. Keep CVV out of logs and notes
The security code is the easiest piece of card data to leak by accident, because it passes through forms, logs and conversations. Check these before go-live:
- Application and web server logs mask card fields
- Error messages and analytics events never include CVV
- CRM and ticket forms have no free-text box where staff might paste card details
- Call recordings pause during payment steps
4. Use processor-independent tokens
Test portability before you sign. In a sandbox, charge the same token through two different gateways, and get written confirmation that stored cards can be exported to a new provider in a PCI DSS compliant way if you ever leave.
It also helps to understand how the vault reaches your gateway. Some vaults relay requests to any REST-based gateway, so adding a processor is mostly configuration. Others support a fixed list of integrations, so a new processor depends on the vendor's roadmap. The difference decides how fast you can move when a rate change or an outage forces the question.
5. Audit every detokenization
Every time a token turns back into a card number, there should be a reason and a record.
| Control | What to set up |
|---|---|
| Who can detokenize | Named services and a short list of approved users |
| Where the card can go | An allowlist of gateway domains |
| What gets logged | Who, when, which token and why |
| How requests are verified | Signed requests, such as HMAC-SHA256, and OAuth2 for service-to-service calls |
| What gets reviewed | Unusual volume, odd hours and requests from systems that should never need the card |
How to choose a credit card tokenization provider
Choosing a credit card tokenization provider is a process of checking its certifications, capture options, gateway support, token formats, CVV handling and whether pricing fits your volume.
A demo always looks smooth. These are the questions we would ask before signing:
| What to check | Why it matters | Question to ask the vendor |
|---|---|---|
| Security certifications | The provider becomes part of your own compliance evidence | Can we see your current PCI DSS Level 1 Attestation of Compliance and SOC 2 Type II report? |
| Capture options | Cards arrive through more than your website | Do you support hosted forms, e-commerce plugins, phone (IVR) capture and a REST API? |
| Gateway compatibility | Decides whether you can add or switch processors later | Which gateways can you send tokenized charges to, and what changes if we switch? |
| Token formats | Older systems may need a card-shaped value | Do you offer random, format-preserving and deterministic tokens? |
| CVV handling | PCI DSS bans storing CVV after authorization | How long do you hold the security code, and how is it deleted? |
| Portability | Protects you from lock-in | Can stored cards be exported to another provider? |
Pricing
Tokenization is usually priced in one of three ways:
| Pricing model | How you pay | Fits best when |
|---|---|---|
| Per request | You pay each time a card is tokenized or revealed | Volume swings month to month |
| Per stored card | Billed monthly for every card held in the vault | Many saved cards, charged rarely |
| Monthly plan | One fixed fee covers usage up to a set limit | Steady, predictable volume |
Model costs on requests, since a single order can create several: one to tokenize the card, one to charge it and another for a refund. Check overage rates, and look for a free tier or sandbox so your team can test the full flow first.
Keep one thing in mind when comparing quotes: tokenization fees are added on top of your payment processing fees.
A few answers should give you pause during evaluation: no current Attestation of Compliance to share, tokens that can be charged only through the vendor's own processor, no clear limit on how long CVV is held, no log of who revealed which card, or no sandbox to test before you pay.
Enigma Card Vault: accept payments without storing card numbers
We built Enigma Card Vault so your systems never have to hold a card number. It tokenizes cards at capture through hosted and embedded forms, Twilio IVR or a REST API, with random, deterministic or Luhn-passable format-preserving tokens, and deletes CVV within 30 minutes. When a charge is due, our vault fills in the card and forwards the request to Authorize.net, Stripe, Braintree, PayPal or any REST-based gateway, so switching processors is a configuration change. We run on PCI DSS Level 1 and SOC 2 Type II certified infrastructure, and your first 1,000 requests each month are free. Start free with Enigma Card Vault: your checkout keeps working, and your auditor gets a shorter list.
