Stripe Radar Rules: A Merchant's Guide
Radar rules let you allow, block or review payments with your own logic. Here is how to write them without blocking good customers.
Stripe Radar comes with default rules. Rules are the part you write yourself. They add your own rules on top. You might block prepaid cards. Or review payments from a client IP country you choose. A bad rule can let risky payments through or block good ones. So build them with care.
How rules fit with Radar's default rules
How does Stripe Radar work with custom rules? Your custom rules run alongside Stripe's default rules. Your rules act on facts about the payment that you care about. Think of your rules as your store's own policy. Stripe's guide says you can use custom rules in Radar to limit or prevent card testing activity.
Rule syntax and the three actions
What is the syntax for a Radar rule? A rule follows this shape: {action} if {attribute} {operator} {value}. For example, Stripe's guide says you can create a custom rule to review payments made with a prepaid card.
There are three actions, and the difference between allow, block and review rules is what happens to the payment:
- Allow. The payment goes through, even if other rules or the default rules would have caught it.
- Block. The payment is declined. You can block payments based on business restrictions, such as blocking payments from prepaid cards.
- Review. Payments still process normally when they match a review rule's criteria, and are added to your review queue. Nothing is declined, and you get a chance to look at the payment.
An allow rule beats the Stripe default rules. It also beats any other custom rule that matches the same payment. This works well for trusted customers. Put their IDs in a list, and their payments go through on their own. It is also the easiest way to let a bad payment through, so use it sparingly.
Attributes you can use
Which attributes can I use in a Radar rule? The common ones:
- Card BIN. The first six digits of the card number.
- Client IP country. A two-letter code for the country where the payment originates.
- Email. The first email derived from the Charge, Card, or Customer objects, in that order.
- ACH and SEPA fingerprints. A Stripe code that points to one bank account.
- 3DS status. The is_3d_secure_authenticated attribute is true when the bank tried 3DS and the customer finished the check.
One caution. A payment can still succeed even when the CVC or address check fails, so do not treat those checks as a rule-free safety net.
Using lists in rules
Lists keep rules tidy. You add many items of the same kind, and a rule can use them all at once. Stripe Radar includes a set of default lists to help you get started. You can add and remove items from default lists, but you can't edit or remove the default lists themselves.
You can also create custom lists that contain items of a specific type of information. A list of email addresses tied to fraud can automatically block any payment with an email address on that list. A list of suspicious IP addresses can place payments into review when they have a matching IP address. For more on the default lists and what they contain, see stripe radar block list.
Requesting 3DS from a rule
Can a Radar rule trigger 3DS? Yes. A rule can request 3DS on all cards that haven't been used on your account. Request 3DS rules apply only with Stripe Checkout, Payment Intents, or Setup Intents. Asking for 3DS does not mean the bank will run it. And asking for it on every sale may cost you sales. The details of when to ask for it are covered in stripe radar 3ds.
Testing rules before enforcing them
How do I test a Radar rule before it affects real payments? Traffic allocation lets you watch how a new rule does first. Then you can turn on its action for every payment it matches. The Review new rule page shows how a rule performs against your recent payments. You can also write rules in a test space and try them on test cards.
The Radar Assistant
The rule editor has a built-in assistant. You type what you want in plain words, and it writes the rule for you. Check the output before you save it. Stripe invites readers to share feedback about how the Assistant performed.
Limits, scope, and pitfalls
You can create a maximum of 200 transaction rules and 100 account rules. Rules only apply to future payments and not to payments you already processed. By default, rules cover every payment method you support. You can name one method in a rule if you want.
Used wrong, rules can hurt your business. A bad rule can let many risky payments through. It can also block many good ones. If a team handles your fraud work, stripe radar for fraud teams covers the review queue and risk settings. Use more than one processor? See adyen risk rules for how Adyen describes its own.
What happens after a rule fires
A payment that matches a review rule still processes normally and lands in your review queue. If a fraudulent sale slips through anyway, it can later turn into a chargeback. To dig into the data, use Sigma and Data Pipelines. They can pull up disputes, fraud data and rule decisions. Marking a refund as fraudulent adds the payment's email and card fingerprint to default block lists. Your rules use them next time.