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.
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 each rule you test, the summary includes the volume and number of payments that fall into the following categories:
- Disputed & EFW: Payments that received a dispute or an early fraud warning (EFW).
- Refunded: Payments that were refunded.
- Failed & Blocked: Payments that were either blocked by Radar, blocked by Stripe, or declined by issuers.
- Legitimate: Payments that are successfully processed and haven’t yet been identified as fraudulent nor refunded.
Additionally, when you test allow rules, you can also see Overrides. This refers to payments that Radar blocks due to high risk of fraud or a custom block rule, but now will be allowed by your proposed rule. In the Dashboard, you can see further breakdowns of these summary metrics. For example, you can see refunds that are classified as fraudulent.
Review the sample questions in the following table to help you decide if you can implement your rule.
It’s uncommon to find a perfect rule that only blocks fraudulent payments or only allows good payments. Thus, your decision to implement a rule is typically based on a trade-off. Consider if this rule will block enough fraudulent payments to be worthwhile compared to any valid payments it might incorrectly block. The trade-off that’s right for you depends on the particulars of your business. For more information, see our fraud detection primer.
|Rule type||Implement this rule if…|