Payment tokenization: how it works for merchants

Payment tokenization is the practice of replacing a card number with a substitute value, called a token, so the real number doesn't have to sit in your systems. EMVCo, the body behind the chip card specifications, describes payment tokenisation as replacing the card number with a unique alternative value that can be restricted to a specific merchant, device, or payment scenario. A thief who steals a token can't take it to another store and shop with it.

For a merchant, tokens solve two practical problems: how to charge returning customers without storing their cards, and how to keep your PCI workload small. This guide explains the three kinds of tokens you'll run into, how each one affects your compliance, and what to ask your provider before you rely on them. Facts are current as of October 2026.

What is payment tokenization?

It's a swap. When a customer pays or saves a card, the card number goes to a secure system run by your gateway, the card network, or the customer's phone, and a token comes back in its place. You store the token. The next time you charge that customer, you send the token, and the system that issued it maps it back to the real card behind the scenes.

EMVCo frames the goal as replacing valuable card data with a payment token. The value is in the restriction. A token that only works for your merchant account, or only from one phone, is worth very little if your database leaks.

Here's what that looks like for a customer saving a card on your site:

1. The customer enters card details in a payment form hosted by your provider.
2. The provider sends the card details for authorization and stores the card number in its own secure vault.
3. Your system receives a token plus the last four digits and the expiry, enough to show "Visa ending 0019."
4. Next month, your billing system sends the token and the amount.
5. The provider swaps the token for the card number and runs the charge. Your systems never saw the full number.

How is tokenization different from encryption?

Encryption scrambles the card number so it can be unscrambled later with the right key. Tokenization removes the card number from your hands entirely and gives you a value that can't be reversed without access to the token provider's vault. Both protect data, but they do different jobs.

The difference matters for PCI. PCI SSC's merchant FAQ says encryption alone is generally insufficient to take card data out of scope, because if you hold encrypted card numbers and the keys exist somewhere in your business, the data is still yours to protect. A token you can't reverse is a different story. In practice you'll often have both: encryption while card data travels, and tokens for anything you keep.

Network tokens vs processor tokens: what's the difference?

The difference is who issues the token and where it works. Processor tokens (also called gateway tokens) come from your payment provider and work only with that provider. Network tokens come from the card networks themselves and are built to the EMVCo framework. Device tokens are tied to a specific phone or watch, and they're how Apple Pay and Google Pay keep card numbers out of the checkout.

Visa runs its own service for this: the Visa Token Service substitutes Visa card numbers with tokens for digital payments. Most small merchants never connect to a network directly. Your gateway requests network tokens on your behalf, if it supports them, and gives you its own reference to store.

For a small merchant, processor tokens are fine for security. The catch is lock-in. If you ever move providers, a vault full of processor tokens can't simply be copied over, so ask before you sign whether your provider will transfer stored cards securely to a new one. Our guide to what a payment gateway is covers that question in more detail.

How do Apple Pay and Google Pay use device tokens?

Phone wallets are tokenization you get without lifting a finger. When a customer adds a card to Apple Pay, a unique Device Account Number is stored in the phone's Secure Element, and Apple says your actual card number isn't sent when you pay in a store. The payment goes through with the device account number and a dynamic security code that's specific to that transaction. Apple adds that the Device Account Number isn't stored on Apple servers or backed up to iCloud.

Each Apple Pay payment also has to be approved by the user, with Face ID, Touch ID, or the passcode. On Android, Google says tap to pay sends a virtual account number and keeps the actual card number confidential.

Online, Google Pay has a detail worth knowing. Its developer documentation describes two authentication methods. With PAN_ONLY, the card is stored on file with the user's Google Account, and the returned payment data includes the actual card number with its expiry. With CRYPTOGRAM_3DS, the card is stored as an Android device token, and the returned data includes a cryptogram generated on the device. So "the customer paid with Google Pay" doesn't always mean you received a token. Ask your provider which method your checkout accepts.

For in-person sales, wallet acceptance is a terminal setting, not a project. Clearo's POS terminals and mobile payments accept Apple Pay and Google Pay, and our guide to whether tap to pay is safer explains why wallets beat plastic on security.

How does tokenization shrink your PCI scope?

Your PCI scope is every system that stores, processes, or transmits card data. Tokens take card numbers out of the systems that would otherwise hold them, which is why PCI SSC's tokenization guidelines recommend minimizing the number of system components that touch card numbers. Fewer systems in scope means a shorter self-assessment questionnaire (SAQ). Our PCI compliance support page lists saved cards among four ways to shrink that scope.

Take a meal-kit subscription company in Minneapolis that built its own checkout years ago and saves card numbers in its customer database. That puts it in SAQ D and makes the database a breach target. Moving to provider-hosted payment fields with tokens takes card numbers out of the database entirely and could move it to SAQ A, with one condition: PCI SSC now asks merchants that embed a provider's form to confirm their site is not susceptible to attacks from scripts.

Visa adds a reason to care. Its Technology Innovation Program can remove the annual validation requirement for eligible merchants when at least 75% of yearly transactions go through EMV chip terminals, a validated point-to-point encryption solution, or EMVCo-standard tokenization. Ask your acquirer whether you qualify. Our guide to what PCI compliance is explains SAQs and validation in full.

How do tokens work for card-on-file and recurring payments?

Tokens are the safe way to run card-on-file billing. The rules around storing a card still apply when the stored thing is a token, though.

• Get consent first. Visa's stored credential framework requires the cardholder's agreement before card details are stored for future use, and asks merchants to flag the first storage and later charges in the transaction data.
• Never store the security code. PCI SSC's FAQ says the code isn't needed for card-on-file or recurring transactions, and storing it for those purposes is prohibited. Our CVV guide covers the rest of the rules for that code.
• Plan for cards that change. Visa's account updater FAQ says that on average 30% of the card accounts in a participating issuer's portfolio change number or expiry date, or close, every year.

Run that against a real list. If the Minneapolis company has 1,500 subscribers and its cards change at that average rate, about 450 stored cards go stale in a year (1,500 × 30%). Every one is a failed charge unless something updates it. Ask your provider whether its tokens stay valid when a bank reissues a card, and whether it runs account updater services for the cards that aren't covered.

Clearo's virtual terminal includes recurring billing and payment links, and our recurring billing guide covers disclosure, cancellation, and retry rules.

What should you ask your provider about tokens?

Ask these before you sign, not after you have 2,000 saved cards:

1. Does saving a card return a token, and do my systems ever receive the full card number?
2. Are those processor tokens, network tokens, or both?
3. Do tokens keep working when a customer's bank reissues the card, and do you run account updater services for Visa and Mastercard?
4. If I leave, will you transfer stored cards securely to my new provider, and is there a fee?
5. Which Google Pay authentication methods does my online checkout accept?
6. Which SAQ do you expect me to file with this setup, and will you confirm in writing that your embedded form protects against script attacks?
7. Do my in-person terminals accept Apple Pay and Google Pay?

Common tokenization mistakes

Tokens fail when a merchant assumes they cover more than they do:

• Saving a token and the card number "as a backup." The backup is the thing PCI cares about.
• Letting card numbers arrive by email or phone notes, then tokenizing them later. The emails and notes are still in scope.
• Assuming every wallet payment is tokenized. Online Google Pay can return a real card number under PAN_ONLY.
• Ignoring portability until the day you want to switch.
• Treating tokens as fraud prevention. A token protects stored data; it doesn't tell you whether today's buyer is the real cardholder. You still need address verification, CVV checks, and good judgment on card-not-present orders.

When is tokenization not worth worrying about?

If you only take in-person payments on standalone terminals and never save cards, you're not storing anything a token would replace. Your attention is better spent on terminal security and chip and tap acceptance. Tokens start to matter the moment you keep a card for a second charge, sell online, or bill on a schedule.

For businesses that do keep cards, tokens aren't optional in our view. A gym in Toronto billing monthly memberships and an online shop in the United States saving cards for faster checkout face the same PCI standard, and both should hold tokens, not numbers. Our wellness and fitness page covers membership billing setups.

Next step

If you're not sure whether your current setup stores card numbers or tokens, we can find out. Send us a recent statement for a free statement review and we'll look at how your online and recurring payments are processed, or contact us to talk through online payments with hosted checkout and saved cards.