Encryption
What is encryption?
Encryption is a security process that converts readable data into an unreadable format, so only a party holding the correct decryption key can restore the original. The unreadable output is called ciphertext.
In payments, encryption protects data while it moves and while it sits in storage. Card numbers, expiry dates, and the travel encrypted from the checkout page to the , the , and the , and stored records are encrypted again at rest. sets the encryption expectations for cardholder data, while data-protection regimes such as GDPR and HIPAA cover personal and health data more broadly.
Key facts
- What it protects: card numbers, expiry dates, card verification values, login credentials, and personal data, both in transit and at rest
- Two main types: symmetric (one shared key encrypts and decrypts) and asymmetric (a public key encrypts, a private key decrypts)
- Applies to: anyone who stores or transmits cardholder data, including merchants, , acquiring banks, and issuing banks
- Required by: PCI DSS for cardholder data, plus GDPR and HIPAA for personal and health data
- Reversible: yes, with the key. That is what separates encryption from and hashing
Types of encryption
By key structure
- Symmetric encryption uses the same key to encrypt and decrypt. It is fast, which suits large volumes such as stored transaction records. AES is the common family.
- Asymmetric encryption uses a public key to encrypt and a matching private key to decrypt. It is slower, so it is generally used to exchange keys and verify identity rather than to encrypt bulk data. RSA and elliptic-curve algorithms are the common families.
TLS uses both. The handshake relies on asymmetric keys to agree on a symmetric session key, and the transaction data then travels under that session key.
By where the data sits
- In transit – TLS protects data moving between the cardholder's browser, the merchant's server, the PSP, and the card networks. Point-to-point encryption applies the same idea to card-present terminals by encrypting at the reader, before the data reaches the merchant's systems.
- At rest – stored card numbers are encrypted in a database or vault, with the keys held in a separate system so a copied database doesn't yield usable card data.
Why it matters
- Intercepted traffic is unusable without the key. An attacker who captures an encrypted message sees ciphertext, not a card number they can charge.
- A breach of an encrypted data store exposes ciphertext. The card data stays unusable for as long as the keys sit in a separate system that was not also taken.
- Encryption of cardholder data is a condition of PCI DSS validation for merchants, PSPs, and acquiring banks. Penalties for failing validation are set by scheme rules and vary by scheme and volume, and are typically passed to the merchant through the acquiring bank.
- Encryption keeps data confidential. Confirming who is behind a is a separate job, handled by authentication tools such as .
Encryption vs tokenization
Both keep clear card data out of merchant systems, and the practical difference is reversibility: encrypted data can be turned back into a card number with the key, a token cannot.
| Method | Reversible? | Typical payments use |
| Encryption | Yes, with the decryption key | Protecting card data in transit and at rest |
| No. The token maps to the card in a separate vault | Charging a saved card without storing the number | |
| Hashing | No | Matching values, such as recognising a repeat card, without keeping the number |
