Enable 3D Secure on Stripe
The single biggest evidence lever for fraud chargebacks. Setup is two Radar Rules in your Stripe Dashboard, takes about two minutes, and shifts fraud dispute liability to the card issuer when authentication succeeds.
Why this matters
Per Visa Core Rules Section 11.4, when a cardholder successfully completes 3D Secure authentication, liability for fraud chargebacks shifts from the merchant to the card issuer. The cardholder verified their identity through their bank's authentication system; if they later claim the transaction was unauthorized, the bank — not the merchant — absorbs the loss.
Modeled win-rate impact for fraud disputes (Visa 10.4): ~22% baseline (no 3DS) → ~75% with 3DS. That's the largest single lift in the win-rate breakdown by a wide margin. Other dispute types see smaller lifts.
Setup: two Radar Rules
Open Radar Rules
In your Stripe Dashboard, navigate to Settings → Radar → Rules. You'll see a list of existing rules grouped by action (Block, Review, Request 3D Secure, Allow). The "Request 3D Secure" section is where the rules below go.
Add the elevated-risk rule
Click Add rule under the "Request 3D Secure" section. Use this rule:
This requests 3DS only on charges Stripe Radar already flagged as elevated risk — typically 1-3% of traffic depending on your customer mix. Low friction, high evidence value.
Add the international-card rule (recommended)
International cards have higher fraud rates and the cardholder's issuer is more likely to support 3D Secure. Add a second rule:
This catches the most common cross-border fraud pattern (card issued in one country, transaction from another) and requests authentication on it.
Save and verify
Click Save on each rule. Stripe applies them immediately to all new payment intents. Existing pending disputes are unaffected (3DS is set at charge time).
To verify the rules are active, run a small test charge with a card Stripe knows is in an elevated-risk profile (Stripe's test card 4000000000003220 triggers 3DS authentication in test mode).
Stronger rules (higher friction trade-off)
The two rules above are the "low friction, high evidence value" setup. If your dispute pipeline is bad enough that you'd rather lose some conversion than absorb chargebacks, these are stricter:
Always request 3DS on first-time customers
Triggers 3DS on every new card. Highest authentication coverage, highest checkout friction. Worth it if you have a high-AOV product and disputes are bleeding margin.
Always request 3DS on amounts over $X
Conservative middle ground. Authentication friction only on charges large enough to matter; small charges flow through without it. Adjust the threshold to your AOV.
Always request 3DS on subscription renewals
Applies to off-session (saved-card / recurring) charges where the cardholder isn't actively at checkout. Subscription chargebacks benefit most from this since the customer can claim "I forgot to cancel" and the merchant has no real-time auth proof.
Common mistakes
Confusing "Request" with "Require"
Stripe's "Request 3D Secure" rules ask the issuer to authenticate but allow the charge through if the issuer doesn't support 3DS. There's no "Require" equivalent in Radar Rules — for hard-require behavior you'd set payment_intent_data.payment_method_options.card.request_three_d_secure to any in your checkout code. The Radar Rules approach is what most merchants want.
Setting rules in test mode and forgetting to enable in live
Stripe Radar Rules are mode-specific. Rules added in test mode don't apply to live charges. Toggle to live mode in your Stripe Dashboard before adding rules, or add them in both.
Expecting immediate dispute-rate change
3DS rules apply to new charges going forward. Disputes filed today are on charges from 30-90 days ago — those won't benefit. The dispute rate change shows up 30-90 days after the rule is enabled, as new charges age into dispute eligibility.
Disabling rules after one chargeback win
3DS adds checkout friction, and merchants sometimes panic-disable rules after one customer complains. The rules are doing their job — the conversion-loss-per-prevented-fraud math almost always favors keeping them on. Watch the chargeback rate over a 90-day window before changing.
What 3D Secure doesn't fix
3DS shifts liability on fraud disputes specifically (Visa 10.4 and Mastercard equivalent). It does not help with product-not-received disputes, duplicate-charge disputes, subscription-canceled disputes, or product-quality disputes — those need different evidence (delivery tracking, transaction records, cancellation policy, service completion). For non-fraud disputes, Evidence Vault and the Reflex evidence package are the levers; 3DS itself does little.
After you've enabled 3DS
Reflex automatically detects 3DS authentication on each charge and includes the result in dispute responses. No further setup needed inside Reflex.