First-Time 3DS Setup (Playbook)

TL;DR

Week 1: Integrate 3DS2 (processor-provided is fastest), implement challenge flow
Week 1-2: Define triggers (first-time customer? High-value? EU?), configure risk thresholds
Testing: Frictionless success, challenge success, challenge failure, not enrolled, attempted
Go live: Start with 10-25% of traffic, target over 70% frictionless, under 2% conversion drop
Success: Fraud disputes showing liability shift, conversion stable

3D Secure shifts fraud liability to issuers when authentication succeeds. Done wrong, it kills conversion. Done right, you get protection with minimal friction. This playbook sets up 3DS2 for first-timers.

Timeline: 1-2 weeks. Integration complexity varies by provider.

Key Principle: 3DS Instead of Decline

If you're thinking about declining a transaction for fraud, use 3DS instead. You get liability shift if they pass, and lose nothing if they fail. See 3DS deep-dive for the full rationale.

3DS Only Protects Against Fraud Chargebacks

Liability shift covers fraud disputes (Visa 10.4, Mastercard 4837). Customers can still dispute for merchandise not received, not as described, or credit not processed. 3DS doesn't protect against bad fulfillment.

Workflow Overview

Phase	Key Tasks
Integrate	Choose provider, configure settings, implement challenge flow
Configure	Define triggers, set SCA exemptions, build risk rules
Test & Launch	Test all scenarios, rollout 10-25%, expand to 100%
Monitor	Track rates, tune rules, check fraud impact

Prerequisites: Processor with 3DS2 support, 3DS provider access, ability to modify checkout flow, test cards.

Trigger Criteria

Use this playbook when:

You're accepting CNP payments without 3DS
Fraud chargebacks are eating into margin
You sell to EU customers (SCA mandate)
You want liability shift for high-risk transactions

Prerequisites

Before starting, ensure you have:

Processor that supports 3DS2
3DS provider access (Stripe Radar, Adyen, Cardinal, etc.)
Ability to modify checkout flow
Test cards from your 3DS provider
Understanding of AVS & CVV basics
Familiarity with fraud prevention concepts

Understanding 3DS2

How 3DS2 Works

3DS2 vs 3DS1

Feature	3DS1 (Legacy)	3DS2 (Current)
User experience	Always redirect	Mostly frictionless
Data shared	Minimal	100+ data points
Mobile experience	Poor	Native SDKs
Approval rate	Lower	Higher

Key Outcomes

Result	What Happens	Liability
Frictionless success	No customer action	Shifts to issuer
Challenge success	Customer authenticates	Shifts to issuer
Challenge failed	Customer fails auth	Transaction declined
Not enrolled	Card doesn't support 3DS	Stays with merchant
Attempted	Issuer unavailable	Shifts to issuer

Week 1: Integration

Step 1: Choose 3DS Provider

Provider Type	Examples	Pros	Cons
Integrated with processor	Stripe Radar, Braintree	Easiest setup	Less control
Standalone	Cardinal, Netcetera	More control	More integration
Gateway-provided	Adyen, Checkout.com	Single vendor	Vendor lock-in

Recommendation: Start with processor-integrated 3DS. Add standalone later if you need more control.

Step 2: Configure 3DS Settings

If Using Stripe

const paymentIntent = await stripe.paymentIntents.create({
  amount: 1000,
  currency: 'usd',
  payment_method: 'pm_card_visa',
  confirmation_method: 'manual',
  confirm: true,
  // Enable 3DS when required
  payment_method_options: {
    card: {
      request_three_d_secure: 'automatic' // or 'any' to always request
    }
  }
});

If Using Adyen

const paymentRequest = {
  amount: { currency: 'USD', value: 1000 },
  paymentMethod: { type: 'scheme', number: '...', ... },
  // 3DS2 configuration
  authenticationData: {
    threeDSRequestData: {
      nativeThreeDS: 'preferred'
    }
  },
  // Pass browser/device data for frictionless
  browserInfo: {
    userAgent: '...',
    acceptHeader: '...',
    language: '...',
    // ... more fields
  }
};

Step 3: Implement Challenge Flow

When 3DS requires a challenge:

Receive challenge URL or data from 3DS response
Render challenge in iframe or redirect
Customer completes authentication
Receive completion callback
Continue with authorization

// Handle 3DS challenge (Stripe example)
if (paymentIntent.status === 'requires_action') {
  const { error } = await stripe.handleCardAction(
    paymentIntent.client_secret
  );

  if (error) {
    // Customer failed authentication
    showError('Authentication failed');
  } else {
    // Confirm the payment
    await confirmPayment(paymentIntent.id);
  }
}

Checkpoint: 3DS integrated; test transactions showing challenge when expected.

Week 1-2: Tuning

Step 1: Define When to Trigger 3DS

Don't 3DS everything. Target high-risk transactions:

Condition	3DS Recommendation
First-time customer	Yes (no history)
High-value order	Yes (over $X threshold)
High-risk country	Yes
Mismatched geo	Yes (IP vs billing)
Returning trusted customer	No (friction hurts)
Low-value order	No (fraud cost low)
EU customer	Required (SCA mandate)

Step 2: Configure Risk Thresholds

Example 3DS trigger rules:

IF order_amount > 500 THEN require_3ds
IF customer_type = 'new' AND order_amount > 100 THEN require_3ds
IF country IN (high_risk_list) THEN require_3ds
IF ip_country != billing_country THEN require_3ds
IF fraud_score > 70 THEN require_3ds

Step 3: SCA Exemption Strategy (EU Only)

SCA allows exemptions. Use them to reduce friction:

Exemption	When to Use
Low value	Under 30 EUR
Low risk (TRA)	Your fraud rate is low
Recurring	Subsequent subscription payments
Trusted beneficiary	Customer whitelisted you

Note: Issuers can override exemptions. Track exemption success rate.

Testing Checklist

Test Card Scenarios

Scenario	What to Test
Frictionless success	No challenge, auth succeeds
Challenge success	Challenge presented, customer completes, auth succeeds
Challenge failure	Challenge presented, customer fails, auth declined
Not enrolled	Card doesn't support 3DS, auth proceeds without
Issuer unavailable	Attempted result, auth may proceed

Integration Tests

3DS triggers on configured conditions
Challenge renders correctly (desktop)
Challenge renders correctly (mobile)
Callback handles success
Callback handles failure
Timeout handled gracefully
Fallback if 3DS unavailable

Checkpoint: All test scenarios passing.

Go Live and Monitor

Initial Rollout

Start with 10-25% of eligible traffic
Monitor for 1 week
Check key metrics before expanding

Metrics to Track

Metric	Target	Red Flag
Frictionless rate	Over 70%	Under 50%
Challenge success rate	Over 80%	Under 60%
Conversion impact	Under 2% drop	Over 5% drop
Liability shift rate	Over 90%	Under 70%

What Good Looks Like

3DS requested on 20-40% of transactions (risk-based)
70-85% frictionless (no customer action)
80%+ challenge success when challenged
Fraud chargebacks dropping
Conversion stable

Success Criteria

You're done when:

3DS integrated and processing live traffic
Risk-based triggers configured (not 3DS on everything)
Frictionless rate above 70%
Conversion impact under 2%
Fraud disputes showing liability shift

Scale Callout

Volume	Approach
Under $100k/mo	Use processor default 3DS; minimal tuning; focus on working integration
$100k-$1M/mo	Custom risk rules; A/B test thresholds; optimize frictionless rate
Over $1M/mo	Sophisticated risk model; exemption strategy; issuer-level analysis

Where This Breaks

3DS on every transaction. Kills conversion. Be selective.
No browser data passed. Frictionless rate tanks. Collect and pass device data.
Mobile challenge renders poorly. Test on actual devices; use native SDKs.
Ignoring exemptions (EU). Over-authenticating loyal customers. Implement TRA.
Not tracking liability shift. Can't prove ROI. Tag transactions with 3DS result.

SCA Requirements (EU)

If you sell to EU customers, SCA is required with exceptions:

Must Authenticate

First-time EU card transactions over 30 EUR
High-risk transactions (unless exempt)

Exemption Eligible

Under 30 EUR (low value)
Recurring after first payment
Your fraud rate qualifies for TRA
B2B payments (some cases)

Your Fraud Rate for TRA

Your Fraud Rate	Amount Threshold for Exemption
Under 0.13%	Up to 100 EUR
Under 0.06%	Up to 250 EUR
Under 0.01%	Up to 500 EUR

Next Steps

After 3DS is live and stable:

Tune thresholds: A/B test your risk triggers to optimize frictionless rate vs. fraud protection
Add exemptions (EU): Implement TRA exemptions if your fraud rate qualifies
Track liability shift: Verify fraud chargebacks are being deflected to issuers
Consider network tokens: Combine 3DS with network tokenization for additional auth lift

3D Secure - Deep-dive on 3DS mechanics
Auth Optimization - Improving approval rates
Fraud Prevention - Prevention strategies
Benchmarks - Industry 3DS benchmarks
Payments Experimentation - A/B testing 3DS triggers
AVS & CVV - Verification signals
Risk Scoring - Combining 3DS with scoring
Processor Rules Configuration - Setting up 3DS rules
Checkout Conversion - Measuring friction impact
Third-Party Fraud - What 3DS protects against
Chargeback Prevention - Liability shift benefits
Increase Auth Rates - Optimizing auth after 3DS

Workflow Overview​

Trigger Criteria​

Understanding 3DS2​

How 3DS2 Works​

3DS2 vs 3DS1​

Key Outcomes​

Week 1: Integration​

Step 1: Choose 3DS Provider​

Step 2: Configure 3DS Settings​

If Using Stripe​

If Using Adyen​

Step 3: Implement Challenge Flow​

Week 1-2: Tuning​

Step 1: Define When to Trigger 3DS​

Step 2: Configure Risk Thresholds​

Step 3: SCA Exemption Strategy (EU Only)​

Testing Checklist​

Test Card Scenarios​

Integration Tests​

Go Live and Monitor​

Initial Rollout​

Metrics to Track​

What Good Looks Like​

Success Criteria​

Scale Callout​

Where This Breaks​

SCA Requirements (EU)​

Must Authenticate​

Exemption Eligible​

Your Fraud Rate for TRA​

Next Steps​

Related​