Tokenization vs Encryption: What Merchants Actually Need
Tokenization vs encryption, explained for merchants: what each protects, how network tokens help recurring billing, and how both shrink PCI scope.
Photo: Pixabay
On this page 7 sections
- Tokenization vs Encryption in One Sentence Each
- How Point-to-Point Encryption Protects Card Data at the Terminal
- How Payment Tokenization Protects Stored Card Data
- Network Tokens vs Gateway Tokens for Recurring Billing
- What a Thief Gets: An Illustrative Comparison
- How Each One Shrinks Your PCI Scope
- Questions to Ask Your Processor
Encryption scrambles card data so that only someone holding the right key can read it. It protects the card number while the number moves from your terminal or checkout page to your processor. Tokenization swaps the card number for a stand-in value that is useless anywhere outside your payment setup, and it protects the card data you keep for later. For most merchants the tokenization vs encryption question has a simple answer: you need both. Encryption covers the moment of the sale, and tokens cover anything you store after it.
The rest of this article explains which one does what, where network tokens fit for recurring billing, and how each affects the PCI work you do every year.
Tokenization vs Encryption in One Sentence Each
Encryption applies a mathematical key to card data so it becomes unreadable, and anyone who holds the matching key can reverse it.
Tokenization replaces card data with a random substitute that has no mathematical link to the real number. The real number sits in a secure vault run by your processor, gateway or card network.
Reversibility is the practical difference. Encrypted data is still card data, just locked. A token is not card data at all, so even someone who steals it can't turn it back into a card number. That is why encryption suits data in transit, which has to be unlocked at the other end, and tokenization suits data at rest, which you want to keep without holding anything worth stealing.
How Point-to-Point Encryption Protects Card Data at the Terminal
Point-to-point encryption (P2PE) encrypts the card number inside the payment terminal the instant the card is dipped, tapped or swiped. The data stays encrypted through your POS software, your store network and your internet connection, and it is decrypted only inside your processor's secure environment. Your systems never see a readable card number.
A lot of merchants assume EMV chip cards already handle this, and that assumption is wrong. A chip card generates a one-time code for each transaction, which makes a cloned card hard to use. The card number itself still passes through the terminal and, in many setups, through the POS software in readable form. EMV fights counterfeit cards. P2PE keeps the number unreadable while it moves through your equipment. They solve different problems.
P2PE matters most for retail counters and hotel front desks. Both run a lot of in-person volume through POS software that connects to other systems: inventory, property management, loyalty. Every one of those connections is a path an attacker could use to reach card data. If the terminal encrypts before anything else touches the card, those paths lead nowhere useful. When you compare smart terminals for in-person payments, ask how and where each one encrypts card data, along with the usual questions about price and features.
Validated P2PE and an "Encrypted Terminal" Aren't the Same Thing
The PCI Security Standards Council, the industry body behind PCI DSS, runs a P2PE standard and publishes a list of solutions that have been validated against it. Many processors also sell their own end-to-end encryption that hasn't gone through that validation. Both protect data in transit. Only a listed, validated solution reliably earns the PCI scope reduction described below, and even then your acquirer decides which self-assessment you file. If a sales rep says the terminal is "encrypted," ask whether the solution is on the PCI SSC list.
How Payment Tokenization Protects Stored Card Data
Payment tokenization starts after the processor has the card number. The processor stores the real number in its vault and sends your system a token, which often keeps the last four digits so receipts and customer service still work. When you need to charge that card again, you send the token and the vault handles the rest. For a fuller primer, see our explainer on how tokenization protects card data.
Stored cards show up in most businesses, sometimes without the owner noticing:
- A hotel takes a card at booking or check-in to guarantee the room and cover incidentals, then charges it at checkout.
- A subscription box or membership business charges the same card every month.
- An e-commerce store offers "save this card for next time."
- A retailer keeps a card on file for special orders or layaway balances.
In each case, storing the real number turns your database into a target. Storing a token means a breach of your systems exposes nothing that works at another merchant.
Online, tokenization usually starts at checkout. Hosted payment pages and embedded payment fields send card data straight from the shopper's browser to the payment gateway, which returns a token to your site. Your web server never handles the card number.
Network Tokens vs Gateway Tokens for Recurring Billing
Tokens differ depending on who issues them, and the difference shows up in your decline rate.
Gateway tokens (also called processor or PSP tokens) come from your gateway or processor. They work only inside that provider's vault. They protect stored data well, but they have two weak spots. First, when a cardholder's card is reissued because it expired, was lost or was replaced after a breach, the token still points to the old number, and the next renewal declines. Second, if you switch processors, those tokens don't come with you unless your old provider agrees to export the underlying card data to your new provider's vault.
Network tokens come from the card networks themselves. They replace the card number with a token tied to your business, so a stolen network token can't be used at another merchant. Transactions that use them often carry a one-time cryptogram as well. For recurring billing, the bigger benefit is that the network updates the token when the issuing bank reissues the card. The customer gets a new card in the mail, and your next monthly charge goes through without anyone re-entering anything. The digital wallets your customers already use run on the same idea. Our guide to Apple Pay security and setup covers how device tokens work at the counter.
Account updater services fix part of the same problem for stored card numbers and gateway tokens. The processor checks your stored cards against issuer updates on a schedule. That helps, but it runs in batches, so a card replaced the day before billing may still decline. If involuntary churn is costing you subscribers, read the decline codes behind failed renewals to see whether "expired card" and "invalid account" declines make up a large share of your failures.
What a Thief Gets: An Illustrative Comparison
Take a hypothetical boutique hotel. It takes cards at the front desk and stores them on its property management system until checkout. An attacker installs memory-scraping malware on the front desk computer and copies the system's database. The table shows what the attacker walks away with under three setups. These are illustrative scenarios, not data from any real breach.
| Setup | Card data captured at the desk | Card data in the stored database |
|---|---|---|
| No encryption, no tokens | Readable card numbers as cards are processed | Readable card numbers for every guest on file |
| P2PE only | Encrypted data the attacker can't read | Readable card numbers, if the system stores them after authorization |
| P2PE plus tokenization | Encrypted data the attacker can't read | Tokens that only work for this hotel's account |
With encryption alone, the database is still exposed. With tokenization alone, the malware still catches readable card numbers as cards pass through the desk computer. Only the combination leaves the attacker with nothing usable. The same logic applies to a retailer's POS or a subscription business's billing database. Hotels and other businesses that hold cards for days or months have the most to lose from the second row.
How Each One Shrinks Your PCI Scope
PCI DSS is an industry standard enforced through card network rules and your merchant agreement. It is not a federal law, although state data breach laws can apply once card data is exposed. Your "scope" is every system that stores, processes or transmits card data, plus anything connected to those systems. The smaller the scope, the fewer requirements you have to meet and document.
A validated P2PE solution takes your POS, your network and your back-office computers out of the card data path, because they only ever see encrypted data. Merchants using one can usually file a much shorter self-assessment than merchants whose systems handle readable card numbers. Tokenization does similar work for storage: systems that hold only tokens generally fall outside the strictest requirements. Hosted payment fields do it for online checkout, although your website stays partly in scope because whoever controls the page that loads the payment form could tamper with it.
Neither technology makes PCI go away. You still file an annual self-assessment, and any system that touches card data before it is encrypted or tokenized stays in scope. A keyed phone order typed into a computer is the classic example. Treat this section as general information. Your acquirer decides which assessment applies to you, and a Qualified Security Assessor can confirm your scope.
Questions to Ask Your Processor
Bring these to your current provider, or to any provider you're considering:
- Is your terminal encryption a PCI-validated P2PE solution, and which self-assessment questionnaire will I file with it?
- Where does decryption happen, and does my POS software ever see a readable card number?
- Do you offer network tokens, or only gateway tokens? Is there a fee for either?
- Do you run account updater on my stored cards, and how often?
- If I leave, will you export my stored card data to my new processor's vault, and on what terms?
- For online sales, do my hosted fields or payment page keep card data off my server entirely?
The fifth question is the one merchants forget. It's also the hardest to fix later, because a subscription business that can't move its stored cards has to ask every customer to re-enter a card. Ask it before you sign.
If you want help reviewing your current setup or comparing equipment and gateways, request a free quote from MannyPay. A specialist will respond within one business day.
This article is for general educational purposes and is not legal, tax or financial advice. Card network rules and state laws change; confirm current requirements for your business.
