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 that are evaluated at a specific risk level. Test payments can be created either in the Payments page of the Dashboard when in test mode or by making a charge request using the API and your test API key.
| Number | Description |
|---|---|
| 4000000000004954 | Results in a charge with a risk level of highest, but will be blocked according to the rules you have in place (for example, the Block if :risk_level: = 'highest' rule may be disabled, in which case payments made with this card will not be blocked). |
| 4100000000000019 | Results in a charge with a risk level of highest, and will always be blocked regardless of your rules. |
| 4000000000009235 | Results in a charge with a risk level of elevated. |
| Token | Description |
|---|---|
| tok_riskLevelHighest | Results in a charge with a risk level of highest, but will be blocked according to the rules you have in place (for example, the Block if :risk_level: = 'highest' rule may be disabled, in which case payments made with this card will not be blocked). |
| tok_chargeDeclinedFraudulent | Results in a charge with a risk level of highest, and will always be blocked regardless of your rules. |
| tok_riskLevelElevated | 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 (depicted below) compares
- Payments disputed or refunded as fraud that the rule would have blocked—i.e. the payments you would want to match—and
- Other successful payments this rule would have 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 have placed in review, and
- Other successful payments the rule would have 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. Nonetheless, for proposed allow rules we summarize:
- Previously blocked payments that the rule would have allowed, and
- 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, or
- Matches so few charges that it would be difficult to draw conclusions about its future behavior.