Processor Rules Configuration
- Default processor fraud rules are tuned for average merchants - they'll over-block some of your good customers and under-block some fraud patterns specific to your business
- Start with a rules audit: what share of fraud blocks are confirmed legitimate? Price those lost orders against the fraud prevented; a percentage alone won't tell you which costs more
- Build rules in shadow mode first (log the decision, don't enforce it) before flipping them live - one bad rule can tank auth rates overnight
- Review rules monthly against your actual false positive and catch data. What worked at $100K/month won't hold at $500K/month
Processor rules configuration is the process of customizing the fraud block, allow, review, and 3DS rules built into tools like Stripe Radar, Braintree Fraud Protection, and Adyen RevenueProtect. Default settings are tuned for average merchants, which means they block too much good revenue or let too much fraud through for your specific business. This page covers how to configure each major processor's fraud tools, build custom rules, and tune them monthly using false positive and fraud catch data.
Bots keep trying cards right now? Use the incident playbook before tuning ongoing rules.
What Matters
- Defaults are conservative. Processors don't want fraud on their platform, so they block aggressively.
- False positives cost more than you think. Every blocked good customer is lost revenue plus the acquisition cost you've already paid. See economics of fraud.
- Custom rules beat default ML for your edge cases. Processors see patterns across merchants, but they don't know your business.
- 3DS can shift liability. Use it strategically, not everywhere. See first-time 3DS setup.
- Monitor and tune continuously. One-time setup doesn't work. Track your fraud metrics.
Understanding Processor Fraud Tools
What Processors Offer
| Processor | Fraud Tool | Included? | ML Scoring? |
|---|---|---|---|
| Stripe | Radar | Radar Lite included, Standard / Plus / Pro are paid tiers | Yes |
| Braintree | Fraud Protection | Basic included, Advanced extra | Yes |
| Adyen | RevenueProtect | Included | Yes |
| Square | Basic built-in | Included | Limited |
| PayPal | Built-in screening | Included | Yes |
| Authorize.net | Advanced Fraud Detection Suite | Extra cost | Limited |
What the ML Does
Processor ML models score transactions based on:
- Device fingerprint
- IP geolocation and velocity
- Card metadata (issuer, country, BIN)
- Email patterns (see identity verification)
- Behavioral signals
- Cross-merchant data (what they've seen from this card elsewhere)
The score is typically 0-100 (higher = riskier) or a risk level (high/medium/low). See risk scoring for threshold strategies.
What You Control
| Control Type | Examples | Learn More |
|---|---|---|
| Block rules | Block if IP country != billing country | Velocity rules |
| Allow rules | Allow if customer has 3+ prior orders | Risk scoring |
| Review rules | Review if risk score > 75 | Manual review |
| 3DS rules | Require 3DS if order > $500 | 3DS setup |
| Velocity limits | Block if > 3 transactions from this card in 1 hour | Card testing |
Stripe Radar Configuration
Stripe's Radar is the most commonly used processor fraud tool for SMBs.
Default Behavior
Radar blocks transactions when its ML model predicts high fraud risk. You don't control the ML, but you control rules that run on top of it.
Radar Rule Types
| Type | What It Does | When Triggered |
|---|---|---|
| Block | Declines transaction immediately | Before auth |
| Allow | Bypasses other rules | Before other rules |
| Review | Marks for manual review | After auth |
| 3DS | Requires 3D Secure | Before auth |
Useful Starter Rules
These are illustrative conditions and syntax, not processor-required amounts, counts or score bands. Choose your own from confirmed fraud and legitimate customer history, then shadow and test before enforcing. The same applies to the 3DS examples below.
Block rules:
# Block mismatched countries
Block if :ip_country: != :card_country:
# Block high velocity
Block if :total_charges_per_card_number_hourly: > 3
# Block risky email patterns
Block if :email_domain: in ('tempmail.com', 'guerrillamail.com')
Allow rules:
# Allow existing customers
Allow if :customer_id: != null AND :total_charges_per_customer_id_all_time: >= 3
# Allow repeat cards
Allow if :total_charges_per_card_number_all_time: >= 2
3DS rules:
# 3DS for high-value
Request 3D Secure if :amount_in_usd: > 500
# 3DS for high risk
Request 3D Secure if :risk_score: > 65
The Paid Radar Tiers
A product called Radar for Fraud Teams still gets quoted at $0.02 per screened transaction, $0.07 on Connect platforms. That name appears nowhere on Stripe's Radar page, pricing page or docs as of 4 August 2026, and neither does the $0.02 figure. Wherever you find it, it's pricing a discontinued SKU. Source: stripe.com/radar and stripe.com/radar/pricing, verified 2026-08-04.
Stripe now sells Radar in four tiers: Lite, Standard, Plus and Pro. Radar Lite is included with Stripe Payments at no extra charge. Standard, Plus and Pro are monthly subscriptions, each with a fixed fee that includes a set allowance of screens per transaction, per active account, and per customer, with a pay-as-you-go option if you'd rather pay per screen.
What they cost. US list, read 4 August 2026:
| Tier | For your business | Platforms and marketplaces |
|---|---|---|
| Standard | From $10/mo | From $20/mo |
| Plus | From $14/mo | From $44/mo |
| Pro | From $20/mo | From $70/mo |
Each tier includes a screen allowance. Past it you're on pay-as-you-go, which starts at $0.05 per screened transaction. You can take pay-as-you-go on its own instead if your volume is low or unpredictable.
What the paid tiers add over Lite:
- Custom rule builder with more attributes
- Manual review queue
- Block and allow lists
- Advanced analytics
Worth pricing if you're over $500k/mo or have complex fraud patterns.
"Which Radar tier are we on: Lite, Standard, Plus or Pro? What Radar rules do we currently have, and what does the subscription cost us per month?"
Braintree Configuration
Braintree's fraud tools are part of Braintree Gateway.
Basic Fraud Protection
Included with Braintree:
- AVS mismatch blocking
- CVV mismatch blocking
- Duplicate transaction detection
- Risk threshold configuration
Advanced Fraud Protection
Paid add-on with:
- Device fingerprinting
- ML risk scoring
- Custom velocity rules
- Kount integration option (see fraud vendors)
Key Settings to Configure
| Setting | Recommendation |
|---|---|
| AVS response handling | Block on full mismatch, allow partial |
| CVV response handling | Block on mismatch |
| Risk threshold | Start at "Approve" for low/medium, "Review" for high |
| Duplicate transaction window | 30 seconds |
Braintree Custom Rules
Via Control Panel > Fraud Management:
# Example: Block international for domestic business
Rule: Card Country NOT equals US
Action: Decline
# Example: Review high-value
Rule: Transaction Amount greater than 1000
Action: Review
Adyen RevenueProtect Configuration
Adyen's fraud tool is included but needs configuration.
Risk Profiles
Adyen uses "Risk Profiles" that group settings by business type:
- E-commerce
- Retail
- Subscription
- Digital goods
Start with the profile matching your business, then customize.
Key Configuration Areas
| Area | What to Set |
|---|---|
| Risk scoring | Set thresholds for accept/review/block |
| Velocity checks | Transactions per card/email/IP per hour/day |
| AVS/CVV handling | Decline vs. review on mismatch |
| 3DS triggers | Amount thresholds, risk levels |
| Block/Allow lists | Cards, emails, IPs |
Adyen RevenueProtect Rules
Via Customer Area > Risk:
- Select profile
- Add rules in order (first match wins)
- Test with simulation before live
3DS Configuration Strategy
3D Secure adds an authentication step. Configure it strategically.
When to Require 3DS
| Trigger | Why |
|---|---|
| High transaction amount (> $500) | High value = higher risk tolerance |
| High-risk score | Adds friction only for risky transactions |
| International transactions | Cross-border fraud is higher |
| First transaction with new card | No history to trust |
| Mismatched shipping/billing | Common fraud signal |
When to Skip 3DS
| Trigger | Why |
|---|---|
| Returning customer with history | Trust is established |
| Low-value transaction (< $50) | Fraud loss < conversion loss |
| Transaction qualifies for exemption | TRA, low-value, trusted beneficiary |
| Mobile checkout | 3DS UX is painful on mobile |
3DS Rule Examples
Stripe:
Request 3D Secure if :amount_in_usd: > 500
Request 3D Secure if :risk_score: > 65
Braintree:
3DS Required when: Amount > 500 AND Risk = High
3DS Optional when: Amount > 200 AND Customer new
3DS1 vs 3DS2
If you're still on 3DS1, upgrade. 3DS2 supports frictionless authentication (no customer challenge for low-risk), which dramatically reduces conversion impact.
"Are we on 3DS1 or 3DS2? What's our frictionless rate?"
Common Mistakes
Mistake 1: Never Touching Defaults
Default settings are calibrated for the average merchant. If you're higher-risk, you'll get more fraud. If you're lower-risk, you'll block good customers.
Fix: Review and customize within 30 days of launch.
Mistake 2: Blocking Too Aggressively
Overly strict rules block good customers. A blocked good customer costs you:
- The transaction revenue
- Future LTV
- Acquisition cost wasted
- Potential bad review
Fix: Start with review instead of block. Analyze what you're blocking.
Mistake 3: Not Monitoring Rule Performance
A rule that worked in January may hurt in July. Traffic patterns change.
Fix: Monthly review of:
- Rule trigger rates
- False positive estimates
- Fraud that got through
Mistake 4: One-Size-Fits-All 3DS
Requiring 3DS on everything kills conversion. Skipping 3DS on everything invites fraud.
Fix: Risk-based 3DS triggers.
Mistake 5: No Allow Rules for Good Customers
If a repeat customer triggers a risk rule, they shouldn't be blocked.
Fix: Allow rules for trusted customers before block rules.
Rule Tuning Process
Monthly Review
- Pull fraud losses - What got through that shouldn't have?
- Pull block rates - What are we blocking?
- Sample blocked transactions - Were they actually fraud?
- Calculate false positive rate - Blocked good / Total blocked
- Adjust rules - Tighten where fraud is high, loosen where false positives are high
Tuning Example
Problem: Rule "Block if IP country != card country" is blocking 5% of transactions.
Analysis:
- Pull sample of 50 blocked transactions
- Contact 10 customers from blocked list
- 8 of 10 were legitimate (travelers, VPN users)
- Confirmed legitimate among the 10 contacted: 8 / 10 = 80%. That isn't an estimate for all blocks: the contact group may be selective, and the other sampled orders still need investigation.
Solution: move it from Block to Review, add an exception for known VPN ASNs, or make it a 3DS trigger instead. Blocking isn't your only option.
Test to Run
2-week fraud rules audit:
Week 1: Discovery
- Document all current rules
- Pull rule trigger rates for past 30 days
- Pull fraud losses for past 30 days
- Identify top 5 rules by trigger volume
Week 2: Optimization
- Sample blocked transactions for false positive analysis
- Add allow rules for repeat customers
- Convert highest-FP block rules to review
- Add 3DS for high-risk instead of block
Week 2's changes loosen live rules, so make them one at a time and treat each as a live test: an owner, a loss cap and a way back.
Success criteria: False positive rate decreases. Fraud rate doesn't increase once the outcome window has closed. Until then, the fraud side is inconclusive.
Scale Callout
| Volume | Focus |
|---|---|
| Under $100k/mo | Start with processor controls. Test 3DS on a measured high-loss segment; set amounts from your own orders. Review only when expected benefit justifies the time. |
| $100k-$1M/mo | Custom rules for your top fraud patterns. Monthly rule review. Price a paid Radar tier (Standard, Plus or Pro) or an equivalent from your processor. |
| Over $1M/mo | Dedicated fraud rules person or vendor. Real-time monitoring. A/B testing of rule changes. Multi-layer fraud stack. |
Where This Breaks
-
High-risk categories with sophisticated fraud. Gift cards, electronics resale, cryptocurrency. Processor tools alone won't cut it. You need specialized fraud vendors.
-
Marketplaces and platforms. Fraud comes from sellers as well as buyers, and processor tools only see the buyer side. That's why you need platform-level detection.
-
International with local payment methods. Processor tools are optimized for cards. Local methods (iDEAL, Boleto, etc.) need different fraud approaches.
Analyst Layer: Metrics to Track
Use the Fraud Metrics definitions so these rates use the same denominators across your reports.
| Metric | What It Tells You | How to judge it |
|---|---|---|
| Block rate | Fraud-control blocks / Total attempts | Compare with similar traffic and your customer-impact budget |
| Review rate | Manual review load | Cases you can clear before fulfillment deadlines |
| False positive rate | Confirmed legitimate / All fraud blocks | Compare lost margin with fraud prevented; report unknowns |
| Fraud rate | Confirmed fraud count / Transaction count | Your loss budget and applicable written processor limits |
| 3DS challenge rate | Challenges / Total 3DS attempts | Compare by issuer and customer segment |
| 3DS completion rate | Completed challenges / Challenges started | Investigate changes against the same checkout flow |
Rule Performance Dashboard
Track for each rule:
- Trigger count (how often it fires)
- Block/review/allow breakdown
- Fraud caught (confirmed fraud among blocked)
- False positives (legitimate among blocked)
- Revenue impact
Processor Rule Performance Analysis
Build a monthly rule effectiveness report:
| Rule | Triggers | Blocks | Reviews | Fraud Caught | False Positives | FP Rate |
|---|---|---|---|---|---|---|
| High amount | 500 | 100 | 400 | 25 | 75 | 75% |
| IP mismatch | 300 | 50 | 250 | 20 | 30 | 60% |
| Velocity | 200 | 100 | 100 | 80 | 20 | 20% |
Analysis questions:
- Which rules have highest FP rate? → Candidates for loosening
- Which rules catch the most fraud? → Keep tight
- Which rules have low trigger rates? → Maybe unnecessary
- What fraud gets through? → Need new rules
Rule ROI Calculation
For each rule, calculate:
Rule Value = (Fraud Blocked × Avg Fraud Loss) - (False Positives × Avg LTV Lost)
Example: High-amount block rule
- Fraud blocked: 25 transactions × $200 avg = $5,000 saved
- False positives: 75 transactions × $500 LTV = $37,500 lost
- Rule ROI: -$32,500 → This rule is losing money
Optimization Priorities
| FP Rate | Fraud Catch Rate | Action |
|---|---|---|
| High | High | Convert to review, investigate each |
| High | Low | Remove or significantly loosen |
| Low | High | Keep as-is, maybe tighten |
| Low | Low | Remove, not adding value |
A/B Testing Rules
A split test sends real orders through the new rule, so it's a live test. Before it starts, write down who owns the risk, which orders it touches, the loss cap, rollback, stop rule and outcome window. Then:
- Split traffic - A small share gets the new rule and the rest keeps the old one. Start small, for example 10%
- Watch the stop rules daily - Pause the moment one fires
- Wait for outcomes - Block and auth rates show within days. Fraud and disputes take weeks, so judge them on the outcome window you set, not on two weeks of data
- Validate significance - Is the difference real?
- Roll out or revert - Inconclusive means revert and keep the old rule
Next Steps
Setting up processor rules?
- Understand what processors offer - ML and rule options
- Configure Stripe Radar - Block, allow, review, 3DS
- Set 3DS strategy - When to require, when to skip
Tuning existing rules?
- Follow monthly review process - Pull fraud, blocks, samples
- Avoid common mistakes - Never touching defaults, blocking too aggressively
- Calculate rule ROI - Fraud saved vs LTV lost
Advanced optimization?
- Build rule performance dashboard - Track each rule
- A/B test rule changes - Split traffic validation
- Set optimization priorities - FP rate vs catch rate
Related Pages
- Fraud Prevention - Prevention strategies
- 3DS Optimization - Authentication tuning
- Auth Optimization - Approval rates
- Velocity Rules - Rate-based detection
- Fraud Vendors - Third-party tools
- Risk Scoring - Score thresholds
- Rules vs. ML - Detection approaches
- Data Enrichment - IP, email, phone signals to supplement processor rules
- Device Fingerprinting - Digital identity
- Manual Review - Review queues
- Checkout Conversion - Friction balance
- Fraud Metrics - Measuring effectiveness
- Experimentation - Testing rules