Tokenization
Replacing card numbers with a meaningless token so you never store real card data.
Tokenization swaps a card's real number (PAN) for a randomised token that stands in for it in your systems. Because the token is useless if stolen, it reduces PCI scope and enables safe repeat billing without holding card data yourself.
How it works
The card number goes from the shopper's browser to the gateway, through a hosted field or iframe your own page cannot read. The gateway vaults it and hands back a token. That string has no mathematical route back to the card. You store the token against the customer record and send it for every charge after, and the gateway swaps the live number back in before the transaction reaches the network. Your customer database stops being worth stealing, which keeps PCI scope small and most breach exposure away from you. Saved cards, one-click repeat purchases, and subscriptions work without you holding anything sensitive.
Mainstream providers rarely bill tokenization as a separate line item, though some gateways price the vault as an add-on, so confirm rather than assume. The real cost is portability. Most gateway tokens are proprietary and mean nothing to anyone else, so changing provider means asking your current one to hand the underlying card numbers over under a PCI-compliant migration. They will do it, rarely quickly. Ask how that works before you sign rather than on the way out. Network tokens are a different animal: the card networks issue them, and they refresh themselves when a card is reissued, which cuts subscription declines.
Worked example
A customer pays $49 on a subscription site. Their card number never touches the merchant's server. What lands in the customer table is a string like tok_9f3a1c7be24d, and that is all that sits there. Next month the billing job posts the token and the $49 amount to the gateway, which swaps in the real number and charges the card. If that database leaked, nobody could use the token to charge that card anywhere else.
Frequently asked questions
- Is tokenization the same as encryption?
- Encryption is reversible by design: scramble the number with a key, and anyone holding the key can unscramble it. A token cannot be reversed at all, because the mapping lives only in the provider's vault. Payments use both. Encryption protects the number while it moves, and tokenization removes the need to keep it once it arrives.
- Can I move my saved cards to a new payment processor?
- The cards move, the tokens do not. You request a PCI-compliant vault migration: your old provider transfers the underlying card numbers directly to the new one, which issues fresh tokens against your customer records. Most large processors support this and many do not charge for it, but it usually takes weeks. Confirm how it works before you sign anything.
- Does tokenization make me PCI compliant?
- It shrinks your scope and leaves the obligation intact. Tokenization plus a hosted field or hosted checkout usually puts you on SAQ A, the shortest self-assessment, and you still validate and attest every year. Anything that puts a live card number back in your hands, phone orders keyed in by staff being the usual culprit, pulls you into a longer questionnaire regardless.