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.

Reviewing payments

Payments created in test mode with an elevated risk level are placed into your review queue. This gives you a good opportunity to test how you intend to review payments, including sending any additional information that can be useful during the review process (e.g., making use of metadata to provide order details or shipping information).

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.