Encryption in payments is a non-negotiable aspect of securing transactions, protecting customer information, and preventing data breaches. Beyond understanding how it works, it’s crucial for merchants and service providers to understand their encryption responsibilities under PCI DSS and how to reduce compliance scope without compromising system security.
This article explores how payment encryption works, different types of encryption in payments, PCI DSS encryption requirements, and how encryption fits into a multi-layered security approach.
Encryption in payments is the process of protecting sensitive transaction information from exposure during transit or storage. It works by immediately transforming customer payment data into an unreadable format at the time of purchase, and protecting it as it travels through the payment ecosystem. If encrypted data isintercepted, it can’t be read without the decryption key, which is securely stored and protected by strict management controls.
Payment data needs strong encryption to reduce risk across the entire transaction process, both digitally and in person. It protects customers from fraud, shields merchants from data breaches, and most importantly, provides assurance that sensitive payment information is protected in modern transactions.
Encryption is fundamental for securing payment data and has benefits like:
This is how payment encryption works in action:
The customer enters payment details:
When a customer initiates a transaction, like checking out for an online purchase, they enter card details, which are automatically encrypted from plain text to cipher text.
Encrypted data is transmitted:
The merchant system (in this case, a shoppable website) sends encrypted customer data through a protected channel to the payment processor or acquiring bank. Once received, a secure key is used to decode the encrypted data.
Transaction approved, purchase authorised, payment settled:
If funds are available and no fraud is detected, the transaction will appear as completed on both customer and merchant systems.
This entire process is faster than the blink of an eye, creating a frictionless checkout flow for customers and a secure payment system for the business.
The two most common types of encryption in payments are symmetric and asymmetric.
Symmetric encryption:
Uses ONE secure key for both encrypting and decrypting data. Common symmetric algorithms like the Advanced Encryption Standard (AES) support real-time transactions by scrambling cardholder information, but have downsides, like complicated key distribution, management, and storage logistics. This creates limits formulti-layered security systems, especially in complex or enterprise payment environments.
For this reason, symmetric encryption is typically used to encrypt payment data in controlled scenarios like:
Asymmetric encryption:
Uses TWO secure keys: a public key for encryption and a private key for decryption. Only the system owner (like a payment processor) has access to the secure private key. Asymmetric encryption is most common in today’s payment scenarios, especially for online transactions where customer data is transmitted to a gateway or processor.
While symmetric encryption scrambles the actual card data, asymmetric encryption enables:
Together, symmetric and asymmetric encryption create a smooth checkout experience without requiring the merchant to store payment data or access private decryption keys. Decryption and transaction completion remain exclusively within the processor’s control, as do obligations related to key security and management.
AES, or the Advanced Encryption Standard, is the system that actually scrambles card data into its encrypted format. This symmetric encryption algorithm uses such advanced math that it’s impossible to decode encrypted information without the correct key; there are simply too many possibilities.
AES comes in 128, 192, and 256-bit variants, and while all are highly resilient, AES-256 isthe standard for secure payment processing. AES-256 payment encryption uses a256-bit cryptographic key and 14 encryption rounds, creating 2²⁵⁶ possible keys to provide strong resistance againt attacks and long-term data protection.
Keys are the secret values that allow AES to encrypt and decrypt data. Keys function like long, complex passwords that enable algorithms to transform plain text into ciphertext and back again.
When considering payment data encryption, generating a strong key is essential for secure processing. But key management is what really keeps the entire system protected. Key management includes:
Best practices for key management typically use an external system, like a hardware security module (HSM), or key management software that runs on a dedicated server.
Proper keymanagement requires:
Proper key management drives secure payment processing and reduces compliance scope for merchants who, through proper asymmetric encryption, never need to store or handle decryption keys.
An important aspect of how payment encryption works is protecting data in transit between merchants, gateways, payment processors, and issuing banks. Because payment data needs to travel through multiple networks during a single transaction, in-flight encryption is paramount to ensuring sensitive data is never exposed as it moves through the payment system.
TLS (transport layer security, formerly known as SSL) enables secure communication by creating a virtual “safe tunnel” that payment data can travel through without exposure. Before card data leaves the customer’s browser or the merchant's system, TLS in payment processing verifies the server’s identity, encrypts the information throughout transmission, and makes sure that each connection uses a unique session key, freshly encrypting every transaction.
The way this happens is:
TLS handshake authenticates server:
When a user makes an online purchase, the server presents its TLS certificate to the browser during the TLS handshake. This server verification ensures the customer is communicating with a real merchant, not an attacker.
Secure channel established via asymmetric encryption:
With a validated certificate, TLS uses asymmetric cryptography to securely exchange keys, allowing both sides to derive a shared symmetric session key without ever transmitting it directly.
Transaction data encrypted with symmetric key:
After the handshake, the symmetric session key encrypts all payment data, commonly viaAES-256. Even if an attacker intercepts the traffic, transaction data can’t be decrypted without the symmetric session key determined during the TLS handshake.
TLS in payment processing allows merchants to depend on gateways and processors to handle decryption and much of the compliance burden, while maintaining a seamless checkout experience for customers.
TLS has gone through multiple iterations and the last major update came in 2018 from version1.2 to 1.3. Significant changes in TLS 1.3 are:
Faster handshakes:
TLS 1.3 considerably reduces handshake time, speeding up websites and transactions, and improving mobile checkouts. Beyond abetter user experience, this translates into higher conversion rates for merchants, who see fewer abandoned carts due to less friction during online purchases.
Stronger data protection:
While TLS 1.2 supported a range of cipher suites, TLS 1.3 only supports the five most modern AEAD cipher suites, which are the most secure. The updated TLS version removes:
TLS 1.3 also encrypts the handshake earlier than TLS 1.2, protecting information from the moment the transaction is initiated.
Reduced overhead: TLS 1.3 is much simpler than previous versions. It has fewer configuration options, making it easier to use and maintain. Straightforward implementation reduces overhead with faster, safer, and more efficient systems that are up to date with PCI best practices and compliance requirements.
Point-to-point encryption (P2PE) and end-to-end encryption payments (E2EE) are designed to protect data as it moves through the payment chain.
The main differences between P2PE vs E2EE for payment data encryption are:
Primary usecase
Where encryption starts
PCI scope reduction
Key management
At-rest encryption protects stored data rather than data in motion. This encompasses data on a device, server, disk, database, or in backups when they’re being stored.
At-rest encryption helps ensure that even if someone gains access to stored payment data, for example, on an unlocked POS or stolen laptop, all that’s visible is unreadable ciphertext.
However, this data can remain in PCI scope even though it requires a secure key for decryption. As a result, many merchants pair at-rest encryption with tokenisation, allowing them to operate without storing cardholder information in their own systems.
Tokenisation and encryption are often grouped together, but serve different purposes. Encryption masks data by scrambling it with a key, whereas tokenisation replaces sensitive information with a random string, known as a token.
When transaction data is encrypted, the original payment details still exist – they just need to be decrypted to process the transaction. However, with tokenisation, the token is used to complete payments, which removes the need ever to handle payment details. This system powers most subscription and recurring payment models, and plays a large part in mobile wallets, too.
When weighing tokenisation vs encryption, one isn’t necessarily better than the other. It depends on the information you need to protect, how you plan to use the data, and your overall compliance obligation. For the strongest approach, encryption should be combined with tokenisation and further layered with fraud detection and strong customer authentication to create an impenetrable security for safeguarding sensitive payment information.
Learn more about PCI Proxy’s tokenisation solutions and how we safeguard confidential data.
To align with PCI DSS encryption requirements, the following best practices should be adopted by merchants:
Strong cryptography:
PCI best practices require that data at rest be encrypted with AES-256 or an equivalent, while data in transit should use TLS 1.2 or higher. Outdated and weak algorithms like SSL, early TLS versions, RC4, and SHA-1 are no longer PCI DSS-compliant.
Data in transit:
Cardholder data, like PANs, must be encrypted when transmitted. Industry standards dictate that sensitive data is sent via authenticated communication channels like HTTPS with a validated SSL/TLS certificate. Payment information should never be sent in plaintext or via insecure methods like email or text messages.
Data at rest:
Stored payment information must be encrypted and protected with strict, role-based access controls. When displayed, sensitive data should always remain masked, except when authorised access is required. For example, showing only the final four digits of a customer’s PAN rather than the entire account number.
Beyond specific encryption requirements, there are also PCI DSS key management requirements, like:
Secure key storage:
Cryptographic keys must be kept in a safe location, either in organisation-owned tamper-resistant hardware such as an HSM or with a vaulting service.
Regular key rotation:
Keys must be updated or replaced within the defined crypto period, after a specified number of encryption operations, or when a key is compromised. When a key is replaced, the old one must be destroyed securely so it cannot be reused.
Restricted access controls:
Keys should be accessible only to authorised users, with risk spread across multiple parties. No single individual should have complete access or control over keys.
Regular risk assessment:
Penetration testing, vulnerability scans, and regular security assessments to find and fix weak links are required for PCIDSS compliance.
Comprehensive documentation:
Detailed documentation of encryption policies is vital for audits and consistency across systems. Encryption documentation should outline key creation, management, use, and storage, along with organisational security policies and access controls for encryption.
If a merchant outsources payment processing so they don’t have to store or process cardholder data within their environment, PCI DSS encryption requirements can be significantly reduced. That said, the merchant still has some compliance responsibilities depending on system integration and channels where data is transmitted. This ensures best practices are upheld by all entities in the payment process.
Some common encryption myths in payments include:
Myth: Encryption prevents merchants from fraud.
Reality: Encryption safeguards payment data from fraud, not transactions. Encryption is essential for security, but is not a fraud detection mechanism.
Myth: Encryption and tokenisation are the same thing.
Reality: Encryption protects stored and transiting data by scrambling it into an unreadable format, while tokenisation completely replaces the original data. The two often work together to protect sensitive information and increase payment security.
Myth: Strong encryption is enough for PCI DSS compliance.
Reality: PCI focuses just as much on key management as it does on the encryption process itself. Lack of proper key storage, rotation, or access controls can render even the strongest encryption useless.
Myth: Encrypted data is useless to attackers
Reality: If an attacker gains access to a decryption key, the encrypted data is readable. This is why PCI places such strong emphasis on key management, and why many merchants use tokenisation to reduce their compliance scope by keeping customer payment data out of their systems. [AG1]
The use cases for encryption in payments are far-reaching, especially when paired with tokenisation. The most common are:
E-commerce payments and online purchases:
Cardholder data is encrypted at point of entry on the browser and stays encrypted as it moves from the merchant server to the gateway and processor.
Mobile wallets and NFC transactions:
While mobile wallets like Apple and Google Pay rely mainly on tokenisation, encryption is still used to protect the token during transmission and to create a secure communication channel between the device, terminal, gateway, and issuer.
Recurring payments and subscription models:
Payment data is encrypted during the initial capture and for any transmission of stored credentials.
Bank transfers and account-to-account payments:
PANs, IBANs, routing details, and personal customer information are encrypted as the data moves between financial institutions.
In-person POS transactions:
Card data is encrypted the moment it hits the terminal, before it even reaches the merchant environment.
TLS on its own is not enough for PCI compliance, as PCI DSS also requires strong key management, data storage protection, network segmentation, strict access controls, and monitoring across the entire payment environment for full compliance.
You still need encryption if you use tokenisation because PCI DSS requires cardholder data to be encrypted during transmission, which happens before it can be tokenised.
Banks do use256-bit encryption, most commonly with AES-256 for data at rest and TLS with strong cipher suites for transmitting data.
Card payments are encrypted, meaning the payment data is scrambled for protection as it moves between the customer, merchant, gateway, and processor.
PCI DSS encryption requirements include strong encryption algorithms, encryption of data at rest and in transit, and strict controls on key storage and management.
Merchants can store encrypted cardholder data themselves, but this makes them responsible for meeting all PCI DSS requirements for secure storage, key management, and access controls. However, many merchants choose to use a third party to keep payment information out of their systems, which reduces their compliance scope.
.svg)
