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
    4100000000000019 Results in a charge with a risk level of highest. The charge is blocked as it's considered fraudulent.
    4000000000004954 Results in a charge with a risk level of highest.
    4000000000009235 Results in a charge with a risk level of elevated.
    Token Description
    tok_chargeDeclinedFraudulent Results in a charge with a risk level of highest. The charge is blocked as it's considered fraudulent.
    tok_riskLevelHighest Results in a charge with a risk level of highest.
    tok_riskLevelElevated Results in a charge with a risk level of elevated.

    Rules

    Custom rules are not run on test-mode charges because many of the needed payment attributes are only available in live mode.

    However, 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.

    Questions?

    We're always happy to help with code or other questions you might have! Search our documentation, contact support, or connect with our sales team. You can also chat live with other developers in #stripe on freenode.

    Was this page helpful? Yes No

    Send

    Thank you for helping improve Stripe's documentation. If you need help or have any questions, please consider contacting support.