Protect margin during a fraud spike with Stripe Radar
Review affected payments, backtest the block threshold, and compare a card brand monitoring program to protect solo-store margin.

A fraud spike can look like a normal week until the chargebacks arrive. In August 2026, Stripe made a Radar capability generally available that shifts the payment-blocking cutoff when a fresh fraud attack appears. For a solo operator, the durable move is a short review loop, not a new dashboard.
- Inspect the payments the threshold touched.
- Backtest the threshold before you trust it.
- Price the card brand monitoring alternative.
The default is the setting you return to
When Stripe no longer detects a fraud threat, the dynamic risk threshold reverts to your default setting. That reset makes the default the real decision. You are not tuning blocks during the attack. You are deciding what normal looks like before the threat ends. A solo operator has no team, so the default has to do the work.
Choose the setting you would keep if the store were quiet. It should reflect the margin you are willing to risk on a suspicious payment. A loose default absorbs losses that a tighter cutoff would have stopped. A tight default turns away customers who would have paid cleanly. For a solo store, the math is simple: a blocked good order costs the sale, a missed bad order costs the chargeback and the time to fight it.
Keep the default boring enough to explain after a bad week. A setting you cannot explain after a bad week is too complicated. The move is to keep real customers paying while the bad ones get stopped.
The automatic threshold blocks extra risk
When your account is under fraud pressure, Stripe Radar's dynamic risk thresholds control blocks additional elevated and high-risk payments. The control runs in the background, so you do not have to build custom rules or change settings while a threat is active. Stripe Radar lets you inspect affected payments in the dashboard and run a backtest to see how a risk control would have treated earlier payments.
Open the dashboard and make a short list of declined or blocked orders. Check each one against the customer, the address, and the order value. You are looking for patterns a solo operator can act on: repeat addresses, unusual item quantities, high-value first orders, and customers who have never completed a purchase. A blocked order that looks like a real customer gets noted. A blocked order that looks suspicious stays blocked. The review should take minutes, not hours.
Keep the pass small. A short review is better than a long audit that never happens. Catch obvious false blocks before they become refund requests and support tickets. The output is a few notes, not a new system.
The backtest tells you what the setting costs
Run the backtest. A completed run gives you a simulation result you can act on. The simulation is the part that turns a setting into a decision. Use it to compare the blocked amount against likely fraud loss and lost good orders. A simulation that shows the threshold stopped a lot of bad payments without killing real sales earns the control a place in your routine.
A spike is temporary. A control that stays tight after the attack ends can quietly cost good customers. Do not run the simulation to prove the control was perfect. Run it to learn what it costs. Too many blocked good orders call for a new default before the next spike. A threshold that missed a lot of fraud calls for a tighter default or a monitoring program.
Monitoring needs a price before it earns a place
A card brand monitoring program includes early fraud warnings in its VAMP monitoring program calculations, the card brand's monitoring calculation. Check whether you are in one, then count the hours you spend reviewing alerts, the margin lost to blocked good orders, and any program fees or penalties. The review gives you a yes or no on monitoring, based on margin and hours. Monitoring is worth it when the warnings save more margin and time than the program costs.
Stripe Radar's dynamic risk thresholds feature is limited to card payments. Other payment methods sit outside the threshold. A monitoring program adds its own warnings and reporting burden. The durable move is to keep the threshold and the review, then price the extra protection.
Keep monitoring only when the warnings change a decision you would otherwise miss. Extra work without a changed outcome is a reason to leave it out.