Stripe Radar and 3DS: What a Request Does
You can ask Radar to trigger 3-D Secure on a risky payment. The issuer still decides what the customer sees.
You sell something to a new card. The payment feels off. You want the bank to make the buyer prove who they are. Stripe Radar can ask for that, but the ask is not an order.
What requesting 3DS actually does
A Radar rule can tell Stripe to request 3-D Secure on a payment. Requesting it does not mean it happens. Stripe's documentation says requesting 3DS does not necessarily mean the issuer actually performs 3DS. The issuer determines the final authentication flow.
The customer is only prompted to authenticate if 3DS is available for the card. If it is not, the payment proceeds normally. So you can ask, and nothing changes for the buyer.
Stripe can't guarantee your 3DS preference. You also cannot use Stripe APIs to manually turn 3DS off. The setting is not a switch you own.
When 3DS happens without you asking
Some payments get 3-D Secure no matter what you do. Stripe's documentation says 3DS activates automatically when required by a regulatory mandate such as Strong Customer Authentication.
Stripe also runs its own mandatory authentication rules. They work automatically, whether or not you manually request 3DS. Your rule sits on top of that, not instead of it.
For the wider picture on how the challenge works, read our 3d secure guide.
Writing a Request 3DS rule in Radar
A rule uses the syntax {action} if {attribute} {operator} {value}. To request authentication, the action is Request 3DS. You pick the attribute, then the operator, then the value.
You do not have to write it by hand. The rule editor has a built-in assistant that constructs a Radar transaction rule from a natural language prompt. Describe what you want in plain words and it builds the rule.
One example from Stripe's own guide: a rule can request 3DS on all cards that have not been used on your account. That targets the payments you know least about.
Where the rules apply matters. Request 3DS rules work only with Stripe Checkout, Payment Intents, or Setup Intents. If you take payments another way, the rule will not fire.
By default, rules apply to all supported payment methods unless you define a specific payment method in the rule. Keep that in mind if you only meant to touch cards.
There are limits on how many you can write. You can create a maximum of 200 transaction rules and 100 account rules.
Target the right payments, not everything
A rule that asks for authentication on every payment is tempting. It feels safe. It is not free.
Stripe's guide says indiscriminate use of 3DS might lower conversion rates. Every extra step is a chance for the buyer to quit. A poorly set up rule can automatically allow many high-risk payments or block many legitimate payments. Rules can negatively affect your business if used incorrectly.
So aim the rule. Stripe's own example aims it at cards that have not been used on your account. The payments where a challenge earns its cost. For more on building rules that fit your store, see our page on stripe radar rules.
Test the rule before you enforce it
Do not flip a rule on for all payments and walk away. Traffic allocation lets you monitor a custom rule's performance before enforcing its action on every matching payment. Run it on a slice of traffic first.
The Review new rule page shows how a rule performs against your recent payments. Read that before you commit. You want to know what the rule would have done, not guess.
One more thing to know. Rules only apply to future payments. They do not reach back to payments you already processed.
Check whether authentication happened
After the payment, you can see if the challenge really ran. The is_3d_secure_authenticated attribute is true when the issuer attempted 3DS and the customer completed a full authentication.
During 3DS2 authentication, Stripe.js collects basic device information and sends it to the issuing bank. That is part of the flow, not something you control.
What you cannot control
A few things stay out of your hands no matter how good your rules are.
The issuer decides the final authentication flow. You cannot customize the web authentication UI, because the bank that issued the card controls the fonts and colors. The buyer sees the bank's screen, not yours.
You cannot turn 3DS off through the API. You cannot make the issuer run it. You can only ask, watch what happens, and adjust.
For the team side of this work, see stripe radar for fraud teams. To stop known bad actors before a rule ever fires, use the stripe radar block list.
A fraudulent sale that slips through can later turn into a chargeback. Requesting 3DS on the risky ones is one way to shrink that pool. It is a tool with limits, and the limits are worth knowing before you write the rule.