Tokenisation, Encryption and Hashing Explained
Tokenisation, encryption and hashing are the three core techniques used to protect payment data, and they are often confused with one another. All three transform sensitive data into something safer to store or transmit, but they work differently, protect against different threats, and are used at different points in the payment flow.
Understanding the difference matters practically: it determines your PCI DSS scope, what you are allowed to store, and how you should log and reference payment data in your own systems.
What is the difference?
| Tokenisation | Encryption | Hashing | |
|---|---|---|---|
| What it does | Replaces the data with a substitute token; the real value is stored in a secure vault | Scrambles the data mathematically using a key | Produces a fixed-length fingerprint of the data |
| Reversible? | Only by the token vault | Yes, with the key | No — one-way by design |
| Typical use in payments | Storing cards for repeat billing | Protecting data in transit (TLS) and at rest | Verifying passwords, integrity checks, matching records |
| If stolen, is the data exposed? | No — a token is useless outside the system that issued it | Only if the key is also compromised | No original data to recover, though weak inputs can be guessed |
How does tokenisation work in payments?
When a customer saves a card, the payment provider stores the real card number in its secure vault and gives the merchant a token — a reference that only works with that provider (and often only for that merchant). The merchant charges the token for future payments without ever holding the card number. If the merchant's database is breached, the tokens are worthless to the attacker.
There are two layers of card tokenisation:
- Provider (vault) tokens issued by the payment gateway or processor.
- Network tokens issued by Visa and Mastercard themselves, which replace the card number at scheme level and can be automatically updated when a card is reissued.
See card tokenisation and network tokens for the details, and recurring card payments for how tokens enable subscription billing.
How is encryption used in payments?
Encryption protects data while it moves and while it rests:
- In transit: every payment page, API call and webhook should use TLS, so card numbers and bank details cannot be read on the network.
- At rest: databases, backups and files containing sensitive data are encrypted so a stolen disk or dump is unreadable without the keys.
- In hardware: card terminals and payment processors use dedicated cryptographic hardware to protect PINs and keys.
Encryption is reversible by design — systems that need the real value can decrypt it. That makes key management the critical discipline: encrypted data is only as safe as the keys, which must be stored separately from the data, rotated, and tightly access-controlled.
Where does hashing fit in?
Hashing is one-way: you can compute the hash of a value, but you cannot recover the value from the hash. In payment systems it is used for:
- Password storage — systems store the hash, never the password itself.
- Integrity and signatures — webhook signatures and API request signing use hashes to prove a message was not tampered with. See API authentication and signatures.
- Matching without storing — comparing whether two records refer to the same underlying value without keeping that value.
Hashing is not a substitute for tokenisation or encryption when you need the original value back — and hashing predictable data (like card numbers, which have known structure) provides weaker protection than it appears to.
What does this mean for your systems?
- Never store raw card numbers; use your provider's tokens instead.
- Mask sensitive values in logs and interfaces — show at most the first six and last four digits of a card. See logging, masking and audit trails.
- Keeping card data out of your systems entirely, via a hosted checkout and tokenisation, is also the single biggest reducer of PCI DSS scope.