Optimize fraud prevention to your unique goals by writing rules specific to your business.

You might have unique business logic that you’d like to implement within Stripe. For instance, you may want to:

  • Request 3D Secure for all payments that support 3D Secure and are made by a new customer
  • Allow all payments from your call center’s IP address
  • Block payments made from a location or card issued outside your country
  • Review all payments greater than $1,000 that have been made with a prepaid card

Rules allow you to implement this business logic as specific actions to be taken whenever a payment matches a criteria that you define. Stripe Radar comes with some built-in default rules and Stripe Radar for Fraud Teams gives you the ability to create custom rules in the Dashboard.

Built-in rules

Stripe Radar and Stripe Radar for Fraud Teams provide a set of default rules based on the judgments of our machine learning models, which are:

Block if Stripe evaluates the payment as high risk

Payments with a high risk of fraud are blocked and not processed. This rule is enabled by default.

Review if Stripe evaluates the payment as elevated risk

With Stripe Radar for Fraud Teams, payments that we suspect have an elevated risk of fraud are placed into review by default.

Traditional card checks

A payment can still be successful even if the CVC or ZIP code check fails. This is because card issuers take many signals into account when making a decision whether to approve or decline a payment. In some cases, a card issuer may still approve a payment they consider legitimate even if the CVC or ZIP code verification check fails.

A failed CVC or ZIP code check can be an indication of fraud, even if the card issuer has approved the payment. Stripe provides CVC and ZIP code verification as built-in rules so you can block payments even if they have been approved by the card issuer.

These rules also apply to the card validation process that occurs when adding a card to a customer’s account. In cases where the card and customer are created together, CVC or ZIP code validation failure prevents the successful creation of the customer record.

Block if CVC verification fails

Payments that fail a card issuer’s CVC verification check are blocked. If the CVC number is not provided, or the customer’s card issuer doesn’t support its verification, the rule cannot block the payment.

Block if ZIP code verification fails

Payments that fail a card issuer’s ZIP code verification check are blocked. If the ZIP code is not provided, or the customer’s card issuer doesn’t support its verification, the rule cannot block the payment.

Built-in rules to request 3D Secure

With 3D Secure, a customer is prompted to complete an additional authentication step before they can complete the purchase flow. If a payment is authenticated by 3D Secure, the liability for any fraudulent dispute that occurs on that payment is typically shifted from the merchant to the issuer. This means that in most cases, the merchant will not be responsible for fraud costs on 3D Secure authenticated payments.

When using Payment Intents or Setup Intents, Stripe provides three default rules to dynamically request 3D Secure:

  1. Request 3D Secure if 3D Secure is required for card * Automatically prompt the customer for 3D Secure authentication if the card used requires 3D Secure. * Note that if 3D Secure is not used when the customer’s card requires 3D Secure authentication, some card issuers may choose to decline the payment.
  2. Request 3D Secure if 3D Secure is supported for card * Disabled by default but similar to the above previous rule. Enabling this rule will prompt the customer for 3D Secure authentication as long as their card supports 3D Secure. * Use this instead of the previous rule if you want to maximize the number of payments that have liability shift. Note that this additional friction may decrease conversion rates.
  3. Request 3D Secure if 3D Secure is recommended for card * Automatically prompt the customer for 3D Secure authentication if the card used recommends 3D Secure. * Disabled by default. Enabling this rule will prompt the customer for 3D Secure authentication when Stripe believes that 3D Secure authentication will be achieved with minimal impact on conversion rates. * Enable this if you want to maximize the number of payments that have liability shift.

After attempting 3D Secure authentication, the result can be evaluated in Allow, Block or Review rules with the following attributes:

  • :is_3d_secure: = false and :is_3d_secure_authenticated: = false
    • 3D Secure is not supported on this card and cannot be invoked. The PaymentIntent will proceed without performing authentication.
  • :is_3d_secure: = true and :is_3d_secure_authenticated: = false
    • 3D Secure was attempted but the card is not enrolled in 3D Secure. The PaymentIntent will proceed without performing authentication.
  • :is_3d_secure: = true and :is_3d_secure_authenticated: = true
    • 3D Secure was attempted and the card was authenticated by the issuer. The authentication may or may not have included a challenge.

On the other hand, if 3D Secure was attempted but authentication failed, then the PaymentIntent or SetupIntent will have a status of requires_payment_method and the payment_failed webhook will be called.

In most cases a charge that has gone through 3D Secure will receive a liability shift, but there are exceptions. To verify that a charge has received a liability shift in a rule, use the attribute :has_liability_shift:. Also, note that 3D Secure requires your customer to go through an additional layer of authentication, and indiscriminate usage of 3D Secure may hurt conversion rates. We recommend that you make use of our default Request 3D Secure rules to only send payments from supported cards through 3D Secure.

Knowing when to create rules

Stripe’s default rules can block a substantial number of fraudulent payments. For businesses that need more control over which payments should be reviewed, allowed, or blocked, rules are a powerful tool to use.

To help you decide whether you need rules and the exact types of rules you might implement, here are some questions to consider:

  • Are there certain features or user behaviors that you perceive to be more risky (e.g., use of a disposable email)?
  • Are there payments of a certain amount you want to manually review or perceive to be very low risk and would want to allow through (e.g., review if the payment is greater than $500, allow if the payment is less than $5)?
  • Do your existing disputed and refunded payments share any common patterns (e.g., similar amounts, card types, or countries)?
  • Do you have existing rules that you want to migrate to Stripe? Keep in mind that many of these rules may already be covered by Stripe’s machine learning models, and it is worth seeing how our system performs for your business before customizing it.

How to create effective rules

While rules can help you automate your existing workflows, they can also become detrimental to your business if used incorrectly. For example, a rule can automatically allow a large number of payments that are fraudulent or block a large number of legitimate payments.

Some helpful tips to keep in mind while setting up rules include:

  • Rules only apply to future payments and do not apply to any that have already been processed
  • Request 3D Secure rules apply only when using Stripe Checkout, Payment Intents, or Setup Intents, and are evaluated before Review, Block, and Allow rules
  • Before implementing any block rule, which would block all payments that meet its criteria, consider whether you’d rather review these payments first
  • Allow rules should be rarely implemented, as they override Stripe’s default rules along with any other custom rules that match the same criteria
  • A maximum of 200 rules across all rule types can be created per account

Rules are created and managed within the Dashboard. To create a rule, first decide upon the action it should take, then click Add rule. You can test your rule using your account’s payment history from the last six months to see what effect the rule would have before saving it.

Review rules

Payments that meet a review rule’s criteria are still processed normally. They’re also placed into your review queue for your team to take a closer look at. Setting up too broad a rule can result in too many payments being placed into your review queue, slowing down your customer journey and burdening your review team.

Stripe’s rule testing interface runs a simulation on the last six months of charges to determine how many legitimate, fraudulent, and blocked payments would have been affected by the rule, had it been implemented. While testing a rule and examining the last six months, you should ensure that:

  • Overall volume of payments are low. Reviewing these payments should not pose a burden to your team.
  • Human reviewers add value. A human reviewer should be able to identify if the payment was fraudulent with greater confidence than the automated system.
  • The rule results in a mix of successful and refunded or disputed payments. This means that additional inspection on these types of payments can help separate legitimate ones from those that are fraudulent.

The following is an example of how a review rule created by a business that wants to review pre-paid credit cards can be improved.

Bad rule   Better rule
Review if :card_funding: = 'prepaid'   Review if :is_disposable_email: and :card_funding: = 'prepaid'
Too broad; results in too many reviews   More focused; results in a smaller number of reviews

Block rules

You can use block rules to block payments you strongly believe to be fraudulent, or based upon any restrictions your business may have in place (e.g., blocking payments from prepaid cards). If you’re experiencing some uncertainty, we recommend that you place payments in review using a review rule. After spending some time reviewing these payments for potential false positives, you can confirm if you’d like to create a block rule instead.

Block rules only impact fraudulent and successful payments, as already blocked payments would be unaffected. While testing a rule, you should ensure to:

  • Keep false positives as low as possible. During testing, Stripe surfaces the number of successful and disputed payments that would have been matched by the rule. A good block rule results in significantly more fraudulent payments blocked than legitimate payments.
  • Minimize unnecessary rules. If your rule appears to perform very well but is already covered by an existing rule, your newer rule may not be necessary. Similarly, if the results during testing appear to be mixed, consider setting up a review rule instead so you can gather more information about those types of payments.

The following is an example of how a block rule created by a business that is suffering from a high level of fraud from payments outside the U.S. can be improved:

Bad rule   Better rule
Block if :card_country: != 'US'   Block if :card_country: != 'US' and :risk_level: = 'elevated'
Too broad; high number of legitimate payments blocked   More focused; smaller number of false positives

Allow rules

Allow rules override all other rules, including Stripe’s machine learning models, and should be used with the most caution. Many businesses may not need to implement allow rules. If you have concerns that an allow rule could let through even a small number of fraudulent payments, you should consider adjustments to further restrict these rules before implementing them. As allow rules override all other rules, including Stripe’s machine learning judgments, we strongly recommend that any allow rule you create still continues to block any payments we believe are likely to be fraudulent.

Allow rules apply to all new payments once the rule has been created. This includes any that are similar to previously blocked payments. While testing a rule, you should ensure to:

  • Examine the number of previously blocked payments that would have been allowed. Allow rules override all other rules and Stripe’s risk assessment. When testing a new allow rule, all of the payments shown would have been allowed if this rule were active. This can include payments that had been blocked or disputed, impacting your future dispute rates.
  • Continue to block any high-risk payments. You can do this by adding the following to any allow rule: and :risk_level: != 'highest'

The following is an example of how an allow rule for a business that generally (but not always) sees good payments coming from customers in the United Kingdom can be improved:

Bad rule   Better rule
Allow if :ip_country: = 'GB'   Allow if :ip_country: = 'GB' and :risk_level: != 'highest'
Allows a significant number of fraudulent payments.   Ensures that any high risk payments continue to be blocked.

Maintaining your rules

As your business continues to grow, it’s important to make sure that your rules continue to reflect the types of customers that your business would like to see. Here are some best practices to keep rules working well for you.

Regularly monitor rules to ensure they are still effective

As patterns of fraud are constantly changing, you should re-evaluate your rules regularly. There is continuous feedback about the effectiveness of each of your rules with a running total of how many payments it has taken action against. You can click on this total to view a filtered list of every payment that a rule has been applied to. Evaluate this information to help you decide whether to make changes to a rule, keep it as-is, or remove it completely.

Additional actions can be found by clicking the ••• button. To disable or enable a rule, select either Disable or Enable. If you have created a rule and no longer want to keep it, select Delete.

Regularly monitor your manual review queue

If your review queue is getting too large to manage, check to see if you have the right rules in place. If most reviews end up being refunded as fraudulent, consider some additional rules to block payments. Likewise, if most payments are simply approved, consider making your review rules more focused.

Analyze your disputed and refunded payments

Disputes are inherently linked to fraud, so the more you do to reduce fraud, the lower your dispute rate. You should check to see if disputed payments share any similar traits or characteristics (e.g., from the same locations or of similar amounts). You can also perform this investigation looking at payments that have been refunded during a review. Once you’ve seen trends, you can test and create the appropriate rules. Should any payments look to be fraudulent, refund and report them as fraud to avoid potential disputes.

You can respond to any incoming disputes using the Dashboard or through the API, and our dispute documentation includes some suggestions on how to present a well-argued, solid case.

Anticipate large changes to your business that might impact your fraud rate

If you are planning any major product releases or changes to your service (e.g., a new, high-value product or expanding your service into new countries) then you may want to pay special attention to these specific payments. For changes like these, it’s a good idea to set up some review rules so your team can take a closer look at these new transactions. After spending some time reviewing these payments, you can identify any new patterns with which to set up subsequent rules that further protect your business from new types of fraud.

Next steps

Was this page helpful?
Questions? Contact us.
Developer tutorials on YouTube.