Stripe Radar Block Lists: A Plain Guide
Radar lists hold emails, IPs and card fingerprints that your rules can act on. Here is how the default lists work and when to build your own.
A Stripe Radar block list is a stored set of information that your rules can act on. An email on the list can stop a payment. An IP on the list can send one to review. The list itself does nothing. The rule does the work, and the list feeds it.
What a Radar list is, and how it connects to rules
Stripe's documentation says you can create lists of specific types of information and use them in rules. That is the whole idea. Instead of naming one bad email in a rule, you point the rule at a list. The list holds many of them.
This is why lists matter. Stripe's documentation says lists make rules more manageable by letting similar types of information be added for a rule to use automatically. You add an email to the list once. Every rule that points at that list picks it up. You do not edit the rule again.
So a block list is not a separate fraud filter sitting beside Radar. It is a part of stripe radar rules, and rules are where the blocking happens.
Default lists: what ships with Radar and what you can change
Stripe Radar includes a set of default lists to help you get started. You do not have to build anything from scratch on day one.
You can add and remove items from default lists, but you can't edit or remove the default lists themselves. So treat them as fixed containers with contents you control. If a default list fits your need, use it and add to it. If you need a different shape of list, build a custom one instead.
Custom lists: building your own by information type
You can create custom lists that contain items of a specific type of information. Each custom list holds one kind of thing. A list of emails. A list of IP addresses. A list of card BINs. You would not mix them, because a rule needs to know what it is comparing against.
Build a custom list when your situation does not match a default list. Maybe you want a list of trusted customer IDs, or a list of client IP countries. Name it clearly, keep it to one type, and let your rules point at it.
What can go in a list
Stripe's documentation names the types of information a list can hold. It is worth knowing what each one is.
The email used is the first email derived from the Charge, Card, or Customer objects, in that order. So the list acts on the email tied to the payment, wherever Stripe found it.
The card BIN is the first six digits of the card number. A BIN list lets your rules act on cards by those first six digits.
The client IP country is a two-letter code for the country where the payment originates. A list of these can drive rules about where orders come from.
Bank accounts have fingerprints too. The ACH fingerprint is a unique Stripe identifier of a particular ACH bank account. The SEPA fingerprint is a unique Stripe identifier of a particular SEPA bank account. A fingerprint list can catch the same bank account coming back under a new email.
Customer IDs can go in a list as well, and that use has a pleasant side, covered next.
Blocking, allowing and reviewing: the three outcomes
A list can drive three different outcomes, and Stripe's documentation gives an example of each.
A list of email addresses tied to fraud can automatically block any payment with an email address on that list. That is the classic block list.
A list of suspicious IP addresses can place payments into review when they have a matching IP address. Review means a person looks before the order ships, rather than the list deciding alone.
And a list of customer IDs for trusted customers can automatically allow payments by those customers. The same tool that blocks bad actors can also wave good ones through, so your regulars stop tripping your own checks.
How marking a refund as fraudulent feeds the default lists
Here is a quiet way the default lists grow. Stripe's docs say marking a refund as fraudulent adds the payment's email address and card fingerprint to default block lists.
So when you refund an order and mark it fraudulent, you are not just closing a ticket. You are teaching the default lists. The next payment from that email or that card fingerprint has a better chance of being stopped by a rule that points at those lists. A fraudulent sale can later turn into a chargeback, so this habit is worth keeping.
Where block lists fit in a broader fraud setup
Lists are one part of a Radar setup, not the whole of it. They pair naturally with stripe radar rules, which decide what happens when a list matches.
They also sit beside other tools. stripe radar 3ds can step a payment up to extra verification. stripe ai fraud detection evaluates payments without you writing a rule at all. And if your store has a team on it, stripe radar for fraud teams covers the fuller workflow.
Use lists for what you know. Use rules to act on it. Use the rest of Radar for what you have not seen yet.
What block lists won't do
A block list only acts on what is on it. A brand new fraudster with a fresh email, a fresh card and a fresh IP will not match anything. Lists are memory, not prediction.
They also depend on rules. A list with no rule pointing at it changes nothing.
And no list, rule or filter stops all fraud. Anyone who tells you otherwise is selling something. Keep your lists maintained, keep your rules pointed at them, and treat both as one layer among several.