Skip to main content

3D Secure Authentication

Prerequisites

Before implementing 3DS, ensure you understand:

TL;DR
  • 3DS = Authentication that shifts fraud liability from you to issuer on CNP transactions
  • Worth it if: Fraud over 0.5%, approaching Visa thresholds, margins can absorb 2-5% auth drop
  • Liability shift: Visa ECI 05 = full shift; Mastercard SLI 1 = full shift; anything else = you're liable
  • Frictionless rate: More data sent = 60-90% frictionless (no challenge); send everything you have
  • Roll out in phases: high-risk segments first, measure for 2 weeks, expand or kill
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.

3DS shifts liability to the issuer for authenticated CNP transactions. But it also adds friction that kills conversion for some merchants.

Before you flip the switch everywhere, run an experiment.

Experiment to Run

Population: Orders over $200 from customers with fewer than 2 prior purchases

Control: Same segment, no 3DS challenge

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

Guardrail: Auth rate can't drop more than 3%

Run length: 2 weeks or 1,000 transactions per variant

Kill criteria: If auth rate drops more than 5% in first 3 days with no fraud improvement, turn it off

This is a Bet

If you turn 3DS on for a segment, you're trading an expected auth rate drop (typically 2-5%) for liability shift on fraud chargebacks.

That's worth it if:

It's probably NOT worth it if:

  • Your fraud rate is already low (under 0.3%)
  • Your margins are thin (see 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.

How 3DS Works​

VersionStatusKey Features
3DS 1.0DeprecatedStatic passwords, high friction
3DS 2.0CurrentRisk-based, frictionless options
3DS 2.1CurrentEnhanced data, mobile support
3DS 2.2CurrentSCA compliance, exemptions

Brand Names​

Network3DS Brand Name
VisaVisa Secure
MastercardMastercard Identity Check
American ExpressAmerican Express SafeKey
DiscoverProtectBuy

Liability Shift Rules​

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

Visa (ECI Values)​

ECIMeaningLiability Shift
05Fully authenticated✅ Yes, to issuer
06Attempted, issuer not available⚠️ Partial
07Not authenticated / Failed❌ No, merchant liable

Mastercard (SLI Values)​

SLIMeaningLiability
1Fully authenticated (first-party)Issuer
2Delegated authenticationIssuer
OtherNot authenticatedMerchant

When Liability Does NOT Shift​

Even with authentication:

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 data = higher frictionless rate:

Data QualityTypical Frictionless Rate
Minimal data30-50%
Good data60-75%
Excellent data80-90%+

Send everything you have: shipping address, email, phone, device info, customer history, 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 is concentrated:

  • High-risk BINs (prepaid, certain countries) - see going global
  • New customers with no history
  • Orders over your average fraud amount

Measure: CB rate change, auth rate 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.

3DS Exemptions: When to Skip Authentication​

Even when SCA is required (Europe) or you want liability shift, certain transactions can skip 3DS. Understanding exemptions is critical for optimizing conversion while maintaining compliance.

Exemption Types​

ExemptionCriteriaWho Decides
Low valueUnder €30 (€100 cumulative limit)Issuer
Low risk (TRA)Based on fraud rate thresholdsAcquirer or Issuer
Recurring/MITAfter initial authenticated transactionMerchant initiates (see subscriptions)
Corporate cardsSecure corporate payment processIssuer (see B2B)
Trusted beneficiaryCardholder whitelisted merchantCardholder/Issuer
Secure corporateDedicated payment processesVaries

Transaction Risk Analysis (TRA) Thresholds​

TRA exemptions are based on your fraud rate. Lower fraud rate = higher exemption threshold.

Your Fraud RateExemption Threshold
Below 0.13%Up to €100
Below 0.06%Up to €250
Below 0.01%Up to €500

Reality check: Most merchants can't claim TRA exemptions because they don't have the verified fraud rate data or the acquirer support.

Exemption Decision Flow​

Exemption Risks​

RiskDescription
Issuer declineIssuer can reject exemption request
Liability stays with youExempted transactions = no liability shift
Ratio impactFraud on exempted transactions counts against you
Cumulative trackingLow-value exemptions have limits

When to Request Exemptions​

Request ExemptionDon't Request
Repeat customers with historyFirst-time high-risk orders
Low-value transactionsHigh-value orders
Low-risk profileAny fraud signals present
Conversion-critical flowWhen liability shift matters

Implementation Notes​

Ask Your Processor

"Do you support 3DS exemption requests? Which exemption types can we request? How do we flag transactions for TRA?"

Not all processors support all exemptions. Verify:

  1. Which exemptions your processor can request
  2. How to flag transactions for exemption
  3. What data is required for TRA
  4. How declined exemptions are handled (fallback to full 3DS?)

Exemption Strategy by Business Type​

Business TypeRecommended Approach
SubscriptionsAuthenticate first payment, MIT exemption for renewals
High-frequency, low-valueRequest low-value exemption, accept liability
High-value goodsFull authentication, don't exempt
Return customersTrusted beneficiary (if supported)
MixedSegment by risk, exempt low-risk only

Chargeback Handling for 3DS​

When you get a fraud chargeback on an authenticated transaction, include the authentication data in your representment response.

Mastercard (4837):

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 can occur for:

  • Non-fraud reason codes (13.x)
  • Services not rendered (see 13.3)
  • Goods not received (see 13.1)
  • Processing errors
  • Authentication data errors

Metrics to Watch​

Track these during your experiment:

MetricWhat It Tells You
Frictionless rateHow often issuers are letting transactions through without challenge
Challenge completion rateHow many customers complete the challenge vs. abandon
Auth rate by ECIAre you getting liability shift or just friction?
Cart abandonmentMeasure at checkout step, not just overall
CB ratio on 10.4/4837The 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.

Next Steps​

If 3DS is working for you:

  1. Risk Scoring - Combine with scoring for precision
  2. Velocity Rules - Catch what 3DS misses
  3. Fraud Metrics - Track your improvement

If 3DS is killing conversion:

  1. AVS & CVV - Lower-friction alternatives
  2. Device Fingerprinting - Passive signals
  3. Rules vs ML - Other approaches

Fighting 3DS chargebacks:

  1. Visa 10.4 - CNP Fraud - Reason code details
  2. Mastercard 4837 - Fraud - Mastercard specifics
  3. Compelling Evidence Guide - Win with authentication data

See Also​