Tokenization vs encryption:
what actually protects
card data

Two of the most common search queries hitting security-conscious merchant pages are variations on "bank-level encryption" and "3DS liability shift" -- proof that buyers are trying to evaluate a payment processor's security claims but rarely get a straight answer on what those claims actually mean. We covered the liability side in 3-D Secure: liability shift vs conversion cost and EMV liability shift. This post covers the data-protection side: what "encryption" and "tokenization" each really do to a card number, why a vendor claiming one doesn't mean they're doing the other, and why the distinction directly determines how much PCI DSS paperwork lands on your desk.

Encryption: the card number still exists, just scrambled

Encryption takes a primary account number (PAN) and runs it through a cryptographic algorithm -- in modern payment systems, almost always AES-256 -- using a secret key, producing ciphertext that's unreadable without that key. The PAN hasn't gone anywhere. It's fully recoverable by anyone who holds the decryption key, which is exactly the point: a payment processor, an issuer, or a merchant's own backend often needs the real number at some stage to route a transaction, settle a batch, or handle a refund. Encryption protects that number while it's in transit across a network (via TLS) or sitting at rest in a database, but the underlying value is preserved, not eliminated.

That preservation is precisely what keeps an encrypted system inside PCI DSS scope. The PCI Security Standards Council's own tokenization guidance is direct about this: encrypted cardholder data is still cardholder data, and any system that stores, processes, or transmits it -- even in encrypted form -- remains part of the cardholder data environment and subject to the full weight of applicable PCI DSS requirements, because the key that unlocks it exists somewhere, and wherever that key lives becomes a target.

Tokenization: the card number leaves your systems entirely

Tokenization takes a different approach: instead of transforming the PAN into a reversible ciphertext, it replaces the PAN with a token -- a surrogate value that, done correctly, has no mathematical relationship to the original number at all. The real PAN is stored once, in a highly access-controlled system called a token vault, and the token itself is what circulates through your point-of-sale, your CRM, your recurring-billing system, and your reporting dashboards. Because the token can't be reverse-engineered back into a card number without access to the vault, a system that only ever touches tokens never actually holds cardholder data in the PCI DSS sense.

That's the scope-reduction mechanism, and it's substantial in practice: per PCI SSC guidance, systems that store, process, or transmit only tokens -- and cannot access the vault, the encryption keys protecting it, or the de-tokenization process -- fall outside the cardholder data environment altogether. Merchants who tokenize early, ideally at or near the point of card capture, commonly move from a roughly 300-control Self-Assessment Questionnaire D down to a 13-control SAQ A, because nearly everything downstream of capture is now handling a value that simply isn't sensitive.

Encryption protects a number that still exists somewhere and can be unlocked. Tokenization means the number your systems actually touch was never real to begin with.

Gateway tokens vs network tokens: not the same thing

Most merchants have already encountered "tokenization" through their payment gateway or processor -- the gateway swaps the PAN for a token the moment it's captured, and that gateway-issued token is what gets stored for recurring billing or reporting. That's real tokenization and it delivers the scope-reduction benefit described above, but the token is typically portable only within that one gateway's ecosystem.

Network tokenization is a different, higher tier: the token is issued directly by the card network itself -- Visa's Visa Token Service, Mastercard's Secure Card on File (the service formerly known as MDES), or American Express's token service -- under the EMVCo Payment Tokenization Specification, and it's tied to the real card at the network level rather than at any single processor. Visa has issued more than ten billion network tokens as of 2024, up from roughly five billion in 2022, which gives a sense of how fast issuers and networks have pushed this model. Network tokens carry two concrete advantages a plain gateway token doesn't: automatic updates when the underlying card is reissued (no more failed renewals on stored subscriptions), and measurably higher approval rates, because the issuer can validate the token's cryptographic provenance before it even evaluates the sale. Visa has reported roughly a 4.6 percentage-point lift in authorization rates on card-not-present network-token transactions compared to raw PAN submissions, and Mastercard has reported a comparable, smaller lift near 2.1 points on its network.

Property	Encryption	Gateway token	Network token
Original PAN recoverable?	Yes, with the key	No, not from the token alone	No, not from the token alone
PCI DSS scope of token-only systems	Stays in scope	Can fall outside CDE	Can fall outside CDE
Portable across processors?	N/A	Usually no	Yes -- issued by the network
Auto-updates on card reissue?	No	No	Yes
Authorization-rate lift on CNP	None	Minimal	~2-5 points (network-reported)

Where each one actually sits in a transaction

In a typical card-not-present sale processed through MidPay's stack, the sequence looks roughly like this: the card number is encrypted in transit the instant it leaves the customer's browser or terminal (TLS), it's tokenized at or immediately after capture so the merchant's own systems never store the raw PAN, and the token -- not the number -- is what sits in the merchant's CRM or recurring-billing table going forward. If a network token is available for that card, later authorizations run on the network token instead of a raw or gateway-only token, picking up the approval-rate and auto-update benefits described above. At no point in that flow does "encryption" and "tokenization" compete for the same job; they cover different exposure windows -- encryption during transmission and any brief pre-tokenization storage, tokenization for everything that happens after.

This is also why "bank-level encryption" as a standalone marketing claim tells you less than it sounds like. AES-256 is table stakes; nearly every processor uses it, including ones with weak internal controls elsewhere. The question worth asking a processor isn't whether they encrypt data in transit -- assume they do -- it's whether your own systems ever touch a decrypted PAN or only ever touch a token, because that answer is what determines your actual breach exposure and your PCI DSS paperwork.

What a breach actually exposes, under each model

• Encrypted-only environment, keys compromised alongside the data: a breach that reaches both the ciphertext and the decryption key exposes real, usable card numbers -- the worst-case outcome, and the reason key management (where keys live, who can access them, how often they rotate) is itself a heavily audited PCI DSS control area.
• Encrypted-only environment, keys not compromised: the ciphertext alone is not immediately usable, but it remains cardholder data under PCI DSS and the exposure risk persists as long as the key exists anywhere reachable by an attacker with enough persistence.
• Token-only environment, vault not breached: an attacker who steals a full database of tokens has stolen values that don't resolve to a card number without separately breaching the vault -- a materially different, and typically much narrower, incident to disclose and remediate.
• Vault itself breached: the vault is the one place actual PANs and their token mappings coexist, which is exactly why legitimate token service providers isolate it aggressively, limit its access list to a minimal set of systems, and subject it to the tightest tier of PCI DSS controls rather than treating it like any other database.

What merchants should actually check

1. Ask your processor directly whether your own systems ever handle a decrypted PAN, or whether everything downstream of the initial swipe/tap/entry is a token. The answer determines your real PCI scope, not the marketing copy on their site.
2. If you store cards on file for recurring billing, ask whether tokens are gateway-only or network tokens. Network tokens' auto-update behavior alone eliminates a recurring source of failed-renewal churn on subscriptions and memberships.
3. Confirm your SAQ level with your acquirer rather than assuming tokenization automatically drops you to SAQ A -- eligibility depends on your specific implementation and how completely your systems are isolated from the vault and keys.
4. Don't accept "bank-level encryption" as a complete answer to a security question. It's true of nearly every competent processor and says nothing about whether tokenization is also happening -- ask the tokenization question separately.
5. If you operate both in-store and online, confirm both channels tokenize, not just the one that happened to get set up first; a POS terminal added years after the online checkout sometimes gets missed in a tokenization rollout.

Frequently asked questions

Does tokenization replace encryption?

No -- they run together, not instead of each other. Card data is still typically encrypted in transit (TLS) and often encrypted at rest during the brief moment before it's tokenized. Tokenization then replaces the primary account number itself with a token for storage and everyday use, so the systems handling that token never hold cardholder data that could be decrypted at all. Encryption protects data that still exists somewhere; tokenization means the sensitive data mostly doesn't exist in your environment in the first place.

Does tokenization reduce my PCI DSS scope?

Yes, substantially, when done correctly. Per PCI SSC guidance, systems that only store, process, or transmit tokens -- and cannot access the token vault, encryption keys, or de-tokenization process -- fall outside the cardholder data environment. Merchants who tokenize cardholder data before it enters their environment commonly move from SAQ D, which requires evaluation against roughly 300 controls, down to SAQ A, which covers 13 controls. Systems that still handle encrypted PANs directly remain in scope, because encrypted data is still cardholder data under PCI DSS.

What is network tokenization and how is it different from a payment gateway token?

A gateway or processor token is generated by your payment service provider and is typically only useful within that provider's system. A network token is issued directly by the card network -- Visa's Visa Token Service, Mastercard's Secure Card on File (formerly MDES), or American Express's token service -- under the EMVCo Payment Tokenization Specification, and it's tied to the real card at the network level. Network tokens carry real advantages: automatic updates when the underlying card is reissued, and measurably higher authorization rates because issuers can validate the token's provenance before approving the sale.

If a hacker steals my tokenized card data, can they reverse it back to a real card number?

Not from the token itself. A properly implemented token has no mathematical relationship to the original PAN -- it's a reference value that only resolves to the real card number inside the token vault, which is a separate, tightly access-controlled system. Reversing a token to a real PAN requires breaching the vault directly, not just the systems that store or transmit the token. That's the core security property tokenization offers that encryption alone does not: even a complete database dump of tokens is not, by itself, a card-number breach.