Security and Authentication

How the industry protects card data at every stage, and what happens when it fails.

Every module so far has described a system built on trust. The cardholder trusts that their card details are safe. The merchant trusts that the payment is legitimate. The acquirer trusts that the merchant is not laundering transactions. The issuer trusts that the person on the other end of the transaction is who they claim to be.

Security is what makes that trust possible. It is also the area where the payments industry has invested the most and where the consequences of failure are the most severe. A single data breach can compromise millions of card numbers. A single authentication failure can open the door to fraud at scale. The security architecture of card payments is layered, complex, and continuously evolving.

This module covers the five layers of payments security: PCI DSS compliance, encryption, tokenisation, authentication (including 3D Secure), and fraud detection. We will explain how each layer works, where it sits in the transaction lifecycle, and how they interact to protect the system.

Security in payments is not a single technology. It is a layered architecture where each layer compensates for the limitations of the others. Understanding these layers is essential for anyone building, evaluating, or operating payments infrastructure.

The Five Layers of Payments Security

Payments security operates in layers. No single mechanism prevents all fraud or protects all data. The system works because multiple defences operate simultaneously, each catching what the others miss.

PCI DSS: The Rules of the Game

The Payment Card Industry Data Security Standard (PCI DSS) is the mandatory security framework for any organisation that stores, processes, or transmits cardholder data. It is administered by the PCI Security Standards Council, which was founded by Visa, Mastercard, American Express, Discover, and JCB.

PCI DSS version 4.0 (effective March 2025) is the current standard. It contains 12 core requirements organised into six categories: build and maintain a secure network, protect cardholder data, maintain a vulnerability management programme, implement strong access control, regularly monitor and test networks, and maintain an information security policy.

The level of compliance required depends on the merchant's transaction volume:

For most modern merchants, the easiest path to PCI compliance is not to handle card data at all. By using a hosted payment page or a gateway with tokenisation (like Stripe Elements or Adyen's drop-in components), the merchant's systems never see raw card numbers. The PCI scope shrinks dramatically, and the compliance burden drops from hundreds of requirements to a handful.

PCI DSS is the baseline, not the ceiling. Compliance means you meet the minimum standard. It does not mean you are secure. The most damaging data breaches in payments history occurred at companies that were PCI compliant at the time of the breach.

Encryption: Protecting Data in Motion and at Rest

Encryption is the mechanism that protects card data from interception. It operates at two stages: in transit (when data is moving between systems) and at rest (when data is stored).

Encryption in Transit

Every connection that carries card data must use TLS (Transport Layer Security), currently at version 1.2 or 1.3. When a customer enters their card details on a checkout page, TLS encrypts the data before it leaves the browser. The same encryption protects the communication between the gateway, processor, acquirer, and network.

PCI DSS 4.0 mandates TLS 1.2 as the minimum for any system handling card data. Older versions (TLS 1.0 and 1.1) are prohibited because of known vulnerabilities.

Encryption at Rest

If card data must be stored (a rare requirement in modern architectures, but sometimes necessary for recurring billing or data analysis), it must be encrypted using strong cryptographic algorithms. AES-256 is the industry standard. The encryption keys must be stored separately from the data they protect, rotated regularly, and managed according to strict key management procedures.

Point-to-Point Encryption (P2PE)

For card-present transactions, P2PE encrypts card data at the terminal before it enters the merchant's environment. The data remains encrypted through the merchant's network and is only decrypted at the processor's secure facility. This means the merchant's systems never see unencrypted card data, even temporarily. P2PE-validated solutions are certified by the PCI Security Standards Council and significantly reduce the merchant's PCI scope.

Tokenisation: Removing the Target

Encryption protects data by making it unreadable. Tokenisation takes a different approach: it removes the sensitive data entirely and replaces it with a non-sensitive substitute (a token) that has no exploitable value outside its intended context.

There are two types of tokenisation in card payments, and the distinction matters:

Gateway (Merchant) Tokenisation

The payment gateway (like Stripe, Braintree, or Adyen) stores the card number in its vault and gives the merchant a token. The merchant uses this token for recurring charges, one-click checkout, and card-on-file transactions. If the merchant switches gateways, the tokens are not portable because they are specific to that gateway's vault.

Network Tokenisation

The card network itself (Visa Token Service, Mastercard MDES) replaces the PAN with a network-level token. Network tokens are more powerful than gateway tokens for several reasons: they are updated automatically when a card is reissued (reducing failed recurring payments), they include domain restrictions (a token issued for one merchant cannot be used at another), and they carry higher trust with issuers, resulting in higher authorisation rates.

Both Visa and Mastercard are mandating network tokenisation for card-on-file transactions, as we covered in Module 3. This mandate is driving rapid adoption. For merchants, the benefits are tangible: network-tokenised transactions see authorisation rate improvements of two to five percent because issuers trust them more than raw PAN transactions.

Tokenisation does not prevent fraud. It reduces the value of a data breach to near zero. If a hacker steals a database of tokens, they have nothing they can use. The target has been removed.

3D Secure: Authenticating the Cardholder

Encryption and tokenisation protect card data. Authentication answers a different question: is the person making this transaction the legitimate cardholder?

3D Secure (3DS) is the industry standard for cardholder authentication in card-not-present transactions. The "3D" refers to three domains: the issuer domain, the acquirer domain, and the interoperability domain (the card network). The protocol enables the issuer to authenticate the cardholder during an online transaction before the authorisation is processed.

How 3DS 2.0 Works

The original 3D Secure (version 1.0) was widely disliked because it redirected customers to a separate page and required a static password, causing significant cart abandonment. 3DS 2.0 (and the current version 2.3) solved this by introducing risk-based authentication: the issuer evaluates the risk of the transaction using data provided by the merchant and only challenges the cardholder when the risk is high.

Strong Customer Authentication (SCA)

In the EEA and UK, PSD2 mandates Strong Customer Authentication for most electronic payments. SCA requires two of three factors: something the customer knows (password or PIN), something they have (phone or card), and something they are (fingerprint or face). 3DS 2.0 is the primary mechanism for satisfying SCA requirements on card-not-present transactions.

SCA enforcement has had a measurable impact on the European payments landscape. Fraud rates on authenticated transactions have dropped significantly. Cart abandonment spiked initially as issuers were overly aggressive with challenges, but has stabilised as risk-based authentication improved. The frictionless flow rate (transactions that pass 3DS without a challenge) now exceeds 85 percent in mature markets.

The Liability Shift

The commercial incentive for merchants to implement 3DS is the liability shift. When a merchant uses 3DS and the issuer authenticates the cardholder, liability for fraud chargebacks shifts from the merchant to the issuer. If the issuer approves a 3DS-authenticated transaction that later turns out to be fraudulent, the issuer bears the loss, not the merchant. This liability shift is one of the most important economic mechanisms in payments security.

Fraud Detection: The Last Line of Defence

Encryption protects data. Tokenisation reduces exposure. Authentication verifies identity. Fraud detection catches everything else. It is the final layer, operating in real time during and after the transaction.

Modern fraud detection is built on machine learning models trained on billions of transactions. These models evaluate each transaction against hundreds of signals to produce a risk score. The signals include:

• Transaction velocity. How many transactions has this card attempted in the last hour, day, week? Rapid sequences of transactions are a classic fraud pattern.
• Geolocation. Does the transaction location match the cardholder's normal geography? A card used in London and then in Lagos within an hour is suspicious.
• Device fingerprinting. What device is being used? Has this device been seen before? Is the device spoofing its characteristics?
• Behavioural biometrics. How the user types, moves their mouse, and navigates the site. Bots and human fraudsters exhibit different behavioural patterns.
• Transaction characteristics. Is the amount unusual for this merchant or this cardholder? Is the product category high-risk (electronics, gift cards)? Is the shipping address different from the billing address?
• Network-level signals. Visa Advanced Authorization and Mastercard Decision Intelligence score transactions as they pass through the network, adding their own risk assessment to the issuer's evaluation.

The fraud detection ecosystem is large and growing. Sift, Forter, Riskified, Featurespace, and Sardine are among the dedicated fraud prevention companies. Every major gateway and processor also offers built-in fraud tools. The challenge is calibration: too aggressive and you decline legitimate customers (false positives). Too permissive and you let fraud through. The cost of false declines, lost revenue from legitimate customers who give up, often exceeds the cost of the fraud itself.

Fraud prevention is a calibration problem, not just a detection problem. The best fraud teams are not the ones that block the most transactions. They are the ones that maximise the revenue from legitimate customers while keeping fraud losses within acceptable bounds.

AI in Fraud: The Arms Race Accelerates

Both sides of the fraud equation are now using artificial intelligence. Defenders use machine learning to detect patterns in real time. Attackers use generative AI to create synthetic identities, produce deepfake voice authentication, and craft sophisticated phishing campaigns at scale.

The current generation of AI fraud threats includes:

• Synthetic identity fraud. AI-generated identities that combine real and fabricated data to pass KYC checks and obtain credit. These identities are used to open accounts, build credit history, and then "bust out" with maximum fraud before disappearing.
• Voice deepfakes. AI-generated audio that mimics a legitimate customer's voice to pass phone-based authentication. Credit unions and banks are particularly concerned as they prepare for AI agents interacting with their systems.
• Automated card testing. AI-powered scripts that test stolen card numbers at scale, rapidly identifying which cards are still active and valid before using them for larger fraudulent purchases.

Mastercard has responded with a generative AI model trained on its transaction data to improve cyber defences. Both networks are investing heavily in AI-powered fraud detection that can adapt to new attack patterns in real time, not just patterns seen in historical data.

Glossary