Create account
Sign in
Home
Payments
Business operations
Financial services
Developer tools
Security
All products
Home
Payments
Business operations
Home
Payments
Business operations
Financial services
Developer tools
Support
Overview
Overview
Risk evaluation
Risk settings
Reviews
Lists
Rules
Testing
Checklist
Disputes and fraud
Climate
Identity
radar
ยท
HomeBusiness operationsFraud detection

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.

NumberDescription
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
Was this page helpful?
Questions? Contact us.
Developer tutorials on YouTube.
You can unsubscribe at any time. Read our privacy policy.