Testing Stripe Radar

Use the following information to test your fraud prevention strategy.

Use the following test credit card numbers to create payments in test mode with a specific risk level. Create test payments in either the Stripe Dashboard (in test mode) or by calling create a charge with your test API key.

Number	Description
	Results in a charge with a risk level of `highest`, but could be blocked depending on the rules you have in place (for example, payments made with this card aren’t blocked if the `Block if :risk_level: = 'highest'` rule is disabled).
	Results in a charge with a risk level of `highest`, and is always blocked regardless of your rules.
	Results in a charge with a risk level of `elevated`.

Rules

Before you add or update a rule, we’ll search for historical live mode payments that match the rule criteria. You can inspect that list of payments to verify the criterion’s intended behavior, and we also summarize those search results to help you estimate its future impact.

For block rules, the summary compares:

Payments disputed or refunded as fraud that the rule would’ve blocked (i.e., the payments you would want to match)
Other successful payments this rule would’ve blocked (i.e., the payments you would not want to match)

It’s uncommon to find a perfect rule that only blocks fraudulent payments, so your decision to implement a rule is typically based on a trade-off: will this rule block enough fraudulent payments to be worthwhile compared to any good payments it incorrectly blocks? The trade-off that’s right for you will depend on the particulars of your business. For a more complete discussion of exactly this trade-off in Stripe’s own fraud analysis, see our fraud detection primer.

Similarly, for review rules, we compare:

Payments disputed or refunded as fraud that the rule would’ve placed in review
Other successful payments the rule would’ve placed in review

Allow rules are somewhat trickier to evaluate because there’s no way of knowing which previously-blocked charges would, if allowed, have turned out to be fraudulent. So, with these rules, it’s particularly important to review the list of matching historical payments to ensure these are payments you’d like to allow. For proposed allow rules, we summarize:

Previously blocked payments that the rule would’ve allowed
Successful payments matched by the rule that were later disputed or refunded as fraud

In addition to reviewing this summary, you can click the Matching payment attempts over the past six months link to review the full list of matched charges. We’ll also warn you if your proposed rule:

Appears to match a larger portion of your payments than is typically desirable for a custom rule
Matches so few charges that it would be difficult to draw conclusions about its future behavior