US reader? SCA is a UK/EU regulatory regime — your equivalent landscape (Reg E, NACHA WEB Debit, Visa/Mastercard Compelling Evidence 3.0) is different. The 3DS2 protocol details below still apply because the EMVCo spec is global.
Think of 3D Secure as the digital equivalent of a bank asking for your PIN at an ATM. It's that extra security check to prove you really are who you say you are when buying something online. This security layer protects both you and the merchant from the headache of online fraud.
This guide covers the protocol itself — how 3DS2 actually works, the difference between frictionless and challenge flows, the SCA exemptions you can stack on top, and how PSD3 changes the picture for 2026 and beyond. If you take card payments by phone rather than online, the equivalent fraud control isn't 3DS2 at all — it's DTMF masking to keep card data out of the call, which is what we build at Paytia.
3DS2 and SCA: how the protocol satisfies the regulation#
3DS2 is a protocol. SCA — Strong Customer Authentication — is a regulation. They're not the same thing, and the most common confusion we see from finance directors is treating them as one item on the compliance list. They're not.
SCA is the requirement, codified in PSD2 in the EU and the UK's Payment Services Regulations 2017 (as amended). It says any electronic payment over €30 / £30 from a payer's account has to be authenticated using two of three factors: something you know (password, PIN), something you have (phone, hardware token), something you are (biometric). 3DS2 is the dominant way card schemes satisfy that requirement for card-not-present transactions in Europe.
The reason this matters in 2026: SCA enforcement on UK and EU e-commerce is fully live. There's no soft-decline grace period left. Non-SCA-authenticated transactions get declined by the issuer unless they qualify for a specific exemption, and the issuer is the one who decides whether the exemption flies. If you're a merchant trying to maximise authorisation rates, your job isn't "turn 3DS2 on". Your job is to send enough data with every transaction that the issuer can either authenticate frictionlessly or honour the right exemption.
What "3DS2 SCA" actually means in your checkout flow
When a customer presses pay on your checkout, your payment service provider sends a 3DS2 authentication request — the AReq — to the issuer through the card scheme. Inside that AReq sit those 100-plus data elements: device fingerprint, browser data, billing and shipping match, transaction amount, currency, the cardholder's name and email, prior-transaction history if you've sent it.
The issuer's Access Control Server takes that data and runs a risk score. Based on that score and any SCA exemption flag you've sent, it returns one of three outcomes:
- Frictionless approve — the issuer is satisfied the customer is real, SCA is considered done at the data layer, the transaction proceeds without a challenge. This is what every merchant wants on every transaction. In well-tuned UK flows we see frictionless rates of 60–80% on regular customers.
- Challenge — the issuer wants the customer to actively confirm, so they push a biometric or one-time-code prompt to the customer's banking app or SMS. The transaction holds until the challenge is completed. Cart abandonment on challenges runs 15–25% even in 2026.
- Decline — the issuer doesn't trust the transaction enough to challenge it, or your AReq was missing fields the issuer required. The transaction fails.
Frictionless and challenge both satisfy SCA. Frictionless does it by sending enough proof that the issuer's risk engine signs off without prompting the customer. Challenge does it by making the customer perform the two-factor live. The protocol's whole job is to keep as many transactions as possible in the frictionless lane without sacrificing the SCA requirement.
The SCA exemptions you can stack on top of 3DS2#
Even with SCA fully in force, there's a defined list of exemptions a merchant can flag in the AReq. Get these right and your challenge rate drops meaningfully without you ever turning SCA off — because you can't turn it off.
Transaction Risk Analysis (TRA)
The big one. If your acquirer's fraud rate sits below a published threshold — currently 0.13% to qualify for a TRA exemption on transactions up to €500, 0.06% up to €250, 0.01% up to €100 — they can flag eligible transactions as exempt from a challenge. The catch: it's your acquirer's fraud rate that determines the cap, not yours, and the acquirer has to opt in to support TRA flagging. Plenty of UK acquirers still don't.
Low-value transactions
Transactions under €30 / £30 can be flagged as exempt, but only five consecutive times before SCA is forced again, and only up to a rolling €100 / £100 cumulative limit per card. The protocol tracks this at the issuer. You can't game it.
Trusted beneficiary
If a customer adds you to their bank's trusted list — many UK banks let this happen mid-challenge with a "trust this merchant" checkbox — future transactions from that customer to you get exempted from SCA. The customer-side adoption is patchy but worth knowing about for high-frequency repeat businesses.
Merchant-Initiated Transactions (MIT)
Recurring billing, subscriptions, no-show fees, top-ups. The initial transaction needs SCA (a Customer-Initiated Transaction, CIT, that establishes the mandate). Subsequent MIT transactions don't trigger SCA at all because the cardholder isn't present. The protocol calls this out-of-scope-of-SCA, and the AReq carries an MIT flag.
Mail Order / Telephone Order (MOTO)
If you take a card payment over the phone, the transaction is technically out of scope of SCA entirely — there's no online channel for 3DS2 to run on. That's a regulatory gift for phone payments, but it doesn't get you off the hook for PCI DSS. The card data still passes through your agent's headset, your call recording, your CRM screen. That's the gap DTMF masking fills — the customer types the card on their phone keypad, the agent never hears it, the PCI scope drops.
Secure corporate payments
Lodged-card programmes, virtual cards, anything routed through a corporate ID that meets PSD2's secure-payment-process criteria. Mostly relevant to travel and procurement. Rarely the cost-saving lever a B2C merchant is looking for.
The exemption you're going to see the biggest authorisation lift from is TRA. Get on an acquirer that supports it, get your fraud rate clean, and you'll quietly clear most of your eligible transactions without a challenge.
What changes under PSD3 and the PSR in 2026#
The European Commission published the PSD3 / PSR (Payment Services Regulation) proposals in June 2023. The Council reached a general approach in mid-2025. As of May 2026, the trilogue between Commission, Council and Parliament is winding up; the consolidated text is widely expected to be adopted in the second half of 2026, with the regulation applying 18 months after publication. So PSD3 isn't in force yet — but it's close enough that any new 3DS2 build should be designed against the direction of travel.
What we know is changing
SCA exemption criteria stay broadly the same but get clearer. The TRA thresholds are expected to remain, but the European Banking Authority is consolidating how acquirers report fraud and how often the bands get re-calculated. Expect more cards in scope of the higher exemption bands as fraud rates fall industry-wide.
Accessibility-driven exemptions get formalised. Customers who can't use one of the three SCA factors — for instance, blind customers who can't see an SMS, or older customers without smartphones — currently get caught in failed-SCA loops. PSD3 gives banks an obligation to provide alternative SCA methods, and gives merchants a clearer route to flag accessibility-exempt transactions.
Direct merchant liability for failed authentication shifts. Under PSD2, the liability-shift mechanic was 3DS2-fully-authenticated transactions move fraud chargebacks from merchant to issuer. PSD3 keeps that mechanic and tightens it: issuers that wrongly decline an SCA-eligible transaction can be held liable for the lost sale in defined cases. That's not just a 3DS2 protocol change — it's a regulatory hammer the industry hasn't had before.
SCA delegation to merchants gets a clearer framework. Delegated authentication — where the merchant performs the SCA themselves using biometric data they already have (think Apple Pay, in-app face ID) — was technically allowed under PSD2 but legally murky. PSD3 / PSR will give it a defined legal basis. Expect more wallet-led delegated SCA in 2027 and beyond.
Open Banking convergence. The PSR aligns payment initiation services (Open Banking) with card payments on the SCA front. The Open Banking equivalent of 3DS2 — the bank's app authenticating the payer directly — gets the same regulatory weight as a 3DS2 challenge. For merchants this matters because Pay-by-Bank becomes a more competitive alternative to cards in the SCA-required band.
What you should be doing about PSD3 now
Three things. First, audit your existing 3DS2 data flow: are you sending all 100-plus AReq fields, including the optional ones? Most merchants we look at are sending 60–70% of what the AReq supports, which costs them frictionless rate. Second, pick an acquirer that supports TRA exemption flagging if yours doesn't — the lift from getting eligible transactions exempted is bigger than any other single optimisation. Third, plan for delegated SCA: if you have a high-repeat customer base, the ability to perform SCA inside your own app (with the right certification) will become a material competitive advantage by 2027.
3DS 2.1, 2.2, 2.3 — which version are you actually on?#
EMVCo has shipped three minor versions of the 3DS2 spec. They're not interchangeable, and your acquirer's gateway is probably on a different one to your issuer's ACS.
3DS 2.1 shipped in 2017 and was the first mass-adoption version. Most UK and EU issuers were on 2.1 by 2019. It supports browser-based and in-app authentication, the AReq/ARes/CReq/CRes message set, and a basic device fingerprint.
3DS 2.2 shipped in 2018 and added the SCA exemption flagging (TRA, low-value, trusted beneficiary, MIT) into the protocol itself. Before 2.2 those exemptions existed in regulation but the AReq couldn't carry them. If your stack is on 2.1 you're not flagging exemptions at the protocol level — you're missing the biggest lever there is.
3DS 2.3 shipped in 2021 and is the current version most issuers are migrating to. Headline changes: native support for non-payment authentication (so a card-on-file save can be SCA'd without a payment alongside it), better support for delegated SCA, native handling of the SPC (Secure Payment Confirmation) browser API, and richer challenge flows that include passkeys.
What you should ask your PSP this week: which version of the EMV 3DS spec is your gateway sending, and what version is the response coming back as? If either side is still on 2.1, you're authenticating but you're not flagging exemptions, and your challenge rate will be higher than it needs to be.
How 3DS2 affects your phone-payment channel (it doesn't)#
One trap we see UK contact centres fall into: a finance director reads about 3DS2 and SCA, assumes it applies to phone payments, and goes hunting for a 3DS2 vendor for the call centre. It doesn't apply. Phone payments are MOTO under PSD2 and PSD3, and MOTO is explicitly out of scope of SCA. The fraud-control problem on a phone payment is completely different.
On a phone call, the card-not-present fraud risk isn't "is the customer who they say they are" — it's "who in the chain has access to the card data and what could they do with it". The agent. The recording. The CRM screen. The chat transcript. The QA reviewer. PCI DSS v4.0.1's whole approach to phone payments is to keep card data out of those touchpoints, which is what DTMF masking does and what we've been operating since 2016. The customer keys the PAN on their handset, the keypad tones get muted from the recording, your phone payment goes through, and the agent never hears or sees the card.
If you take card payments by phone and you've been told to "add 3DS2 to your contact centre", push back on that advice. The right control is descoping, and the right mechanic is keeping card data out of your environment in the first place. Our PCI DSS v4 phone payments checklist walks through what does apply.
What Is 3D Secure Authentication#
At its heart, 3D Secure (3DS) is a security protocol built to stop fraud in online credit and debit card payments. It adds a step where your identity is verified by the card networks themselves, like Visa (Visa Secure) and Mastercard (Mastercard Identity Check).
This process is like a digital handshake between everyone involved, making sure the person typing in the card details is the actual owner. It was designed specifically to fight Card-Not-Present (CNP) fraud—the all-too-common scenario where a criminal uses stolen card details to make purchases. The fact that the global 3D Secure market was valued at $1.10 billion in 2022 tells you just how essential it has become in modern commerce.
The Three Domains of Security
So, what does the "3D" actually stand for? It's not about graphics; it refers to the three distinct domains, or parties, that work together during the authentication check. Understanding these roles is the key to seeing how it all fits together.
- The Issuer Domain — This is simply the bank that issued your credit or debit card. They're responsible for checking that you are, in fact, you.
- The Acquirer Domain — This is the merchant's side of the equation—their business bank and payment processor. They are the ones requesting the security check to make sure the sale is legitimate.
- The Interoperability Domain — This is the infrastructure, run by the card scheme (like Visa or Mastercard), that securely connects the other two domains. Think of it as a secure courier, passing messages between the merchant and your bank.
By linking these three domains, 3D Secure creates a closed loop of verification. It's like having the customer, the shop, and the bank's security guard all in the same room confirming the purchase is valid before any money changes hands.
This table shows the clear difference between a standard online payment and one protected by 3D Secure.
Standard vs 3D Secure Authenticated Payments
| Feature | Standard Card Payment | 3D Secure Authenticated Payment |
|---|---|---|
| Verification Method | Relies on card details (number, expiry, CVV) | Adds a layer of authentication with the cardholder's bank |
| Data Exchange | Basic transaction data sent to the payment gateway | Rich data is shared between merchant, issuer, and acquirer |
| Authentication Step | None beyond basic card info | Cardholder identity is verified via a challenge (e.g., OTP) or frictionless flow |
| Liability for Fraud | Typically rests with the merchant | Shifts from the merchant to the card-issuing bank |
| Fraud Risk | Higher, as it relies on static, stolen information | Significantly lower due to real-time identity verification |
As you can see, 3D Secure introduces a solid verification process that makes every transaction safer.
How It Protects Businesses and Customers
This collaborative security model offers a win-win. For customers, it's an extra shield, making it much harder for thieves to use stolen card details for unauthorised purchases. It gives you peace of mind that your bank is actively double-checking things behind the scenes.
For merchants, the main benefit is a powerful protection called liability shift. When a transaction is successfully authenticated using 3D Secure, the financial responsibility for any fraudulent chargebacks typically moves from the merchant to the card-issuing bank. This dramatically cuts the financial risk of taking payments online and helps build a more trustworthy e-commerce environment for everyone.
The Evolution from 3DS1 to 3DS2#
The story of 3D Secure authentication is one of moving from a well-intentioned but often clumsy security measure to the smarter, more customer-friendly system we have today. The original version, 3DS1, was a genuine attempt to tackle the growing problem of online fraud.
However, if you've ever been abruptly redirected to a clunky, bank-branded pop-up window during checkout, asking for a password you barely remember setting up, you've experienced 3DS1 firsthand. It wasn't exactly a pleasant experience.
This sudden redirect was a massive point of friction. It interrupted the checkout flow, looked suspicious to many shoppers, and was terribly optimised for the growing wave of mobile commerce. The result? High cart abandonment. Businesses were losing sales not over price or product, but because the final security step was just too much hassle.
The Need for a Smarter Approach
It was crystal clear that a new solution was needed—one that could provide solid security without torpedoing the customer experience. The world was going mobile, and payment security had to catch up. This pressure is what drove the development of 3D Secure 2 (3DS2).
3DS2 was rebuilt from the ground up, designed specifically for how we pay now—online and on our phones. Its main goal was to make the authentication process as invisible as possible, creating what we now call the frictionless flow.
Think of 3DS1 as a security guard who stops and questions every single person entering a building, no matter who they are. 3DS2 is the upgraded, smarter guard who recognises the regulars and waves them through, only stopping an unfamiliar face for a quick ID check.
This new, risk-based approach completely changed the game, moving from an active, in-your-face verification to a passive, background analysis.
This screenshot shows a typical 3DS1 verification page—a common sight that often caused confusion and frustration for online shoppers.
The pop-up window, often with inconsistent branding, would disrupt the user's journey and directly contribute to lost sales for merchants.
How 3DS2 Creates a Smoother Experience
3DS2's frictionless flow runs on data. Where 3DS1 only looked at a few basic details, 3DS2 can securely share over 100 different data elements between the merchant and the customer's bank to assess the risk.
This rich data paints a detailed picture, helping the bank make a highly accurate decision in milliseconds. Key data points often include:
- Device Information — Is the customer using a recognised phone or laptop?
- Transaction History — Does this purchase fit their usual spending habits?
- IP Address and Geolocation — Is the payment coming from a familiar location?
- Browser Details — The browser and OS the customer is using.
Frequently asked questions about 3DS2 and SCA in 2026#
Is 3DS2 the same as SCA?
No. 3DS2 is the protocol most card schemes use to satisfy SCA for online card payments. SCA is the regulation. 3DS2 is the implementation method. You can satisfy SCA via other methods too — Open Banking app-to-app, in-app delegated authentication, secure corporate payment flows — but for card payments on a checkout page, 3DS2 is the default.
Does 3DS2 work without SCA being in force?
Yes. 3DS2 is a global EMVCo standard and gets used in markets where SCA doesn't apply (US, most of Asia) primarily for liability shift on chargebacks rather than regulatory compliance. The protocol runs the same way; only the exemption logic and the regulatory weight change.
What's the difference between 3DS 2.2 and 2.3?
2.2 added SCA exemption flagging into the protocol (TRA, low-value, trusted beneficiary, MIT). 2.3 added native non-payment authentication, better delegated SCA support, the SPC browser API, and passkey-based challenges. If your gateway is on 2.1 you're missing exemption flagging; if it's on 2.2 you're missing the modern challenge UX.
What is the TRA exemption and how do I qualify?
Transaction Risk Analysis is an SCA exemption that lets your acquirer flag transactions as low-risk based on their aggregate fraud rate. Three bands: under 0.13% fraud rate exempts up to €500, under 0.06% exempts up to €250, under 0.01% exempts up to €100. The fraud rate that matters is your acquirer's, not yours individually, and the acquirer has to support TRA flagging in their 3DS2 integration. Plenty of UK acquirers still don't.
Does PSD3 replace PSD2 immediately?
No. As of May 2026, PSD3 / PSR are still in trilogue. Adoption is expected in late 2026 and the regulation typically applies 18 months after publication, so realistic in-force date is mid-to-late 2028. That doesn't mean you ignore it — any new 3DS2 build should be designed against PSD3's direction of travel (clearer exemption criteria, delegated SCA framework, Open Banking convergence) so you're not retrofitting later.
Does 3DS2 apply to phone payments?
No. Phone payments are MOTO under PSD2 and PSD3, which means they're explicitly out of scope of SCA. The fraud-control mechanic for phone payments is keeping card data out of the agent's hearing and your call recording — that's DTMF masking, not 3DS2.
What is delegated authentication?
SCA performed by the merchant or the wallet (Apple Pay, Google Pay, your own in-app biometric) rather than by the issuer's bank app. The merchant holds the SCA factor data, performs the authentication, and signals to the issuer that SCA has already been satisfied. Allowed in principle under PSD2 but legally fuzzy; PSD3 / PSR formalise the framework. Expect material adoption from 2027 onwards.
What's the difference between MIT and CIT?
CIT — Customer-Initiated Transaction — is one the cardholder actively starts (a fresh online purchase, an in-store tap). It needs SCA. MIT — Merchant-Initiated Transaction — is one the merchant starts without the cardholder being present (subscription renewals, no-show fees, post-stay charges). MIT is out of scope of SCA because no customer is there to authenticate. The first transaction that establishes the mandate has to be a CIT with SCA; subsequent MITs run unauthenticated against the agreed mandate.
Will my chargebacks really drop with 3DS2?
For fraud chargebacks, yes — successful 3DS2 authentication moves liability from merchant to issuer, so the chargeback either gets refused at issue or comes back to you with the issuer eating it. For non-fraud chargebacks (item not received, item not as described, duplicate charge), 3DS2 does nothing. Those are dispute-process issues, not authentication issues.
Should I implement 3DS2 myself or rely on my PSP?
Rely on your PSP. Building 3DS2 directly requires EMVCo certification, a 3DS Server component, and ongoing maintenance against three active protocol versions. Every credible PSP — Stripe, Adyen, Worldpay, a major UK payment provider — handles 3DS2 invocation for you. Your job is to send rich AReq data fields and pick a PSP whose acquirer supports TRA exemption flagging.
