Stripe Dynamic Risk Threshold: The Fraud Setting Most Teams Forget to Turn Back Down
Merchants lose 13x more to false declines than fraud. Stripe's new dynamic risk threshold fixes the setting most teams tighten and never loosen.
Every fraud team has done this: a wave of card-testing hits the account, someone drops the Radar block threshold to catch it, the attack fades a few days later, and the threshold stays right where it was left. Nobody assigns "undo the emergency fraud setting" as a ticket. Three months on, that tightened threshold is still quietly blocking a slice of legitimate subscription renewals — and because a blocked charge never generates a decline email or a support ticket the way a bounced card does, almost nobody notices until the churn number is already worse.
Stripe just shipped something aimed directly at this failure mode. Dynamic risk threshold, announced in private preview for Radar for Fraud Teams in August 2026, automatically tightens the blocking threshold when it detects an active attack and automatically eases it back down once the attack signal fades. It's a small-sounding feature that fixes a specific, expensive, and almost entirely invisible cause of involuntary churn: the fraud rule that outlived the fraud.
How a risk threshold actually decides who gets charged
Stripe Radar scores every payment attempt from 0 to 100 based on card behavior, device signals, velocity, and pattern-matching against known fraud. By default, a score of 65 or higher routes a charge to manual review, and a score of 75 or higher blocks it outright, with no human in the loop. That default split — a 10-point review band, a hard block above it — is a tuned compromise between catching fraud and letting good customers through.
| Risk score | Default outcome | What it means |
|---|---|---|
| 0–64 | Approved automatically | Low risk — the large majority of both fraud-free and legitimate off-session traffic |
| 65–74 | Sent to manual review | Elevated risk — ambiguous signals that could go either way |
| 75–100 | Blocked automatically | High risk — Stripe's default cutoff for declining without review |
Source: Stripe Radar documentation, default risk score thresholds.
A fraud team can move that 75 down to, say, 50, and Radar will start blocking anything scoring in the 50–74 range that it previously let through or sent to review. During an active card-testing attack, that's exactly what you want — it catches the fraud attempt faster than waiting for enough disputes to accumulate. The problem is that "50–74" isn't a clean bucket of fraud. It's a mixed bucket of genuinely suspicious traffic and ordinary transactions that happen to carry a few risk signals for boring reasons — a renewal charged from a new IP because the customer travels for work, a card used off-session with none of the live-session signals a fresh checkout provides. Tighten the threshold, and you block both groups together. Loosen it back when the attack ends, and you stop.
Why subscription renewals sit disproportionately in the danger zone
A live checkout throws off a lot of "this is a real person" signal: an active browser session, a device fingerprint, consistent IP-to-billing-address geography, mouse and keystroke behavior in some setups. An off-session subscription renewal has almost none of that. Stripe just initiates a charge against a stored payment method with no customer present — which is precisely why SCA exemption logic exists for authentication in Europe, and it's the same structural gap that makes renewals score higher on generic risk models than an equivalent live purchase would. A charge with fewer positive signals sits closer to the threshold by default, which means any threshold change affects renewals more than it affects fresh checkouts.
Stack a card-testing attack — bots running small charges through your public checkout to validate stolen numbers — against a subscription business, and the false-decline collateral damage concentrates on exactly the transactions you can least afford to lose: recurring revenue from customers who already converted once. A rejected new signup is a lost prospect. A rejected renewal is a customer who did nothing wrong and, from their side, simply stopped being charged — until access lapses and they find out the hard way.
Source: Javelin Strategy & Research, false decline research.
Those numbers are from one-off retail purchases, where the customer at least knows a decline happened and can try a different card. A subscription false decline is worse in one specific way: on a stored, off-session payment method, there's frequently no moment where the customer sees anything decline at all. If Radar blocks the charge before it ever hits the card network, there's no bank-side message, no card_declined event for your dunning stack to catch, and no email trigger — the subscription just goes inactive. Everything we've written about Stripe dunning and involuntary churn recovery assumes a failed charge to react to. A Radar block upstream of the charge attempt doesn't leave one.
Static thresholds vs. dynamic risk threshold
| Static threshold (current default) | Dynamic risk threshold (preview) | |
|---|---|---|
| During a fraud attack | A human manually lowers the block threshold | Radar raises sensitivity automatically based on detected attack signals |
| After the attack ends | Threshold stays wherever it was left until someone manually resets it | Radar automatically relaxes the threshold back down as attack signals fade |
| Who owns the reset | Whoever remembers — often nobody, on a rotating fraud/support team | Nobody — it's the point of the feature |
| Failure mode if missed | Legitimate renewals keep getting blocked indefinitely | Threshold self-corrects without a manual step |
The feature is currently in private preview for Stripe accounts on Radar for Fraud Teams, requestable through Stripe. It doesn't change how Radar scores a transaction — it changes who's responsible for deciding when the threshold should move, and takes the "forgot to loosen it back" failure mode out of human hands entirely. That matters because the failure isn't a one-time event you can catch with a postmortem. It's a setting that silently keeps producing the same wrong outcome, indefinitely, until someone happens to audit it.
Finding out if this has already been costing you subscribers
You don't need the preview to check whether a stale threshold is already a problem. Three things are worth pulling this week:
- Radar's blocked-payment count over time, in the Dashboard. Look for a step change — a sudden jump in blocks that lines up with a known attack, followed by a plateau at the new, higher level instead of a return to baseline. A plateau is the signature of a threshold that got tightened and never reset.
- Blocked volume against actual dispute rate. If your block rate is running well above what your chargeback rate would justify, the threshold is almost certainly catching more than fraud. Fraud that actually reaches a dispute is your ground truth; blocks that far exceed it are false-positive territory.
- Subscriptions that went inactive with no decline reason logged. Cross-reference cancelled or past-due subscriptions against your webhook log for
invoice.payment_failed. A gap — subscriptions that stopped without ever generating a failed-payment event — points at a charge that was blocked before Stripe ever attempted it, which is exactly what a Radar block looks like from the merchant's side.
If any of those checks turn something up, the fix in the meantime — before dynamic risk threshold rolls out more broadly — is procedural rather than technical: whenever someone tightens a Radar threshold in response to an attack, put a calendar reminder on the same day to review and reset it, owned by a specific person, not "the team." It's a low-effort fix for a problem that otherwise has no natural expiration date.
The narrower fix: scope rules to the attack, not the whole account
The other lever, available today without any preview access, is using Radar's custom rules and rule simulator to write conditions narrow enough to catch the specific attack pattern instead of moving the global threshold. A card-testing attack usually has a signature — a burst of small-value charges, a cluster of cards from sequential BIN ranges, an unusual concentration from one IP range or device fingerprint. A rule written against that signature (block charges under $2 from a specific BIN range in a rolling ten-minute window, for instance) can stop the attack without touching the score threshold that every renewal, testing-related or not, gets evaluated against. Run any new rule through Radar's simulator against recent transaction history before activating it, specifically checking how many known-good renewal payments it would have caught — that number should be as close to zero as you can get it before the rule goes live.
Global threshold changes are the blunt instrument. They're fast to apply under pressure, which is exactly why they're the default reach during an active attack, and exactly why they're the ones most likely to get left in place afterward. A scoped rule takes a few more minutes to write correctly but doesn't carry the same open-ended risk of quietly discarding good customers for months.
Where this fits against the rest of your involuntary churn stack
We've covered card account updater for stale card numbers and SCA authentication failures for European renewals — both are failures on the customer's side of the transaction that your own fraud settings have nothing to do with. A Radar false decline is the opposite case: the card is fine, the customer did nothing unusual, and the block originated entirely from a setting your own team changed and forgot about. It belongs on its own line in your gross revenue retention reporting, separate from card declines and separate from authentication failures, because the fix isn't a dunning email or a portal link — it's a rule review that has nothing to do with the customer at all.
This is also, structurally, the involuntary churn category that a cancellation flow can never touch. A subscriber blocked by an overtightened fraud rule never sees a cancel button — they see nothing, until access disappears and they either shrug and move on or file a confused support ticket asking why they were charged, then weren't. CancelFlow is built for the moment someone consciously decides to leave and gives you a shot at changing their mind. A false decline never reaches that moment, which is exactly why it's worth auditing separately from the rest of your churn stack rather than assuming your existing recovery tools already have it covered.
Frequently asked questions
What is a false decline?+
A false decline is a legitimate, well-funded payment that gets blocked because a fraud system misreads it as risky. Unlike a card decline from an issuing bank, the customer did nothing wrong and the card is fine — the merchant's own risk rules stopped a good transaction from going through. On a subscription, this shows up as a renewal that never even reaches the card network.
What is Stripe's dynamic risk threshold?+
Dynamic risk threshold is a Radar for Fraud Teams feature, announced in private preview in August 2026, that automatically tightens your payment-blocking threshold when Radar detects an active fraud attack and automatically relaxes it back down once the attack subsides. It replaces the manual process of a team lowering the threshold during an attack and then having to remember to raise it again afterward.
What is Stripe Radar's default risk score threshold?+
Stripe Radar scores every payment 0–100. By default, a score of 65 or above sends a charge to manual review, and a score of 75 or above blocks it automatically. Lowering the block threshold below 75 catches more fraud but also blocks a wider band of legitimate charges that happen to score in that range — off-session subscription renewals are disproportionately represented in that band.
How do I know if false declines are churning my subscribers?+
Pull your Radar-blocked and manually-reviewed payment counts from the Stripe Dashboard and compare them against your chargeback rate over the same window. A block rate that is high relative to your actual dispute rate, especially one that stayed elevated well past a known attack date, is the signature of a threshold that never got reset. Cross-reference against subscriptions that went inactive with no card_declined or authentication_required reason on file — those are renewals that never reached the card network at all.
Stop losing subscribers today
One script tag. One function call. A live cancellation flow in under 10 minutes.
Start free trial →