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 is 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. 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. 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, 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 (or 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 [merchant-initiated transactions] or recurring payments differently for liability shift). 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 & UX: The idea is not to make every customer go
