3DS2 (3D Secure 2) is the current version of the security protocol that verifies your identity when you make an online card payment. It’s the technology behind those moments at checkout when your bank asks you to confirm a purchase through your banking app, a fingerprint scan, or a one-time code sent to your phone. The system works behind the scenes between the merchant, your card network, and your bank to decide whether a transaction needs extra verification or can be approved silently.
How 3DS2 Differs From the Original
The first version of 3D Secure, launched in the early 2000s, required every online card transaction to pass through a pop-up window where you’d enter a static password. It was clunky, frequently broke on mobile browsers, and drove shoppers away. Businesses saw checkout conversion drop by 3% to 15% with the original protocol, according to data from WorldPay. Many merchants simply chose not to use it.
3DS2 replaces that one-size-fits-all password screen with a risk-based approach. Over 150 data points can be shared between the merchant and your card-issuing bank, including your device type, shipping address, transaction history, and browser details. Your bank uses this information to assess whether the transaction looks legitimate. If it does, the purchase goes through without interrupting you at all. If something looks unusual, the bank triggers an additional verification step. The result is a much smoother checkout. With 3DS2, issuers target a maximum checkout dropoff of 5%, a significant improvement over the original.
Frictionless Flow vs. Challenge Flow
Every 3DS2 transaction follows one of two paths. In a “frictionless flow,” the data exchanged between the merchant and your bank is enough for the bank to approve the transaction confidently. You never see a verification screen. The authentication happens invisibly in about one to two seconds, and the payment proceeds as if 3DS2 wasn’t involved at all. This is the experience for the majority of low-risk transactions.
When the bank’s risk assessment flags something, the transaction enters a “challenge flow.” You’ll be asked to verify your identity through one of several methods: a one-time SMS code, a push notification to your banking app, biometric authentication like a fingerprint or face scan, or answering a security question. On mobile apps, this verification can happen natively within the app rather than redirecting you to a browser window, which was a major pain point with the original 3D Secure.
What the Liability Shift Means for You
One of the most important features of 3DS2 is the “liability shift.” When a merchant uses 3D Secure and the transaction is successfully authenticated, responsibility for fraudulent chargebacks shifts from the merchant to the card-issuing bank. This applies across major card networks including Visa, Mastercard, American Express, JCB, and UnionPay, among others.
This matters practically in two ways. If you’re a cardholder and someone makes a fraudulent purchase that passed 3DS2 authentication, your bank bears the cost of reversing it rather than the merchant. If you’re a merchant, implementing 3DS2 protects you from absorbing fraud losses on authenticated transactions. One important exception: the liability shift does not apply to recurring transactions, such as subscriptions that charge your card monthly after the initial signup.
Where 3DS2 Is Required
In some regions, 3DS2 isn’t optional. The European Union’s Revised Payment Services Directive (PSD2) requires banks to use Strong Customer Authentication (SCA) for online payments within the European Economic Area. SCA means the payment must be verified using at least two of three factors: something you know (a password or PIN), something you have (your phone), or something you are (a fingerprint or face scan). 3DS2 is the primary way card payments meet this requirement.
India requires authentication on all domestic e-commerce card transactions. Japan mandated that merchants apply 3DS2 to all online credit card payments starting April 2025. Australia requires merchants above certain fraud thresholds to implement 3DS2. Malaysia’s issuing banks may require authentication, and transactions without it tend to see lower approval rates. France has tightened its rules as well, with French issuers limiting certain authorization exemptions.
In the United States, 3DS2 is not legally mandated, but card networks encourage its use, and the liability shift gives merchants a strong financial incentive to adopt it. Even without a regulatory requirement, you’ll encounter 3DS2 verification on U.S. purchases increasingly often as banks and merchants adopt the protocol voluntarily.
What 3DS2 Looks Like on Your Phone
On mobile devices, 3DS2 was designed to feel native to the app you’re shopping in. Rather than opening a separate browser window (the old 3D Secure approach that frequently failed on smartphones), the verification screen appears within the app itself through an integrated SDK. If your bank supports biometric authentication, you might simply tap your fingerprint sensor or glance at your phone’s camera to approve the payment. Other challenge methods include a push notification to your banking app asking you to tap “approve,” or a six-digit code sent via text message.
The specific verification method depends on your bank, not the merchant. Some banks default to app-based push notifications, while others rely on SMS codes. If you’ve ever completed a purchase and your banking app popped up asking you to confirm, that was 3DS2 in action.
Exemptions That Skip Verification
Not every transaction triggers 3DS2 authentication, even in regions where it’s mandatory. Several built-in exemptions exist to keep low-risk purchases fast. Transactions below certain value thresholds can be exempt. Payments to merchants you’ve previously whitelisted as “trusted beneficiaries” with your bank may skip verification. Recurring payments for the same amount to the same merchant (like a streaming subscription) typically authenticate only on the first charge.
The merchant or their payment processor can also request an exemption by flagging a transaction as low risk based on their own fraud analysis. The issuing bank has the final say on whether to grant the exemption or require authentication anyway. When an exemption is granted and the transaction goes through without authentication, the liability shift generally does not apply, meaning the merchant retains fraud liability on that purchase.