3D Secure 2 for Merchants: When to Use It, How Liability Shift Works, and How to Keep Conversion High

3D Secure 2 (often written as 3DS2) is a card-network authentication step you can trigger during an online card payment to confirm the buyer is the legitimate cardholder. Done well, it reduces fraud and can shift certain fraud chargeback liability away from the merchant. Done poorly, it adds checkout friction and can lower conversion.

If you sell online, the practical goal is not to turn on 3DS for every order. The goal is to use 3DS in the situations where the risk, issuer behavior, or regulation demands it, and to route everything else through a low-friction path.

In this guide, I will explain what 3DS2 is, where it sits in the payment flow, how Strong Customer Authentication (SCA) fits in, what exemptions exist, and how to decide when to step up authentication without wrecking approvals.

What is 3D Secure 2, and what problem does it solve for merchants?

3D Secure 2 is an authentication protocol that lets your checkout pass transaction data to the issuer so the issuer can either approve the payment with "frictionless" authentication or require a customer challenge.

From a merchant perspective, 3DS2 helps with three common problems:

• Card-not-present fraud on first-time customers
• Issuer declines that happen because the issuer wants stronger signals
• Regulatory mandates (mainly in the EEA and UK) that require strong authentication on many customer-initiated transactions

EMVCo describes EMV 3DS as a way to help prevent card-not-present fraud and increase security for ecommerce payments by exchanging data between merchant and issuer to authenticate the consumer. Source: https://www.emvco.com/emv-technologies/3-d-secure/

Where does 3DS2 sit in the payment flow (and what changes when you enable it)?

At a high level, a card payment has two separate steps:

1) Authentication: "Is this buyer really the cardholder?"

2) Authorization: "Will the issuer approve this specific charge?"

3DS2 lives in the authentication layer, before authorization.

When you enable 3DS2, your checkout (or your gateway, PSP, or orchestration layer) can send an authentication request that includes context about the transaction, device, and customer. The issuer then chooses one of two paths:

• Frictionless flow: issuer authenticates the customer in the background and returns an authentication result without interrupting checkout.
• Challenge flow: issuer requires the customer to complete a step-up verification (bank app approval, one-time passcode, biometrics, etc.).

The result of the 3DS step is then attached to the authorization request.

Merchant takeaway: your main job is to maximize frictionless approvals while still meeting issuer and regulatory requirements.

What is Strong Customer Authentication (SCA), and how does it relate to 3DS2?

SCA is a regulatory requirement in Europe under PSD2. It typically requires two independent factors from the categories of knowledge, possession, and inherence.

In the RTS that supplements PSD2, SCA is defined as authentication based on two or more elements in those categories, and it must generate an authentication code. Source: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32018R0389

3DS2 is not the only possible method to achieve SCA, but in card payments it is the most common rails-based way merchants experience SCA because it coordinates issuer authentication during ecommerce checkout.

Practical translation:

• If you sell into the EEA and accept cards, 3DS2 is often how your PSP will satisfy SCA for customer-initiated ecommerce transactions.
• If you sell mainly in the US, 3DS2 is usually optional and risk-driven. But issuer behavior still matters, especially for cross-border, high-ticket, or high-risk categories.

What does "dynamic linking" mean, and why should merchants care?

Dynamic linking is the requirement that the authentication code is specific to both the amount and the payee, and that any change to either invalidates the code.

The PSD2 RTS explains the dynamic linking requirements in Article 5, including making the payer aware of the amount and payee and ensuring any change invalidates the authentication code. Source: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32018R0389

Merchants should care because:

• It impacts how checkout changes (amount edits, partial captures, shipping changes) interact with the authentication record.
• It is one reason why some issuers are stricter about re-using authentication results across multiple authorizations.

If you have complex post-checkout adjustments, talk to your gateway or PSP about how they handle amendments with 3DS data.

What is liability shift in 3D Secure, and when does it actually help?

"Liability shift" means that for certain fraud disputes (usually "unauthorized transaction" style chargebacks), the party responsible for the loss can shift from the merchant to the issuer when proper authentication is performed.

This is not a universal shield:

• You can still get chargebacks for non-fraud reasons (product not received, not as described, canceled recurring, etc.).
• A successful challenge is generally stronger than a frictionless approval for dispute defense, but the exact rules depend on the card brand, region, and how the transaction was authenticated.
• Some transactions are out of scope for certain regulatory requirements (for example, many merchant-initiated transactions), but that does not automatically guarantee liability shift.

Merchant takeaway: treat 3DS as one layer in a broader fraud and chargeback program.

If you want a deeper chargeback playbook, start with our guide to modern dispute rules and caps: https://merchantalternatives.com/credit-card-surcharging-rules-2026-visa-mastercard-caps-disclosure/

When should you turn on 3DS2 (and when should you avoid forcing it)?

A good 3DS strategy is conditional.

Use 3DS2 more aggressively when:

• Your fraud rate is climbing or you are in a high-risk vertical
• You have a lot of first-time buyers with high AOV
• Issuers are declining too many legitimate orders
• You sell into regions where SCA is commonly enforced
• You are seeing account testing or bot-driven carding

Avoid forcing 3DS2 on every transaction when:

• Your issuer approval rate is strong and fraud is already controlled
• Your business relies heavily on low-friction impulse conversion
• Your customer base includes issuers that treat 3DS requests as suspicious in some markets

A practical compromise is to start with step-up rules that trigger 3DS2 only on defined risk segments, then expand as you measure results.

What SCA exemptions matter most for ecommerce merchants?

If you sell into PSD2 markets, exemptions are your main lever to reduce challenge volume.

Here are the exemptions that matter most for remote card payments.

Low-value exemption (remote ecommerce under EUR 30)

Under Article 16 of the PSD2 RTS, PSPs can skip SCA on a remote electronic payment transaction when the amount does not exceed EUR 30 and the cumulative amount since the last SCA does not exceed EUR 100, or the number of previous remote transactions since the last SCA does not exceed 5. Source: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32018R0389

This is not "always exempt". There are counters.

The EBA has clarified that the payer's PSP (issuer) makes the ultimate decision on whether to accept or apply an exemption, even if other PSPs can apply it. Source: https://www.eba.europa.eu/single-rule-book-qa/qna/view/publicId/2018_4242

Transaction Risk Analysis (TRA) exemption

Under Article 18 of the PSD2 RTS, PSPs can skip SCA for a remote electronic payment transaction identified as low risk based on transaction monitoring mechanisms, subject to fraud-rate thresholds and exemption threshold values in the annex. Source: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32018R0389

In plain English: if your PSP has low enough fraud levels and can run real-time risk scoring, more transactions can go through without a challenge.

Stripe explains that payment providers can request exemptions and the issuer ultimately decides whether to approve the exemption or require authentication. Stripe also lists TRA fraud-rate thresholds (0.13% for amounts below EUR 100, 0.06% below EUR 250, 0.01% below EUR 500). Source: https://stripe.com/guides/strong-customer-authentication

Trusted beneficiaries

Under Article 13 of the PSD2 RTS, SCA is applied when a customer creates or amends a list of trusted beneficiaries, and then PSPs can skip SCA for payments to payees on that list. Source: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32018R0389

Trusted beneficiary flows are issuer-led. As a merchant, you mainly benefit when issuers support it well, and when you keep a consistent merchant identity so the issuer can recognize you.

Recurring transactions with the same amount and payee

Under Article 14 of the PSD2 RTS, PSPs apply SCA when a payer creates, amends, or initiates for the first time a series of recurring transactions with the same amount and payee, and then PSPs can skip SCA for subsequent transactions in that series. Source: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32018R0389

Important nuance for subscriptions: if you bill variable amounts or change the payee descriptor, you may lose the recurring exemption behavior in practice.

For a related concept, read our merchant guide to account updater services (which can reduce subscription churn when cards reissue): https://merchantalternatives.com/account-updater-vau-abu-amex-cardrefresher-merchant-guide/

What does "frictionless" vs "challenge" mean in practice (and what controls it)?

Your checkout does not decide whether the transaction is challenged. The issuer does.

What you can control is the quality of data you pass and the policy you use for when to request 3DS.

In general, issuers are more likely to approve frictionless authentication when:

• The transaction data is complete and consistent
• The device and IP signals look normal
• The customer has a good history
• The amount and merchant category fit expected patterns

Issuers are more likely to require a challenge when:

• The purchase is high-risk or out-of-pattern
• The issuer has limited data on the shopper
• The issuer's model flags the transaction as suspicious
• The issuer declines exemptions

Merchant takeaway: your job is to improve issuer confidence through better data and stable identifiers.

What merchant data helps issuers approve frictionless 3DS2 authentications?

This is the overlooked part of 3DS2. More data can mean fewer challenges.

Depending on your gateway and PSP, you can often pass:

• Customer email, phone, and shipping address
• Account age and prior purchase count
• Whether the customer is logged in
• Delivery time frame (digital vs physical)
• Device signals, including user agent and IP-derived info

EMVCo notes that EMV 3DS enables the exchange of data between the merchant and issuer, including information about the transaction, payment method, and device. Source: https://www.emvco.com/emv-technologies/3-d-secure/

Practical checklist:

• Make sure AVS and postal code data is sent for card payments
• Keep billing and shipping addresses consistent in your UI and data model
• Use a consistent descriptor and domain name
• Avoid unnecessary cart changes between authentication and authorization

How should merchants handle subscriptions, free trials, and merchant-initiated transactions?

Subscription businesses typically face three separate payment moments:

1) The initial card-on-file setup (or first paid invoice)

2) Subsequent recurring charges

3) Off-cycle changes (upgrades, add-ons, usage, proration)

In PSD2 contexts, the first payment in a fixed-amount recurring series is where SCA most commonly appears. Article 14 of the RTS is the baseline concept. Source: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32018R0389

For US merchants, the focus is usually risk and disputes, not SCA.

If you bill variable amounts, treat those charges as higher risk from an authentication perspective. Some issuers will behave as if they are not covered by a recurring exemption, even if your PSP labels them as recurring.

Also, keep your MIT flags straight in your gateway. Mislabeling can cause higher decline rates, poor dispute outcomes, or compliance issues.

If you run a marketplace or platform model, you also need to think about KYC and payment facilitator obligations because those affect risk scoring and monitoring. See: https://merchantalternatives.com/marketplace-payment-processing-payfac-kyc-kyb-compliance-2026/

What are the most common 3DS2 implementation mistakes?

Here are the issues I see most often when merchants roll out 3DS2.

1) Turning on 3DS for every transaction with no measurement plan

2) Not passing enough customer and device data

3) Treating a challenge as a failure and not offering a recovery path

4) Assuming 3DS prevents all chargebacks

5) Mixing up recurring vs one-time flags for subscriptions

6) Ignoring the issuer decisioning layer and blaming the gateway

The easiest way to avoid these is to treat 3DS rollout like an A/B test.

How do you measure whether 3DS2 is helping or hurting?

Track these metrics before and after rollout:

• Authorization rate (overall and by issuer country)
• Fraud rate (by order count and by dollars)
• Challenge rate (what share of attempted authentications are challenged)
• Challenge completion rate
• Post-auth decline rate (issuer approves authentication but declines authorization)
• Chargeback rate (fraud and non-fraud reason codes separately)

If you only look at fraud, you may miss the conversion cost.

What does a practical 3DS2 decision policy look like?

Below is a simple starting point. It is not perfect, but it is better than "always on".

If you are seeing chargeback pressure, also review your dispute processes. Some chargeback programs can escalate costs quickly if you are labeled excessive. (Related reading: https://merchantalternatives.com/mastercard-excessive-chargeback-program-ecm-hecm-guide/)

FAQ

Does 3DS2 guarantee chargeback protection?

No. 3DS2 can help with certain fraud disputes and can shift liability in some cases, but you can still lose chargebacks for non-fraud reasons and for situations where authentication was not successful or not eligible for a shift.

Will 3DS2 lower my conversion rate?

It depends. If most authentications are frictionless, the conversion impact can be small. If a large share of transactions are challenged, you will usually see more drop-off.

Who decides whether an exemption applies under SCA?

Even when an exemption is requested by a PSP, the issuer (payer's PSP) makes the ultimate decision on whether to accept or apply the exemption. Source: https://www.eba.europa.eu/single-rule-book-qa/qna/view/publicId/2018_4242

What are the key PSD2 low-value exemption thresholds?

Under Article 16, the remote transaction amount must be under EUR 30 and the cumulative amount since last SCA must be under EUR 100 or the number of previous remote transactions since last SCA must be 5 or fewer. Source: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32018R0389

Can my PSP request SCA exemptions for me?

Yes in many cases. Stripe notes that payment providers can request exemptions and the issuer ultimately decides whether to approve the exemption or require authentication. Source: https://stripe.com/guides/strong-customer-authentication

Closing: recommended next step

You can apply for a merchant account through Easy Pay Direct or another processor that fits your model. Other options worth a look:

• https://merchantalternatives.com/go/easy-pay-direct/
• https://merchantalternatives.com/go/soar-payments/
• https://merchantalternatives.com/go/paymentcloud/