Encryption scrambles data so that anyone with the right key can read it again. Tokenization removes the data and replaces it with a meaningless reference that has no mathematical relationship to the original — you need the vault to look it up. Encryption protects card data in transit. Tokenization removes card data from your systems entirely. Most modern payment stacks use both.
Two different defenses, often confused#
Buyers ask us this question more than almost any other technical one: aren't tokenization and encryption the same thing? They both make data unreadable to attackers. They both feature in PCI DSS guidance. They both turn 16-digit card numbers into something that looks like gibberish.
But they're solving different problems, and using one when you needed the other is how breaches happen.
How encryption works#
Encryption is a reversible mathematical transformation. You take cleartext (a card number, a password, a message), apply an algorithm with a key, and get ciphertext. Anyone with the matching key can reverse the process and recover the original. AES-256 is the standard for payment data; TLS 1.3 is what protects card numbers in transit between a browser and a server.
The security model: keep the key safe and the ciphertext is useless to attackers. Lose the key and the ciphertext is just data — assuming the algorithm is sound. This is why key management is the hard problem in cryptography. The math rarely fails. The keys leak.
Comparing options? Book a 15-minute demo — we'll show you a live capture and quote a real number for your call volume.
How tokenization works#
Tokenization isn't reversible by math. The token has no mathematical relationship to the underlying card number. You can't decrypt a token because there's nothing to decrypt — the token is a randomly-generated string mapped to the real card inside a separate database called a vault.
To convert a token back to a card number, you have to query the vault and ask. If you don't have access to the vault, the token is meaningless. There's no key recovery, no algorithm to break, no math to attack. The data simply isn't there.
Where each one belongs#
Encryption protects data when authorized systems still need to read it. A card number traveling from a customer's browser to your gateway has to be readable at the destination — encryption is the right tool. Card data sitting in a backup file that you might genuinely need to restore from one day — encryption with strong key management is the right tool.
Tokenization protects data when no system in your environment ever needs the real value again. After a customer's first transaction, your CRM doesn't need the card number — it just needs to identify the card for the next charge. Tokenization removes the card from your systems entirely so it can't be stolen, leaked, or accidentally logged. PCI DSS treats tokenized systems as out of scope, which is the practical commercial benefit.
Why both, not either#
Real payment flows use both, layered. When a customer types a card into a web form, TLS encrypts it in transit. The gateway decrypts it on arrival. The gateway then tokenizes the card and stores the cleartext in its vault — that vault, internally, encrypts the card data at rest. The token comes back to your system, traveling over TLS again. Your CRM never sees the raw card.
You don't pick one over the other. Encryption protects the moments when data has to flow. Tokenization protects the long stretches when it shouldn't exist in your environment at all. Both are part of PCI DSS control families for a reason.
The CVV question#
One area where the encryption-vs-tokenization difference matters more than most teams realize: the CVV. PCI DSS prohibits storing CVV (the three or four-digit security code) after authorization, even encrypted. Encryption isn't a workaround. Tokenization isn't either — the rule applies to any retention of the CVV in any form once the transaction has been authorized.
This catches teams whose call recordings capture customers reading CVVs aloud. The recording, encrypted or not, becomes a control failure under PCI DSS Requirement 3 the moment it's retained. The fix isn't to encrypt the recording harder. It's to make sure the CVV never enters the recording in the first place — which is exactly the problem DTMF masking solves on the call leg. The principle is the same one running through everything in this guide: protect data while it has to flow, and remove it entirely from environments where it shouldn't exist at all.
What this looks like with a US acquirer#
If you're processing through a US gateway — whether that's a direct acquirer relationship or a payment service provider — the same architecture applies. Card data hits the gateway over TLS, the gateway returns a token, and your platform stores the token instead of the card. The acquirer's vault handles the storage, the encryption at rest, and the lookup whenever you need to charge the card again. Your billing system and CRM hold a meaningless string and nothing more.
That's the model behind subscription billing, repeat phone payments, and stored-card checkout flows across most US merchants. The difference between providers tends to come down to which tokens they issue (provider-specific vs network tokens) and how portable those tokens are if you ever change processors. We cover that distinction in the network tokens vs PSP tokens piece.
Three places where confusing the two causes real damage#
Three patterns come up regularly when a team treats encryption and tokenization as interchangeable. None of them are theoretical — they're audit findings we've seen in production environments more than once.
The first is encrypting card numbers in a database and treating the database as out of PCI scope. The card data is still there. It's just unreadable without the key. Anyone who steals the database and the key file together has the card data in cleartext. Encrypted PANs in a merchant database are in scope under PCI DSS, full stop — and the audit work to defend that scope claim is significant. The cleaner answer is to not have the card data in the first place. Tokenize on capture, store the token, let the gateway's vault hold the card.
The second is using a hash instead of a token and assuming it's irreversible. A SHA-256 hash of a card number is deterministic — the same card always produces the same hash. With 16-digit cards drawn from a small structured space (issuer prefix + Luhn-valid account numbers), an attacker can pre-compute every possible card-number hash in a rainbow table and reverse the hash by lookup. PCI DSS v4.0.1 explicitly requires hashed PANs to use keyed cryptographic hashing (HMAC-SHA256 or equivalent) for exactly this reason. A plain hash isn't tokenization, and it isn't a defense.
The third is assuming a token from one provider works at another. It usually doesn't. Provider tokens are scoped to the issuing provider's vault. If you migrate from Provider A to Provider B, you either negotiate a vault-to-vault migration, re-tokenize every card by asking customers to re-enter, or accept that stored-card flows break on cutover. Network tokens issued by Visa Token Service or Mastercard Digital Enablement Service are more portable, but coverage and provider support still vary. This is the practical lock-in side of tokenization, and it's worth knowing before you build a stored-card flow that assumes the tokens are forever.
How Paytia uses both#
Every payment captured through Paytia — phone, in-person, chatbot link, payment portal — moves over TLS to the gateway. The gateway tokenizes the card and returns the token, which we store against the customer record. When you charge that customer again for recurring payments, the token travels back over TLS to the gateway, the vault looks up the card, and the transaction goes through. The card itself never enters our systems or yours.
If you want the broader picture, our tokenization explainer walks through the full payment flow. Pick the right tool for the right problem. Encrypt what has to flow. Tokenize what shouldn't be there.
A short decision rule#
If you find yourself unsure whether to reach for encryption or tokenization on a specific piece of data, two questions usually settle it. First, does any system in your environment still need to read the original value? If yes, you need encryption — keys, key management, the works. If no, you should be tokenizing instead and getting the data out of your environment entirely.
Second, does the data have to traverse a network or sit at rest in a backup? Both situations call for encryption regardless — that's about defending the data while it has to exist. Tokenization handles the longer-term question of whether the data needs to exist in your stack at all. The two questions answer different parts of the same architecture decision.
Get those two questions right on every sensitive data field — card numbers, ACH routing and account numbers, government identifiers, anything else that would cause real damage if leaked — and your control posture gets noticeably easier to defend at audit. Get them wrong and you end up either over-engineering encryption around data that shouldn't be there, or under-protecting data because you assumed tokenization was a stand-in for encryption when it wasn't.
Related reading#
- What Is Tokenization And How It Secures Your Data
- What Is FedNow? The US Instant Payments Network Explained
- ACH Payments for B2B: A Practical Guide for US Businesses
Comparing options? Book a 15-minute demo — we'll show you a live capture and quote a real number for your call volume.
