Rules

    Simplify your fraud operations by automating your workflows in the Dashboard. If you need help after reading this, get in touch or chat live with other developers in #stripe on freenode.

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

    • 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. Radar comes with some built-in rules and the ability to create more in the Dashboard.

    Built-in rules

    Radar provides 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

    By default, any payments that we suspect have an elevated risk of fraud are placed into review.

    Traditional bank checks

    A payment can still be successful even if the CVC or ZIP code code check fails. This is because banks take many signals into account when making a decision whether to approve or decline a payment. In some cases, a bank 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 bank 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 bank.

    Block if CVC verification fails

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

    Block if ZIP code verification fails

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

    While you can turn on and off CVC and ZIP code verification rules, you cannot use the CVC or ZIP code to build custom rules.

    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
    • 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 50 rules 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 certain countries). 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 appears 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 US 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 continue 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 does 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. Spending some time evaluating this information to help you decide whether to make changes to a rule, keep it as-is, or remove 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