Implementing Custom Fraud Rules and Logic

Welcome! While Stripe Radar offers powerful default fraud detection, every business has unique risks. This lesson empowers you to go beyond the defaults.

You'll learn to create custom fraud rules to perfectly match your specific business context and risk tolerance, giving you fine-grained control over how transactions are handled.

Custom rules in Stripe Radar have three primary actions. Understanding these is key to effective fraud management:

• Block: Immediately declines the payment. Use for high-confidence fraudulent activity.
• Review: Places the payment in your Radar review queue for manual inspection. Ideal for suspicious but uncertain transactions.
• Allow: Bypasses other rules and processing, allowing the payment to proceed. Use for trusted customers or low-risk scenarios.

Custom rules work by evaluating various attributes associated with a payment. These are data points Stripe collects about the transaction, card, customer, and more.

Common attributes you can use include:

• :card_country: (e.g., 'US', 'GB')
• :ip_country: (e.g., 'DE', 'FR')
• :amount: (in the smallest currency unit, e.g., cents)
• :risk_level: ('normal', 'elevated', 'highest')
• :customer_age: (days since customer creation)

Custom rules follow a simple attribute operator value structure. You'll use logical operators to define conditions.

• Equality: = (equal to), != (not equal to)
• Comparison: >, <, >=, <=
• Inclusion: IN, NOT IN (for lists of values)
• Pattern Matching: MATCHES (for regex)

For example: :card_country: = 'NG' checks if the card is from Nigeria.

Let's say you've observed high fraud rates from specific countries. You can create a rule to automatically block transactions originating from them.

This rule would immediately decline any payment where the card's country is either 'NG' (Nigeria) or 'GH' (Ghana).

Sometimes, a transaction isn't definitively fraudulent, but it's suspicious enough to warrant a human eye. This is where 'Review' rules shine.

This rule flags payments for review if they are over $500 (50000 cents) AND come from a customer created less than 7 days ago, indicating a new customer making a large purchase.

Allow rules are powerful for reducing false positives. They ensure that trusted transactions bypass review, even if they might otherwise trigger a 'Review' or 'Block' rule.

This rule allows payments from specific trusted customer IDs, as long as the amount is less than $100. Replace 'cus_ABC' with your actual customer IDs.

You can build complex logic by combining multiple conditions using AND and OR operators. Use parentheses () to control the order of evaluation.

This rule blocks payments if the card's country doesn't match the IP address's country AND Stripe's internal risk assessment is 'elevated' or 'highest'.

Stripe allows you to attach custom metadata to charges, customers, or Payment Intents. This is incredibly useful for building rules based on your unique business data.

For example, if you track a 'loyalty_status' or 'plan_type', you can use it in your rules:

Before deploying a new rule to live mode, always test it thoroughly! Use Stripe's test mode and monitor the rule's performance.

• Start with 'Review' rules to observe impact before 'Block'.
• Iterate and refine based on real-world data.
• The Stripe Dashboard's Radar section provides a powerful visual rule builder and analytics.

Consider the following custom rule you've just deployed:

Which of the following transactions would be blocked by this rule?

You've learned how to leverage Stripe Radar's custom rules to create a highly tailored fraud prevention strategy. By defining Block, Review, and Allow rules based on various attributes and logical operators, you gain precise control.

Remember to test thoroughly and iterate on your rules to keep your business safe from evolving fraud threats. Happy building!