Payments11 min readUpdated October 14, 2026

Tokenization vs Encryption in Card Payments

Tokenization vs encryption in card payments: where each happens, what the PCI SSC says about scope, SAQ A vs A-EP, and which tokens can move.

Nick Bonnassies, CMO at Tagada · checked against 14 sources

Article summary

TL;DR

Encryption scrambles the card number with a key, and anyone holding the key can turn it back. Tokenization replaces the card number with a stand-in value, and the real number stays in a separate vault. For PCI DSS, encrypted card data is still card data; systems that only ever see well-isolated tokens can fall out of scope.

Encryption hides the card number but keeps it in your systems. Tokenization takes it out and leaves a reference.
The PCI SSC says encryption alone doesn't take card data out of PCI DSS scope. The token vault and anything that can de-tokenize are always in scope.
Your checkout setup decides your questionnaire: redirect or iframe for SAQ A, your page controlling the handoff for SAQ A-EP, your own servers touching cards for more.
Processor tokens work only with that processor. Network tokens are tied to a merchant and usually to the provider that requested them. Only the card number itself moves between processors.
You need both: encryption for every connection and for the vault, tokens for everything your own systems store.

Want to go further? Ask

On this page

Tokenization and encryption both stop a card number from being read by the wrong person, so they get compared as if you had to pick one. You don't. Encryption protects the card number wherever it travels or rests; tokenization decides where it rests at all. This guide explains each, where they happen in a card payment, what the PCI Security Standards Council says about scope, and which token you can take to another processor.

Tokenization vs encryption: the short difference

The primary account number (PAN) is the long number on the card. Both techniques make it unreadable, in different ways.

	Encryption	Tokenization
What happens to the card number	Turned into ciphertext with an algorithm and a key	Replaced by a surrogate value, the token
Where the real number lives	In the ciphertext itself, wherever it's stored	In a separate card data vault
How you get it back	Decrypt with the key	Ask the vault to de-tokenize
What an attacker needs	The ciphertext and the key	Access to the vault or to a system allowed to de-tokenize
PCI DSS status	Still cardholder data in most cases2	Token-only systems can fall out of scope, under conditions1
Typical use in payments	Data in transit (TLS), card terminals (P2PE), the vault's own storage	Saved cards, subscriptions, order records, routing

Verdict

Encryption hides the card number but leaves it in your systems. Tokenization takes it out and leaves you a reference. A serious payment setup uses both.

The PCI SSC defines tokenization as replacing the PAN with "a surrogate value called a token", and de-tokenization as redeeming the token for its PAN. A token's security relies on the fact that you can't work out the card number from the token alone.1

What encryption does in a card payment

Encryption is reversible by design: the right key always turns the ciphertext back into the card number. That's what makes it useful in payments, because at some point a processor needs the real number to ask the issuer for approval. Encryption shows up in three places.

In transit: TLS
Between the customer's browser, your checkout, the processor and the card network. PCI DSS requirement 4.2.1 calls for strong cryptography to protect the PAN on open, public networks, with only trusted keys and valid certificates.
At the terminal: P2PE
In stores, point-to-point encryption scrambles the card inside the payment terminal. It's decrypted only in the solution provider's secure environment, never in your systems.
At rest: the vault
Card numbers stored in a vault are encrypted, and the keys are kept apart from the data. This is the provider's job if the vault is theirs, and yours if you run it.

The requirement appears, for example, in SAQ A-EP, the questionnaire for checkouts where your page affects the payment.4 TLS protects the connection; it says nothing about where the card number ends up once it arrives.

The weak point of encryption is the key. Whoever can decrypt holds the card number, and every system that can decrypt carries the same exposure. For PCI DSS, that's why encryption alone doesn't shrink your scope. More on that below.

What tokenization does

Tokenization moves the card number out of your systems at the moment it's captured.

The customer types the card into a form served by your payment provider: a hosted page, an iframe or hosted fields.
The card number goes straight to the provider's vault, over TLS, without passing through your servers.
The vault stores the number, encrypted, and returns a token, often with the brand, expiry and last four digits for display.
You store only the token, against the customer and the order.
To charge again, you send the token. The vault, or the processor behind it, swaps it back to the card number to request authorization.

Steps 2 and 5 are the only moments the real card number exists outside the vault.

The PCI SSC lists three ways to generate a token: a reversible cryptographic function with a strong key, a one-way function such as a salted hash, or an index, sequence number or random number "not mathematically derived from the PAN". Whatever the method, recovering the card number from tokens must not be computationally feasible, and tokens "should have no value if compromised or stolen".1

An encrypted token is still an encrypted card number

The PCI SSC warns that when a token is made by encrypting the card number with a key, "the resultant token is an encrypted PAN" and may carry extra PCI DSS obligations.1 Format-preserving encryption, which outputs a 16-digit value that looks like a card, falls in this case. Ask your provider how its tokens are generated.

The same guidelines add that security codes (CVV2, CVC2) and PINs can't be tokenized for storage.1 You can't keep a CVV just because it's behind a token.

The four kinds of tokens you'll meet

"Token" covers very different objects in payments. They don't come from the same place and they don't travel the same way.

Token	Issued by	Where it's used	Usable on another processor?
Processor token (e.g. a saved card at Stripe)	Your processor, from its own vault	Charges through that processor only	NoUnless the processor forwards or exports the card
Vault or orchestration token	A standalone vault or your orchestration provider	Sent to any processor the vault connects to	YesThe vault sends the card number to the processor you pick
Network token	The card network, at the request of a token requestor	Card-on-file and recurring payments, with a cryptogram	Case by caseTied to a merchant and usually to the requestor
Wallet device token (Apple Pay, Google Pay on a device)	The issuer or its provider, stored on the device	In-store, in-app and web payments from that device	Not stored by you: each payment carries the device token and a one-time code

Network tokens replace the card number across the whole payment chain, up to the issuer. EMVCo, which writes the standard, says an EMV payment token "is constrained in how it can be used", for example to a specific merchant, device or payment scenario, and that it's compatible with other forms of tokenization such as acquirer tokens.9 Stripe describes a network token as a credential specific to a card and merchant pair that stays current when the underlying card changes or expires.10 That last point is why they matter for subscriptions: a replaced card doesn't break the renewal.

Wallet tokens work the same way on the phone. With Apple Pay, the issuer creates a Device Account Number that is stored in the Secure Element, can't be decrypted by Apple, and is never stored on Apple's servers. Each payment carries a transaction-specific dynamic security code, and Apple says neither Apple nor the device sends the actual card number to the app or website.12 Google Pay can also return a card saved in the customer's Google account rather than a device token, which changes how 3-D Secure applies: see payment authentication.

Does tokenization or encryption reduce PCI DSS scope?

This is the question behind most searches for "PCI tokenization vs encryption". The PCI SSC's answer on encryption is short:

Encryption alone is insufficient to render the cardholder data out of scope for PCI DSS.

PCI SSC, FAQ 1086, March 2026

Strong cryptography is an accepted way to make stored card numbers unreadable under PCI DSS requirement 3.5.1, but that's a control inside the scope, not a way out of it.2 The Council lists what stays in scope:3

systems that encrypt or decrypt card data, and systems that manage the keys;
encrypted card data that isn't isolated from encryption, decryption and key management;
encrypted card data stored on the same system or media as the decryption key, or in the same environment;
encrypted card data that anyone with access to the key can reach.

The one exception is a third party that only receives or stores data someone else encrypted and can never decrypt: it may be able to treat that data as out of scope, under conditions.3

Tokenization can do more, but not by default. The PCI SSC's tokenization guidelines say every part of the tokenization system, including de-tokenization and card storage, is in scope, as is any system with access to it.1 A system that handles only tokens can be considered out of scope if it meets all of these conditions:1

the card number can't be recovered from the token, from several tokens or from token-to-PAN pairs;
it's isolated from anything that can request de-tokenization, reach the vault or its keys, or derive the card number;
it isn't connected to the tokenization system or to the cardholder data environment, and holds no credentials to it;
it doesn't handle card data through any other channel;
any card data it held before tokenization has been securely deleted.

Tokens that can pay are worth protecting

Tokens that can be used to make a payment, which the PCI SSC calls "high-value tokens", may have the same value to an attacker as the card number. They "might be in scope for PCI DSS" even if they can't reveal the card number, so ask your acquirer.1 A saved-card token that charges a customer from your admin panel is exactly that.

SAQ A, SAQ A-EP and the 2025 script rule

For an online store, scope shows up as the self-assessment questionnaire (SAQ) your acquirer asks you to file. What decides it is less "token or encryption" than "who serves the payment form".

How your checkout takes cards	Questionnaire	What the PCI SSC says
Redirect to the processor's payment page	SAQ A	Every element of the payment page must come from a PCI DSS compliant provider; the 2025 script criterion doesn't apply to redirects5 6
Processor's form embedded in an iframe	SAQ A	Since April 1, 2025, you must confirm your site isn't susceptible to attacks from scripts6
Your page controls the handoff (direct post, JavaScript that sends the card to the provider)	SAQ A-EP	Your site doesn't receive card data but affects the security of the payment; elements of the page come from your site or a compliant provider4 5
Card numbers reach your own servers	Beyond A-EP	SAQ A-EP requires that you don't electronically store, process or transmit any account data4

To meet the 2025 SAQ A criterion with an iframe, the Council accepts two routes: protections like PCI DSS requirements 6.4.3 and 11.6.1 (an inventory of authorized payment page scripts, and change and tamper detection), or written confirmation from your PCI DSS compliant processor that its embedded form protects your page from script attacks when you implement it as instructed.6

Notice what this means: two stores that both "use tokens" can land on different questionnaires, because one redirects and the other posts the card from its own JavaScript. Tokens decide what you store. The form decides what you touch. The wider checklist is in the PCI section of payment risk management, and gateways are compared in PCI-compliant payment gateways.

Point-to-point encryption for in-store sales

If you also sell in person, point-to-point encryption is where encryption, not tokenization, does the scope work.

Fig. 1A card payment with a P2PE terminal

Card tapped or dippedOn a terminal from a PCI-listed P2PE solution
Encrypted in the terminalBefore it reaches your register or network
Travels encryptedYour systems can't decrypt it
Decrypted by the providerIn its secure decryption environment

The card number is never readable in your store systems.

Simplified flow based on PCI SSC FAQs 1158 and 1247.

The Council says a PCI-listed P2PE solution "can significantly reduce the number of PCI DSS requirements" for a merchant, but doesn't remove PCI DSS entirely.7 The short questionnaire, SAQ P2PE, applies only if card data stays inside the validated terminals, you store no card data electronically, and you follow the provider's P2PE Instruction Manual.8 An expired P2PE listing no longer counts as validated.8

The tokenization guidelines recommend combining the two: tokens for everything stored, P2PE at capture, so the only card numbers in your environment sit inside approved terminals.1

Which tokens can move to another processor?

Portability is where tokenization stops being a security topic and becomes a business one. If your saved cards are processor tokens, your customers are tied to that processor.

Saved cards as processor tokens

Customer's saved cardToken valid at one processor
charged byProcessor AOnly one that can charge itApproved
can't use itProcessor BNeeds the card number, not the tokenDeclined

Moving means an export, and some data stays behind

Saved cards in a vault you can route from

Customer's saved cardVault token in your records
resolved byVaultHolds the encrypted card numberApproved
sent toProcessor A or BReceives the card number from the vaultApproved

Same card, any connected processor

What the processors themselves document:

Stripe export. Stripe sends card data only to another PCI DSS Level 1 processor, in an encrypted file. Payment history, subscriptions and cards saved with Link don't come with it.13
Stripe forwarding. The Vault and Forward API keeps cards in Stripe's vault and forwards them to supported third-party endpoints, with access through Stripe support.14
Adyen network tokens. They apply to payments Adyen acquires and "cannot be used with external acquirer connections".11

So the card number is what moves; network tokens usually don't. When a customer moves to a new processor, that processor typically requests its own network token. The vault types and the migration process are covered in what payment orchestration is and the token vault migration glossary entry.

Tokenization or encryption: which one to use, and where

The useful question isn't "which one" but "where does each card number need to exist". Read your setup line by line.

Card data crosses any networkEncryption in transitTLS everywhere, valid certificates, no exceptions for internal calls
You need to charge saved cards laterTokens, not stored card numbersStore your provider's token against the customer, never the card number
You sell subscriptionsTokens that survive card replacementAsk whether your processor uses network tokens and card updater services
You use or plan a second processorA vault that isn't tied to one processorKeep cards in an orchestration or standalone vault, or get the export terms in writing
You run your own vaultEncryption at rest and full PCI DSS scope for the vaultBudget for key management, segmentation and a yearly assessment
You sell in personEncryption at the terminalUse a PCI-listed P2PE solution and follow its instruction manual

Common mistakes

Card numbers where nobody looks

The vault is fine, but a full card number sits in an error log, a support ticket or a webhook dump. The tokenization guidelines ask merchants to make sure every trace of card data is securely deleted from source systems once tokenized.1

Calling encrypted storage "tokenization". If the "token" can be decrypted with a key you hold, it's an encrypted card number and stays in scope.
Building your own form to "control the design". If your JavaScript sends the card number, you move from SAQ A to SAQ A-EP, with many more requirements to meet.
Forgetting the scripts on the checkout page. Pixels, tag managers and chat widgets on an iframe checkout now count under the 2025 SAQ A criterion.
Assuming tokens are portable. A processor token is valid at that processor. Read the export terms before you need them.
Keeping the CVV behind a token. The PCI SSC doesn't allow tokenizing security codes for storage.1
Treating tokens as worthless. A token that can charge a card from your admin panel can be abused like a card number. Restrict who can use it.

Where Tagada fits

How Tagada helps

A card vault that isn't tied to one processor

Tagada's card vault moves customers from one merchant account to another without asking for their card again, and running subscriptions keep charging. Payments route across Stripe, Adyen and Tagada's own TagadaPay processor with one logic, with a cascade on decline. 3D Secure 2 is native, alongside device intelligence and a rules engine, and the checkout supports Apple Pay and Google Pay with one-click upsells and order bumps. TagadaPay still underwrites each business. Pricing is on the pricing page.

Apply for processing

Whatever provider you use, the same three checks apply: who serves your payment form, where your saved cards live, and what you can take with you if you leave.

Updated on October 14, 2026

Nick Bonnassies

CMO at Tagada

CMO at Tagada. Before Tagada, Nick built direct-to-consumer brands that generated over $115M in sales, raised over $25M in crowdfunding and sold two of them. He also works as a fractional CMO on marketing operations and AI systems.

Frequently asked questions

What is the difference between payment tokenization and encryption?

Encryption turns the card number into ciphertext with a key; whoever has the key can recover the number, so the data stays card data. Tokenization swaps the card number for a token and keeps the real number in a separate vault; the token alone can't be turned back into the card number. Payments use both: encryption on every connection, tokens for stored cards.

Does tokenization take you out of PCI DSS scope?

Not entirely. The PCI SSC says the tokenization system, the vault and every system that can de-tokenize are always in scope. Systems that store or handle only tokens, are isolated from the vault and never see card data can fall out of scope. Tokens that can start a payment on their own might still be in scope.

Is encrypted card data still in PCI scope?

Yes, in most cases. The PCI SSC says encryption alone doesn't take cardholder data out of scope. Systems that encrypt, decrypt or manage keys stay in scope, and so does encrypted data stored with its key or reachable by someone who has the key. A third party that only stores data it can never decrypt may treat it as out of scope.

Is tokenization more secure than encryption?

They protect against different things. A stolen token database is useless without access to the vault, while stolen ciphertext is exposed if the key leaks too. But encryption is what protects card data while it travels, and the vault itself is encrypted. The safer design keeps card numbers in as few places as possible and encrypts every one of them.

How can I accept cards without storing card numbers?

Collect cards in your processor's hosted page, iframe or fields, so the card number goes straight to its vault and you keep a token. For several processors, use an orchestration or standalone vault that can send the card number to each of them. Network tokens and wallet tokens such as Apple Pay add another layer on top.

Are Apple Pay and Google Pay payments tokenized?

Apple Pay is. The issuer creates a Device Account Number stored in the phone's Secure Element, and each payment carries a one-time security code; Apple says the real card number isn't sent to the app or website. Google Pay can return either a device token or a card saved in the customer's Google account, which is handled like a regular card.