# Asking the Bank to Verify the Shopper (3D Secure / 3DS)
Source: https://paymentsandrisk.com/docs/fraud/prevention/3ds

Last updated 24 October 2026.

TL;DR

-   **3DS** = Authentication that shifts fraud liability from you to issuer on CNP transactions
-   **Worth testing if**: Fraud losses are rising or you're approaching your processor's written limit. Measure [authorization](https://paymentsandrisk.com/docs/payments/reference/authorization-basics/) and abandonment too
-   **Liability shift**: Visa ECI 05/06 = full shift; Mastercard SLI 2 (fully authenticated) / SLI 1 (attempted) = full shift; ECI 07 or no auth = you're liable
-   **Frictionless rate**: Send supported customer and device data, then measure issuer decisions on your own traffic
-   Roll out in phases: high-risk segments first, measure for 2 weeks, expand or kill

Where to go next

-   [Just tell me how to switch it on without wrecking my checkout](https://paymentsandrisk.com/docs/playbooks/first-time-3ds-setup/)
-   [The extra checkout step is costing me sales - what else is there?](https://paymentsandrisk.com/docs/fraud/prevention/avs-cvv/)
-   [My disputes aren't fraud claims, so will this even help?](https://paymentsandrisk.com/docs/chargebacks/prevention/)

3D Secure (3DS) is the step where the customer's bank checks that the real cardholder is the one buying. Sometimes the shopper sees it: a code by text, a tap in the banking app. Often the bank recognizes the customer from the data you sent and approves without showing anything at all. When the bank authenticates the payment, it takes on the fraud risk for it instead of you. That handover is called the liability shift, and it's the main reason merchants turn 3DS on.

The Golden Rule: 3DS Instead of Decline

**If you're thinking about declining a transaction for fraud, use 3DS instead.**

When your fraud rules flag a transaction as risky, you have two options:

1.  **Decline it** - You lose the sale. If it was a good customer, they're gone.
2.  **Trigger 3DS** - The issuer authenticates them. If they pass, you get liability shift AND the sale. If they fail or abandon, you've lost nothing you wouldn't have lost anyway.

3DS is not just a fraud prevention tool. It's a recovery mechanism for transactions your rules would otherwise kill.

3DS Does NOT Prevent All Chargebacks

Liability shift only covers **fraud chargebacks** (Visa 10.4, Mastercard 4837).

Customers can still dispute for:

-   **Merchandise not received** - Package lost or never shipped
-   **Not as described** - Product doesn't match what you sold
-   **Services not rendered** - You didn't deliver what was promised
-   **Credit not processed** - You owe them a refund and didn't give it
-   **Processing errors** - Duplicate charges, wrong amounts

A fully authenticated transaction that results in an unhappy customer is still a chargeback waiting to happen. 3DS protects you from "I didn't do it" fraud. It doesn't protect you from bad fulfillment, misleading product descriptions, or poor customer service.

Do I Need 3DS?

**No new rollout needed** - if your current controls are meeting your fraud-loss budget and applicable requirements. Check your processor's limits and [network program conditions](https://paymentsandrisk.com/docs/chargebacks/reference/network-programs/). Keep monitoring.

**Test first** - if fraud losses are rising or you see repeat disputers on high-value orders. Test 3DS on your riskiest segment first and measure the impact for 2 weeks.

**Act now** - if fraud chargebacks are driving a processor warning or you're approaching an applicable limit. Confirm whether 3DS and liability shift address the disputes you're receiving.

**Simple starting rule:** Test 3DS on new-customer orders above an amount you choose from your own fraud losses. The $200 population below is illustrative. Set an auth-rate stop limit from lost margin before launch, and judge fraud only after the outcome window closes ([before any live test](https://paymentsandrisk.com/docs/reference/experimentation/#before-a-live-test)). Required authentication still applies.

3DS shifts liability to the [issuer](https://paymentsandrisk.com/docs/fraud/issuer-perspective/) for authenticated [CNP](https://paymentsandrisk.com/docs/payments/payment-methods/cards/) transactions. But it also adds friction that kills [conversion](https://paymentsandrisk.com/docs/payments/checkout-conversion/) for some merchants.

Before you flip the switch everywhere, run an experiment.

Experiment to Run

**Illustrative population:** Orders over $200 from customers with fewer than 2 prior purchases. Replace those cutoffs with your own high-loss segment before testing.

**Control:** Same segment, no 3DS challenge

**Metrics:** Auth rate, cart abandonment, fraud rate, CB ratio (reason code 10.4)

**Guardrail:** Choose the largest auth-rate drop vs. control that your lost-margin budget can absorb. State it in percentage points and name who pauses the test.

**Run length:** Plan the sample from your baseline and the change worth detecting. Keep fraud results inconclusive until the outcome window closes.

**Kill criteria:** Pause at that same auth-rate limit or the dollar-loss cap, whichever comes first. Use the agreed rollback; don't turn off authentication your processor or applicable rules require.

**Before it starts:** Name who owns the risk and the most it can cost. Two weeks shows the auth rate, not the 10.4 chargebacks, so read the CB ratio after the outcome window closes ([the full checklist](https://paymentsandrisk.com/docs/reference/experimentation/#before-a-live-test))

This is a Bet

If you turn 3DS on for a segment, you're testing whether fraud liability shift is worth any added checkout friction. Measure completed payments against comparable traffic. An auth-rate drop isn't a fixed cost you can assume.

That's worth it if:

-   Your [fraud losses](https://paymentsandrisk.com/docs/fraud/metrics/) are above the budget you've set
-   You're approaching your processor's limit or an applicable [network program line](https://paymentsandrisk.com/docs/chargebacks/reference/network-programs/)
-   Your margins can absorb the conversion hit

It's probably NOT worth it if:

-   Your current controls are meeting your fraud-loss budget and applicable requirements
-   Your margins are thin (see [interchange optimization](https://paymentsandrisk.com/docs/payments/interchange-optimization/))
-   Your customer base is older/less tech-savvy (higher challenge abandonment)

Write down your assumptions before you start. Revisit them in 30 days.

* * *

## 3DS Topics

[🎫 3DS Exemptions When to skip authentication: TRA, low-value, recurring, corporate](https://paymentsandrisk.com/docs/fraud/prevention/3ds/exemptions)

[📋 First-Time 3DS Setup Step-by-step implementation playbook](https://paymentsandrisk.com/docs/playbooks/first-time-3ds-setup)

* * *

## How 3DS Works

| Version | Status | Key Features |
| --- | --- | --- |
| 3DS 1.0 | Deprecated | Static passwords, high friction |
| 3DS 2.0 | Current | Risk-based, frictionless options |
| 3DS 2.1 | Current | Enhanced data, mobile support |
| 3DS 2.2 | Current | SCA compliance, exemptions |

### Brand Names

| Network | 3DS Brand Name |
| --- | --- |
| Visa | Visa Secure |
| Mastercard | Mastercard Identity Check |
| American Express | American Express SafeKey |
| Discover | ProtectBuy |

* * *

## Liability Shift Rules

This is the whole point. When 3DS authentication succeeds, fraud liability shifts from you to the issuer.

### Visa (ECI Values)

| ECI | Meaning | Liability Shift |
| --- | --- | --- |
| 05 | Fully authenticated | Yes, to issuer |
| 06 | Attempted, issuer not enrolled/unavailable | Yes, to issuer (merchant attempted, issuer didn't participate) |
| 07 | Not authenticated / Failed | No, merchant liable |

### Mastercard (SLI Values)

| SLI | Meaning | Liability |
| --- | --- | --- |
| 2 | Fully authenticated | Issuer |
| 1 | Authentication attempted (merchant supports UCAF) | Issuer |
| Other | Not authenticated | Merchant |

### When Liability Does NOT Shift

Even with authentication:

-   Mail order/telephone order (MOTO)
-   [Recurring transactions](https://paymentsandrisk.com/docs/payments/subscriptions-recurring/) (after initial)
-   Merchant-initiated transactions (MIT) - see [recurring billing compliance](https://paymentsandrisk.com/docs/compliance/subscriptions/recurring-billing/)
-   Certain [MCC](https://paymentsandrisk.com/docs/reference/mcc-codes/) exclusions

* * *

## Frictionless vs. Challenge Flow

### Frictionless Authentication

The issuer's risk engine decides the cardholder is low-risk and authenticates without interaction.

**Benefits:**

-   Better conversion (no extra steps)
-   Faster checkout
-   Still provides liability shift

### Challenge Flow

Cardholder must complete verification (OTP, biometric, etc.).

**When triggered:**

-   High-risk transaction signals
-   Issuer policy
-   Cardholder behavior anomalies
-   Amount thresholds

### Impact on Frictionless Rate

More supported data can help the issuer assess risk, but doesn't promise a frictionless percentage.

| Data Quality | What to check |
| --- | --- |
| Minimal data | Which supported fields are missing? |
| Good data | Do fields match the order and customer? |
| Excellent data | Does your issuer mix actually produce more frictionless completions? |

Send the supported data your integration permits and your privacy obligations allow: shipping address, email, phone, device info, customer history and IP address.

* * *

## Rollout Strategy

Don't turn it on everywhere at once.

### Phase 1: High-Risk Only (Week 1-2)

Start with segments where [fraud](https://paymentsandrisk.com/docs/fraud/types/) is concentrated:

-   High-risk BINs (prepaid, certain countries) - see [going global](https://paymentsandrisk.com/docs/payments/going-global/)
-   New customers with no history
-   Orders over your average fraud amount

Measure: [CB rate](https://paymentsandrisk.com/docs/chargebacks/metrics/) change, [auth rate](https://paymentsandrisk.com/docs/payments/auth-optimization/) change, cart abandonment.

### Phase 2: Expand or Kill (Week 3-4)

If Phase 1 shows improvement:

-   Expand to medium-risk segments
-   Keep monitoring auth rate closely

If Phase 1 shows no fraud improvement and auth dropped:

-   Kill it
-   Try a different segment or approach

### Phase 3: Steady State

Once you find segments where 3DS works:

-   Lock in those rules
-   Monitor monthly for drift
-   Re-test quarterly as issuer behavior changes

Where Experiments Lie to You

-   **Small samples:** 500 transactions isn't enough to measure fraud rate changes. You need thousands.
-   **Seasonality:** Fraud patterns shift. A rule that works in December may fail in March.
-   **Issuer behavior changes:** Frictionless rates depend on issuer risk engines, which update constantly.
-   **Selection bias:** If you only enable 3DS on high-risk orders, of course it will look effective. Compare to a control.

* * *

## Chargeback Handling for 3DS

When you get a fraud [chargeback](https://paymentsandrisk.com/docs/chargebacks/lifecycle/) on an authenticated transaction, include the authentication data in your [representment](https://paymentsandrisk.com/docs/chargebacks/representment/) response.

**Mastercard (4837):**

```text
AUTH MMDDYY/NNNNNN SL 1
```

**Visa (10.4):** Include ECI value, CAVV, and 3DS transaction ID.

### When 3DS Doesn't Protect

Even with authentication, [chargebacks](https://paymentsandrisk.com/docs/chargebacks/) can occur for:

-   Non-fraud [reason codes](https://paymentsandrisk.com/docs/reference/reason-codes/) (13.x)
-   Services not rendered (see [13.3](https://paymentsandrisk.com/docs/reference/reason-codes/visa/13-3-not-as-described/))
-   Goods not received (see [13.1](https://paymentsandrisk.com/docs/reference/reason-codes/visa/13-1-not-received/))
-   Processing errors
-   Authentication data errors

* * *

## Metrics to Watch

Track these during your experiment:

| Metric | What It Tells You |
| --- | --- |
| Frictionless rate | How often issuers are letting transactions through without challenge |
| Challenge completion rate | How many customers complete the challenge vs. abandon |
| Auth rate by ECI | Are you getting liability shift or just friction? |
| Cart abandonment | Measure at checkout step, not just overall |
| CB ratio on 10.4/4837 | The fraud chargebacks you're trying to prevent |

* * *

## The Bet Framing

Sometimes the "right" decision loses a specific fight, but you keep it because expected value is positive over many fights.

3DS will occasionally let through a fraudster who passes the challenge. It will also occasionally cause a good customer to abandon. That's fine. The question is whether, across thousands of transactions, you're better off with it than without it.

If you're not measuring, you're not betting. You're just guessing.

## Do next

-   [Velocity Rules](https://paymentsandrisk.com/docs/fraud/detection/velocity-rules/) - Catch what 3DS misses
-   [What proof each network accepts](https://paymentsandrisk.com/docs/chargebacks/representment/compelling-evidence/) - Win with authentication data
-   [Risk Scoring](https://paymentsandrisk.com/docs/fraud/prevention/risk-scoring/) - Combine with scoring for precision

## Look up

-   [Visa 10.4 - CNP Fraud](https://paymentsandrisk.com/docs/reference/reason-codes/visa/10-4-fraud-cnp/) - Reason code details
-   [Mastercard 4837 - Fraud](https://paymentsandrisk.com/docs/reference/reason-codes/mastercard/fraud/) - Mastercard specifics

## Deeper

-   [3DS Exemptions](https://paymentsandrisk.com/docs/fraud/prevention/3ds/exemptions/) - When to skip authentication
-   [PSD2 & SCA](https://paymentsandrisk.com/docs/compliance/psd2-sca/) - European authentication requirements for US merchants

**If 3DS is killing conversion:**

-   [Device Fingerprinting](https://paymentsandrisk.com/docs/fraud/detection/device-fingerprinting/) - Passive signals
-   [Rules vs ML](https://paymentsandrisk.com/docs/fraud/detection/rules-vs-ml/) - Other approaches