Stripe Radar Rules That Actually Reduce Chargebacks

What Is Stripe Radar and How Does It Work?

Stripe Radar is the machine-learning fraud-detection layer built into Stripe's payment processing. It evaluates every transaction against hundreds of signals — card BIN, IP address, device fingerprint, transaction velocity, prior history on the network — and returns a risk_score between 0 and 100. Above the configured threshold, Stripe blocks the charge automatically. Below, it processes.

Radar also exposes a rules engine that lets merchants override the ML default with custom Allow, Block, Review, and 3D Secure rules written in a constrained expression language. Rules deploy through Stripe Dashboard → Radar → Rules and apply to all subsequent charges. The ML model continues running underneath; rules override or supplement its verdict for the specific patterns they target.

There are two tiers of Radar. Standard Radar is included with every Stripe account and provides the ML risk score plus a basic rules engine. Radar for Fraud Teams is a paid add-on that adds custom rule complexity, the Reviews queue for manual decisioning, advanced velocity attributes, and richer analytics. Most subscription apps approaching or already inside a Mastercard ECM or Visa VAMP placement should be on Radar for Fraud Teams — the standard tier's rule expressiveness is not sufficient for the structural moves required to exit a monitoring program.

Why Do Stripe's Default Rules Fail for Subscription Apps?

Stripe Radar's default behavior is calibrated for one-time-purchase ecommerce. In that world, a blocked customer rarely returns, false positives are revenue-destroying, and the optimal block threshold sits high — typically around risk_score > 65 with conservative rules layered on top. This calibration is correct for the average Stripe merchant. It is wrong for almost every subscription business.

Subscription apps operate under structurally different economics that the default rule set does not account for. The five structural mismatches below each carry an operator fix specific to subscription models.

Subscription apps have different transaction value economics

For a subscription app, the average transaction value at the point of risk decision is a $4.99 trial or a $9.99 first month — not the $80 annual plan or the $200 lifetime value those numbers eventually represent. Stripe Radar's defaults treat that $4.99 charge the same as a $4.99 one-time ecommerce sale: high block threshold to protect against the false positive that would lose a one-time customer. For subscription, the math inverts. A blocked legitimate customer on a trial costs you a $4.99 charge plus reacquisition expense. An approved fraudulent trial costs the chargeback fee ($15–25), the per-violation fine if you are inside a monitoring program, and the ratio damage that ratchets compliance pressure. The optimal block threshold for subscription sits materially lower than Stripe's default.

Trial conversions mask card testing

Card-testing fraud has a specific shape that does not exist in one-time-purchase ecommerce. A fraudster running a stolen card list against a $4.99 trial endpoint produces hundreds of low-amount, low-individual-risk transactions across overlapping but not identical fingerprints — different email aliases, residential proxy IPs, slightly varied device strings. Each transaction in isolation looks unremarkable to Stripe Radar's ML model, which evaluates one charge at a time against a global fraud distribution. The pattern only emerges in aggregate: dozens of $0.99 to $4.99 attempts per hour from BIN ranges that don't normally appear in your traffic. Default Radar does not catch this. The fix is velocity rules tuned to your specific trial price point combined with BIN-IP rules that elevate the aggregate signature into a blockable verdict.

Stored credentials enable disputes the ML cannot predict

The subscription business model creates a category of dispute Stripe Radar structurally cannot prevent: friendly fraud on renewals. Once a customer's card is on file, every subsequent renewal charge looks like a normal recurring transaction to Radar — same card, same merchant, same amount, no fraud signal in any direction. Three months later, when the customer does not recognise the renewal charge on their statement, they dispute it with the bank. The original authorization was legitimate; the dispute is post-hoc. No Radar rule can prevent it because there is nothing fraudulent to prevent at the point of charge. This is the structural reason a subscription business approaching VAMP or ECM cannot reach the exit threshold with Radar alone — the dispute layer needs Ethoca and Verifi interception, not better pre-authorization rules.

Subscription fraud geography differs from ecommerce

Stripe Radar's defaults are tuned against a global fraud distribution averaged across millions of merchants — predominantly one-time-purchase ecommerce. Subscription app fraud concentrates differently. A fitness app sees high card-testing volume from specific Southeast Asian BIN ranges. A privacy tool sees stolen-card use concentrated in countries with strong VPN demand. A dating app sees friendly-fraud disputes clustered in regions with weak in-app billing recognition. None of these patterns match the global average, which is why default Radar over-blocks legitimate traffic in some regions and under-blocks fraud in others on the same account. The operator fix is category-specific BIN-IP rules built from your own three-to-six-month chargeback data — not Stripe's defaults, not a vendor's "best practices" list.

Stripe Link bypasses CVC and AVS checks

Stripe Link improves checkout conversion by letting returning customers pay with one click, using a card stored in Stripe's network. The trade-off is that Link's authentication path skips the CVC and AVS checks that would normally fire for a new-card entry. A stolen card already saved in Link can process a charge successfully through your storefront, bypassing the rules a fresh-card checkout would trigger. Stripe's ML continues to run on Link transactions — so the risk_score remains a valid signal — but the rule patterns most subscription operators have built (block if AVS mismatch and amount over $X, for example) silently do not fire. The fix is a small set of Link-specific rules that combine :is_link_authenticated: with risk-score or amount thresholds. See section 5 below for the specific rule syntax.

The practical consequence: a subscription app running Stripe Radar's defaults is leaking 2-5% of its transactions to preventable fraud and dispute exposure that a tuned rule set would catch. At scale — and at the chargeback ratios required to stay below Mastercard ECM's 1.5% threshold or Visa VAMP's 0.30% combined threshold — that gap is the difference between compliance and acquirer-mandated remediation.

Which Five Stripe Radar Rule Categories Matter Most?

Across subscription app engagements, five rule categories account for the vast majority of effective Stripe Radar configurations. Each category is independent — a good rule set typically deploys two or three rules in each, layered to catch overlapping but distinct fraud patterns. The order below reflects priority for a fresh deployment.

1. Velocity rules tuned to subscription cadence

Velocity rules count prior activity from the same card, IP, email, or device over defined time windows. They are the single highest-leverage category for subscription apps because card testing — the dominant fraud vector on low-cost trials — is intrinsically a velocity pattern. A single $0.99 trial sign-up is invisible. Thirty $0.99 sign-ups in ten minutes from overlapping IPs are not.

The Radar attributes that drive velocity rules:

• :seconds_since_last_authorization_charge_attempt: — time since this card last attempted a charge anywhere on the Stripe network
• :total_charges_per_card_number_hourly: — total charges by this card in the last hour
• :total_charges_per_ip_address_hourly: — total charges from this IP in the last hour
• :total_charges_per_email_address_hourly: — total charges from this email in the last hour
• :total_charges_per_card_number_daily: — total charges by this card in the last 24 hours

Effective rule examples (deploy these in Review mode first):

Pattern	Rule
Same-card retries within a minute	Block if :seconds_since_last_authorization_charge_attempt: < 60
High-velocity card use	Block if :total_charges_per_card_number_hourly: > 3
Scripted sign-up flow	Block if :total_charges_per_email_address_hourly: > 5
IP-based card testing	Review if :total_charges_per_ip_address_hourly: > 5 and :amount_in_usd: < 5
Trial-funnel velocity	Review if :total_charges_per_card_number_daily: > 3 and :amount_in_usd: < 10

The trade-off in velocity rules is window selection. Tighter windows (60 seconds, hourly) catch automated card testing without blocking legitimate retry behavior. Wider windows (daily, weekly) catch slower-burn fraud patterns but generate more false positives on legitimate customers retrying a failed payment. A good starting point is hourly windows on high-volume attributes (IP, email) and per-minute windows on card-level attributes.

2. BIN-IP geographic mismatch

The BIN (Bank Identification Number, the first 6-8 digits of a card number) encodes the issuing bank and country. Comparing the card's country against the IP's country surfaces fraud in two patterns: (1) a stolen card from one country being used by a fraudster in another, and (2) legitimate users behind VPNs which themselves correlate with elevated dispute rates.

The Radar attributes for this category:

• :card_country: — ISO country code of the card's issuing country
• :ip_country: — ISO country code derived from the request IP
• :card_bin: — the first 6 digits of the card number

The naive rule — block whenever country mismatches — over-blocks. Legitimate international customers, travelers, and VPN users all trigger it. The effective version combines the mismatch with another risk signal:

Pattern	Rule
Mismatch plus elevated ML risk	Block if :card_country: != :ip_country: and :risk_score: > 60
High-risk country pair	Block if :card_country: in ('US','GB','CA','AU') and :ip_country: in ('NG','PK','VN','RU')
3DS-gate the rest	3D Secure if :card_country: != :ip_country:

The combined-signal pattern (mismatch AND elevated risk) reduces false positives by 70-90% compared to the naive version while still catching the majority of geographic fraud. The 3DS-gating alternative shifts the trade-off — instead of blocking the mismatched transactions, it requires step-up authentication, which legitimate users typically complete and fraudsters typically abandon. For subscription apps with significant international traffic, 3DS-gating is usually the better posture.

3. Risk-score override

Stripe's ML model produces a risk_score from 0 (lowest risk) to 100 (highest). The default block threshold lives around 65; below that, the transaction processes. Risk-score override rules let merchants lower the threshold for specific patterns where the business can afford stricter blocking.

The naive override — Block if :risk_score: > 50 — works but is blunt. It catches more fraud but also raises false positives on legitimate transactions that the ML model considers borderline. The effective pattern combines the score with a second signal that confirms risk:

Pattern	Rule
Score plus prepaid funding	Block if :risk_score: > 55 and :card_funding: = 'prepaid'
Score plus new card	Block if :risk_score: > 55 and :is_first_time_card_use: = true
Score plus geographic mismatch	Block if :risk_score: > 60 and :card_country: != :ip_country:
Conservative override	Review if :risk_score: > 65 and :amount_in_usd: > 50

The reason the combined-signal pattern works: the ML model considers many factors; when it returns a score of 55-65, it has seen something concerning but not decisive. Adding an independent signal (prepaid funding, first-time card, geographic mismatch) confirms the suspicion and turns a borderline case into a confident block. Override rules that operate on risk_score alone discard the model's nuance.

One anti-pattern: do not set Allow if :risk_score: < X to whitelist transactions. Allow rules disable other Radar rules for matching charges, which means a high-velocity card-testing pattern with low individual risk scores will sail through. Use Allow rules only for genuine whitelisting (specific business partners, employee test transactions) — never as a generic permissive layer.

4. Dynamic 3D Secure forcing

3D Secure (3DS) shifts the liability for fraudulent transactions from the merchant to the issuer once the cardholder authenticates. The trade-off is friction — every 3DS prompt is a checkout interruption that reduces conversion by 1-3 percentage points on the gated traffic. Blanket 3DS is therefore wrong for subscription apps; selective 3DS is the operator pattern.

Effective 3DS forcing rules target specific high-risk segments without touching the rest:

Pattern	Rule
Credit-bundle / one-time high-value purchases	3D Secure if :amount_in_usd: > 50 and :charge_type: = 'one_time'
Elevated ML risk on first card use	3D Secure if :risk_score: > 55 and :is_first_time_card_use: = true
High-risk BIN ranges	3D Secure if :card_bin: in ('457173','522980','434256', ... )
High-risk country pairs	3D Secure if :card_country: in ('NG','PK','VN','RU')
EU PSD2/SCA compliance	3D Secure if :card_country: in ('FR','DE','IT','ES','NL', ... ) and :amount_in_eur: > 30

The PSD2/SCA rule is non-negotiable for EU traffic — Strong Customer Authentication is legally required for most card-not-present transactions above €30 in the European Economic Area. The other 3DS rules are tunable based on the app's specific fraud geography. The high-risk BIN list typically gets built from analysis of past chargebacks: which BINs appeared disproportionately, and what is their issuer's fraud reputation. Stripe Radar exposes :card_bin: directly, so the BIN list can be added inline.

Subscription renewals should generally not trigger 3DS unless required by SCA. The stored credential exemption (and Strong Customer Authentication exemptions for merchant-initiated transactions) lets recurring charges process without step-up, which is critical for renewal completion rates. 3DS gating applies primarily to new-card flows, sign-up bursts, and one-time high-value purchases.

5. Stripe Link guardrails

Stripe Link is a one-click checkout that lets returning customers pay with a stored card without re-entering details. It improves conversion but introduces a subtle fraud vector: Link's authentication path can bypass CVC and AVS checks normally enforced for new-card entries. A card that would be declined through standard checkout may process successfully through Link.

For subscription apps, Link should be enabled — the conversion lift is real — but bounded with rules that prevent it from becoming a fraud bypass:

Pattern	Rule
Block Link for elevated-risk charges	Block if :is_link_authenticated: = true and :risk_score: > 55
Require 3DS for high-value Link charges	3D Secure if :is_link_authenticated: = true and :amount_in_usd: > 50
Block Link for first-time card-on-file pairings	Review if :is_link_authenticated: = true and :is_first_time_card_use: = true
Block Link for known-fraud BINs	Block if :is_link_authenticated: = true and :card_bin: in (known_bad_bins)

The first rule (Link + elevated risk) is the most important. Stripe's ML continues running even on Link transactions, so the risk_score remains a valid signal. Combining it with the Link flag catches the specific pattern where Link enables a transaction that the standard rule set would have blocked. The other rules layer additional protection for high-value or new-card scenarios.

How to Backtest a Rule Before Going Live

Every Stripe Radar rule should go through a Review-mode shakedown before being promoted to Block. The Review state flags matching charges in the Stripe Reviews queue without blocking them, giving the merchant 7-14 days of real traffic data to inspect what the rule actually catches.

The backtest workflow:

1. Deploy the rule in Review mode. In Stripe Dashboard → Radar → Rules, set the action to "Review" instead of "Block". The rule fires identically but does not interrupt the transaction.
2. Let it run against real traffic for at least 7 days. Shorter windows hide infrequent patterns. Subscription businesses with weekly cycles should let the rule run for a full week minimum; high-seasonality businesses may need 14-30 days.
3. Inspect the matched charges in the Reviews queue. Sort by date, click into each match, and categorize: (a) clear fraud, (b) clear legitimate customer, (c) ambiguous. The ratio tells you whether the rule is correctly tuned.
4. Calculate the projected impact. If 80%+ of matches are clear fraud, the rule is ready for Block. If less than 50% are clear fraud, the rule is over-broad and needs tightening (add a second signal or raise the threshold). If 50-80% are clear fraud, the rule is borderline — depends on the cost-per-false-positive in the business model.
5. Promote to Block. Once the Review window confirms correctness, change the action from "Review" to "Block". Continue monitoring the rule's hit rate in the Radar analytics view for the first 30 days post-promotion.

This workflow prevents the single most common failure mode of Radar rule deployment: shipping a rule directly to Block, having it over-fire on legitimate customers, and discovering the problem only when revenue drops or support tickets spike. Review mode is essentially free insurance against revenue-destroying false positives.

Which Two Stripe Radar Rules Almost Always False-Positive?

Across subscription app engagements, two rules show up repeatedly as misconfigured. Both look reasonable in isolation. Both consistently block legitimate revenue when deployed without modification.

1. Country mismatch without a second signal

The rule: Block if :card_country: != :ip_country:. The intuition is reasonable — fraudsters often use stolen cards from countries they're not in. The problem is everyone else who also triggers the rule: international customers traveling, expatriates paying with home-country cards, anyone behind a corporate VPN, anyone using a privacy VPN by default, anyone on mobile networks that route through neighbouring countries.

The fix: pair the mismatch with another risk signal. Block if :card_country: != :ip_country: and :risk_score: > 60 reduces false positives by 70-90% while still catching the geographic-fraud signal. Alternative: use 3DS forcing instead of Block — 3D Secure if :card_country: != :ip_country: — which gates the transaction without blocking it outright.

2. Email-velocity rules in marketing-burst businesses

The rule: Block if :total_charges_per_email_address_hourly: > 5. The intuition is also reasonable — scripted sign-up flows generate many charges from the same email rapidly. The problem: subscription apps running paid acquisition campaigns frequently produce burst traffic where a single landing page generates many legitimate sign-ups in a narrow window, and a small fraction of users — typically family members sharing an account, business accounts buying licenses, or affiliates — generate multiple legitimate sign-ups from the same email in an hour.

The fix: pair the velocity with a transaction-value signal. Block if :total_charges_per_email_address_hourly: > 5 and :amount_in_usd: < 5 isolates the low-value, high-velocity pattern characteristic of card testing while leaving legitimate higher-value bursts untouched. Alternative: route to Review for manual decisioning instead of automatic Block.

When Stripe Radar Is Not Enough — Ethoca and Verifi

Stripe Radar prevents fraud before authorization. It cannot prevent disputes after the charge has settled. For "subscription amnesia" friendly fraud — the customer who forgets they subscribed and disputes the renewal three months later — no Radar rule can help, because the original authorization was legitimate.

This is the gap that dispute interception networks fill. Two networks dominate the space:

• Ethoca (owned by Mastercard) operates the largest dispute alert network. When a Mastercard cardholder initiates a dispute through their issuing bank, Ethoca alerts the merchant before the chargeback is formally filed. The merchant has a narrow window — typically 24-72 hours — to issue a proactive refund, which prevents the dispute from counting toward the official chargeback ratio.
• Verifi / CDRN (owned by Visa) operates the equivalent network for Visa transactions. Verifi's CDRN (Cardholder Dispute Resolution Network) intercepts Visa disputes before they post.

Both networks typically intercept 30-50% of incoming disputes when integrated correctly. For a subscription app approaching the Mastercard ECM 1.5% threshold or Visa VAMP 0.30% combined threshold, that interception rate is often the difference between compliance and a formal acquirer remediation.

Integration is non-trivial. Both networks require API integration with the billing system, automated refund handling for matched alerts, and a clear policy on which disputes to deflect (proactive refund) versus which to contest at chargeback (representment). The decision logic typically lives in a dedicated dispute-management service that sits between the alert webhooks and Stripe.

Stripe Radar in the Context of ECM and VAMP Compliance

The reason this matters: subscription apps that breach Mastercard's Excessive Chargeback Merchant (ECM) thresholds or Visa's Acquirer Monitoring Program (VAMP) thresholds enter formal compliance programs with escalating fines and eventual account termination. Both programs require sustained sub-threshold performance for three consecutive calendar months to exit. Reaching that requires structural intervention across fraud rules, payment flow, and dispute interception — not just rule tuning.

A typical exit playbook layers four interventions in sequence: (1) Stripe Radar rule rebuild, covering the five categories above; (2) Ethoca and Verifi integration for dispute interception; (3) cancellation-flow redesign to route users to in-app refund instead of bank dispute; (4) formal compliance documentation submitted to the acquirer. Each addresses a different leak; missing any one extends the time-to-exit by weeks.

For deeper context on the programs themselves, see the companion guides on exiting Mastercard ECM and navigating Visa VAMP.

Frequently Asked Questions