3DS2 Liability Shift: How Authentication Works

When you see the term "3DS2" (also written "EMV 3-D Secure" or "3D Secure version 2") you're looking at a protocol developed for online card-not-present (CNP) payments, with the aim of improving authentication of the cardholder and reducing fraud.

Here's the breakdown of how it works, what it was designed to solve, and the specific purchase-use cases it addresses.

What's 3DS2 and why it was designed#

The original 3-D Secure (often called 3DS1) came about as a way to have the card-issuing bank authenticate that the person making an online transaction is in fact the cardholder — adding a layer of protection in card-not-present scenarios.

But over time the payments landscape changed: mobile apps, in-app purchases, digital wallets, and more sophisticated fraud attempts meant the original protocol had limitations (friction, poor UX, limited data).

Thus 3DS2 was developed. Its key design improvements include:

Richer data exchange between merchant/acquirer/issuer domains so risk can be assessed better (device, environment, behavioural data)
Support for mobile and in-app flows (not just browser redirect/pop-up)
Enabling a "frictionless" flow for lower risk transactions (i.e., authentication happens behind the scenes without requiring the cardholder to type a password or one-time code)

So in short: 3DS2 is designed to help merchants and issuers more effectively authenticate online transactions, improve customer experience for lower risk ones, and reduce the fraud risk inherent in CNP transactions.

It's worth understanding how much data 3DS2 can work with compared to the original. 3DS1 sent about 15 data elements to the issuer. 3DS2 can send over 100 — everything from the customer's device fingerprint and browser language to their transaction history with that merchant and the time they've been logged into their account. That volume of data lets the issuer's risk engine make far more accurate decisions about whether a transaction looks legitimate or suspicious.

The liability shift: what it means and when it applies#

One of the big practical incentives for merchants to adopt 3DS2 is the possibility of a liability shift. "Liability shift" means that under certain circumstances the financial responsibility for a fraudulent chargeback moves from the merchant to the card-issuing bank (issuer).

Here's how and when:

If a transaction is authenticated successfully via 3DS2 (or even 3DS1 in some regions) and the issuer accepts that authentication, then if the cardholder later disputes the transaction as unauthorised, the issuer may carry the burden instead of the merchant.
Conversely, if authentication isn't used, or fails, or the transaction doesn't meet the criteria, then the merchant remains liable.
Note — all card networks define their own rules about when liability shift applies (depending on region, card type, enrolment status, authentication result) so it's not a blanket guarantee.

In practical terms: by implementing 3DS2 properly, merchants reduce both fraud risk and risk of bearing the cost themselves when an unauthorised transaction results in a chargeback.

The financial impact can be significant. For a UK e-commerce merchant doing a million pounds in monthly card sales, even a 1% chargeback rate translates to ten thousand pounds in lost revenue — before you count the chargeback fees (typically fifteen to twenty-five pounds per dispute) and the operational cost of managing the dispute process. If 3DS2 shifts liability on half of those disputes, the merchant saves thousands per month. Over a year, it pays for the integration cost many times over.

Use cases: the specific purchase scenarios 3DS2 actually solves for#

Here are concrete scenarios where 3DS2 brings value:

1. Online retail checkout — guest purchases

A customer visits an e-commerce site as a guest (no account), enters their card details, and pays. This is classic card-not-present risk. With 3DS2, richer context data is supplied to the issuer (device, location, previous patterns) so the risk machine can decide: this looks low risk, no challenge needed, frictionless flow. The transaction completes smoothly. If later it turns out fraudulent and the authentication was done, the issuer may pick up liability.

Without 3DS2 — the merchant is exposed to fraud and chargebacks.

2. Mobile app purchases or in-app payments

Because 3DS2 supports mobile SDKs and non-browser flows, it's suitable for purchases via mobile apps or digital wallets. This is important given the shift to app-based commerce.

3. High-value or higher-risk purchases requiring stronger authentication (challenge flows)

While many transactions may be frictionless, where risk is higher the issuer can trigger a "challenge" (e.g., biometric, OTP, 2FA) via 3DS2. For example: first-time customer, large order, unusual delivery address. The authentication gives the merchant and issuer better confidence.

If completed, the liability shift applies in those cases too.

4. Cross-border / international e-commerce

Online merchants selling globally face greater card-not-present fraud risk (different timezones, shipping, unknown customers). 3DS2 enables collecting more signals and pulling in risk assessment which helps reduce fraud loss and shift liability.

5. Recurring payments / subscription first-time billing

While ongoing recurring payments may not always allow authentication each time, using 3DS2 at setup helps establish that the first transaction was properly authenticated and may reduce risk for the remainder of the subscription lifecycle. (Note: many card schemes treat MITs or recurring payments differently for liability shift).

How 3DS2 relates to phone payments#

One important thing to understand: 3DS2 was designed for online and app-based transactions. It doesn't apply to MOTO (Mail Order/Telephone Order) payments in the same way. Phone payments are exempt from Strong Customer Authentication under PSD2, which means they're also exempt from 3DS2.

That might sound like an advantage — no authentication friction for phone payments — but it also means phone payments don't benefit from the liability shift that 3DS2 provides. If a fraudulent chargeback comes in on a MOTO transaction, the merchant typically bears the cost.

This is one reason why having strong fraud controls on your phone payment channel is so important. Without 3DS2's protection, you need other defences — like real-time payment validation, address verification, and velocity checks — to catch fraud before it costs you money.

So what should merchants actually do about their phone payment channel? First, make sure you're flagging MOTO transactions correctly with your acquirer. If a phone transaction gets submitted as an e-commerce transaction by mistake, you'll face authentication failures and declines — because the issuer will expect 3DS2 data that isn't there. Your payment gateway or virtual terminal should be configured to submit the correct transaction type code for MOTO.

Second, compensate for the missing liability shift by layering your own fraud controls. Run AVS checks on every phone transaction. Validate the CVV — if a caller can't provide it, that's a warning sign. Use velocity checks to flag unusual patterns, like multiple high-value transactions from the same card in a short window. And consider using DTMF masking so customers enter card details on their phone keypad rather than reading them aloud. This doesn't just protect call recordings and reduce PCI scope — it also gives you a cleaner data feed with fewer transcription errors, which means fewer false declines.

Third, keep your phone payment data separate in your reporting. Because MOTO transactions don't have 3DS2 protection, you want to track chargeback rates for your phone channel independently. If chargebacks on phone payments are running higher than your online channel, that tells you where to focus your fraud prevention effort — rather than letting the numbers blur together across all channels.

Strong Customer Authentication exemptions worth knowing#

While 3DS2 and SCA are closely linked, they're not the same thing. SCA is the regulatory requirement under PSD2 — it says that electronic payments need two-factor authentication. 3DS2 is one way to satisfy that requirement for card payments. But not every transaction needs SCA, and understanding the exemptions matters for merchants who want to balance security with conversion rates.

MOTO transactions are exempt from SCA entirely, as we've covered. But there are several other exemptions that apply to online transactions where you might otherwise expect 3DS2 to be triggered.

Low-value transactions under thirty euros (or the local currency equivalent) can be exempt. The issuer tracks how many low-value transactions have been exempted since the last authentication — once they hit five consecutive exemptions or a cumulative total of one hundred euros, they'll require SCA again. This is useful for merchants selling low-cost items where authentication friction would kill conversion.

Trusted beneficiary listings let a cardholder tell their issuer that a particular merchant is trusted. Once you're on the list, future transactions with that customer can skip SCA. This works well for subscription businesses or merchants with high repeat-purchase rates, though adoption varies by issuer.

Transaction Risk Analysis (TRA) exemptions are available to acquirers and issuers who maintain fraud rates below certain thresholds. If your acquirer's fraud rate is under 0.13%, they can request a TRA exemption for transactions up to one hundred euros. Lower fraud rates unlock higher thresholds — below 0.06% allows exemptions up to two hundred and fifty euros, and below 0.01% pushes that to five hundred euros. This rewards merchants and acquirers who keep fraud tight.

Recurring payments only need SCA on the first transaction. After that, subsequent charges at the same amount to the same merchant can proceed without authentication. If the amount changes, SCA is required again for the new amount.

The practical takeaway for merchants: don't treat 3DS2 as an all-or-nothing switch. Work with your payment provider to apply exemptions where they make sense, and reserve full authentication for the transactions where it adds genuine security value. The goal is to authenticate when it matters and avoid friction when it doesn't — and understanding these exemptions gives you the tools to do that.

What matters to merchants#

Integration — to get the benefit of liability shift you need to implement 3DS2 correctly (merchant plug-in, SDK or gateway, correct flags passed to acquirer/issuer). If you just attempt and fail, you may not get protection.
Performance and UX — the idea is not to make every customer go through a painful authentication step (that increases abandonment). The richer data and risk-based "frictionless" path lets many lower-risk customers proceed with minimal steps.
Scope — 3DS2 is very relevant for card-not-present (online/app) transactions. It doesn't apply the same way for physical card-present sales. For those, other liability shift rules apply (EMV chip etc.).
Chargebacks vs non-fraud disputes — liability shift covers certain types of fraud-chargebacks (unauthorised transactions). It does not cover all dispute types (e.g., customer dissatisfaction with goods).

If you're a merchant selling online or via app, adopting 3DS2 is not just about ticking a compliance box. It's about strengthening authentication, improving your risk position, and potentially transferring the financial burden of fraud-chargebacks to the issuer when valid authentication has occurred.

The purchase use-cases it solves for include guest checkout online, mobile app purchases, higher-risk orders (that can trigger challenge flows), and cross-border transactions.

Implemented well, 3DS2 helps you convert more customers with less friction while controlling your fraud and liability exposure.

References and Further Reading#

Ready to Secure Your Payment Processing?

Paytia provides secure, PCI DSS compliant payment solutions that protect your business and customers. Learn how we can help you reduce compliance burden while improving security.