Payment security in 2026 rests on two foundational technologies: tokenisation, which eliminates sensitive card data from your systems entirely, and 3D Secure 2 (3DS2), which provides strong customer authentication with friction calibrated to transaction risk. Together they address the two leading vectors of payment fraud — card data theft and CNP (card-not-present) fraud — while maintaining the checkout conversion that drives payment business outcomes.
The Payment Security Landscape in 2026
Online card fraud costs merchants approximately $48 billion annually globally, with card-not-present fraud representing over 80% of card fraud losses. The payment industry's response has been two complementary security technologies: tokenisation removes the primary attack target (the card number) from merchant systems entirely, and 3DS2 verifies that the person using the card is the card owner — closing the fraud window even when card details are compromised.
For enterprise payment architects, both technologies are now regulatory requirements in key markets (PSD2 SCA mandates 3DS2 for European transactions), contractual requirements from card schemes (PCI DSS requires tokenisation for stored card data), and practical necessity for fraud rate management (issuers reject high-fraud merchants through decline rate pressure). This guide covers implementation requirements for both.
Payment Tokenisation: Types and Architecture
Network tokens (issued by Visa Token Service, Mastercard Digital Enablement Service, or American Express Token Service) replace the card's PAN with a token issued directly by the card network. Network tokens are portable across payment processors — the same token works regardless of which acquirer processes the transaction. Crucially, network tokens benefit from issuer-side optimisations: issuers treat network-tokenised transactions as lower risk, producing higher authorisation rates (typically 1–3% improvement) compared to equivalent PAN-based transactions. Network token integration requires working with a payment processor that supports the Token Requestor role.
Gateway tokens (PSP tokens) are issued by the payment gateway or processor, replacing the PAN in the merchant's systems with a gateway-specific substitute. Gateway tokens are simpler to implement than network tokens but are processor-specific — switching processors requires migrating all stored tokens through a migration process. For new implementations in 2026, network tokens are strongly preferred over gateway tokens due to portability and authorisation rate benefits.
Merchant tokenisation (replacing the PAN on the merchant's own servers) addresses PCI DSS scope reduction — a tokenised card number stored in the merchant's database has no value if the database is breached. This is the baseline PCI DSS requirement for stored card data and is typically handled by the payment gateway rather than requiring merchant-side cryptographic infrastructure.
Tokenisation architecture for stored card data: at checkout, the browser or mobile app sends card data directly to the payment gateway (never touching the merchant's servers — reducing PCI scope to SAQ A for e-commerce), the gateway returns a token, and the merchant stores only the token for future transactions. For subscription billing, this token enables future charges without re-entering card details — critical for subscription conversion and involuntary churn reduction.
3D Secure 2: How It Works and Why It Matters
3DS2 is the second generation of the 3D Secure authentication protocol, standardised by EMVCo and required for PSD2 Strong Customer Authentication compliance in Europe. It addresses the critical failure of 3DS1 — disruptive authentication friction that caused 30–40% cart abandonment — with a risk-based authentication model that reduces friction to near-zero for low-risk transactions while applying strong authentication only when genuinely warranted.
Frictionless flow handles 90–95% of transactions in optimised implementations without any customer authentication prompt. The issuer evaluates 100+ data points transmitted in the 3DS2 authentication request — device fingerprint, shipping address consistency with previous transactions, transaction velocity, behavioural biometrics — and approves low-risk transactions in the background without any customer interaction. The customer experiences a seamless checkout with no authentication prompt.
Challenge flow applies when the issuer's risk engine scores a transaction as higher risk. The customer is prompted for additional verification — biometric authentication, one-time passcode, or in-app approval through their banking app. 3DS2's challenge experience is significantly less disruptive than 3DS1's redirect to external authentication pages.
SCA exemptions enable merchants and payment processors to request that specific transactions bypass SCA entirely under PSD2's exemption framework: low-value transactions (under €30), trusted beneficiary (customer has whitelisted the merchant), low-risk transactions (transaction risk analysis — TRA exemption), and merchant-initiated transactions (subscriptions, recurring charges). Intelligent exemption management that maximises exemption application to low-risk transactions is where 3DS2 optimisation generates the most conversion value.
| Feature | 3DS1 | 3DS2 |
|---|---|---|
| Authentication experience | Redirect to issuer page, static password | In-checkout, risk-based, biometric-capable |
| Data points for risk scoring | ~15 | 100+ |
| Frictionless rate (optimised) | 0% | 90–95% |
| Mobile app support | Poor | Native (in-app challenge) |
| SCA exemptions | Not supported | Full exemption framework |
| Liability shift | On authentication | On authentication |
Implementing Tokenisation and 3DS2
For most merchants, tokenisation and 3DS2 are implemented primarily through the payment processor rather than custom development. Select a payment processor with native network token support (Adyen, Stripe, Braintree), integrated 3DS2 implementation, and intelligent SCA exemption logic. The configuration work involves: enabling network token provisioning in processor settings, configuring 3DS2 with appropriate exemption triggers, and implementing the frictionless/challenge flow in your checkout UI.
The critical custom integration work is in SCA exemption decision logic — determining which transactions to request exemptions for, which to submit for 3DS2 authentication, and which to route through merchant-initiated transaction (MIT) pathways for subscription charges. This logic should be regularly reviewed against fraud rate data and conversion metrics to optimise the balance between fraud protection and checkout friction.
Network Token vs Gateway Token Comparison
Payment Security Implementation Roadmap
Map all locations where card data currently exists in your systems: checkout flow, order records, logs, analytics events, third-party integrations. Every PAN exposure point is a PCI DSS scope element and a breach risk. Most organisations discover unexpected PAN data in logs and analytics systems during this audit — these must be remediated before tokenisation is complete.
Enable network token provisioning through your payment processor. Migrate existing stored card-on-file data to network tokens if the processor supports bulk migration; otherwise migrate organically as customers re-transact. Verify that no PAN data persists in application databases, logs, or analytics after tokenisation implementation.
Enable 3DS2 through your payment processor with initial conservative exemption settings. Monitor frictionless rate, challenge rate, fraud rate, and conversion rate for 4–6 weeks. Iteratively optimise exemption thresholds based on observed fraud rates by exemption type, transaction value band, and customer risk profile.