Stripe's Early Fraud Warning Has Always Arrived After the Charge. Its New Radar Signal Predicts One Before.
Stripe split one fraud signal into two and made it predictive. Here's how early_fraud_warning differs from the 8-year-old EFW object it's named after.
Stripe has had a feature called Early Fraud Warning for about as long as Radar has existed. It's always worked the same way: a card issuer on the Visa or Mastercard network flags a completed charge as suspected fraud, sends a TC40 or SAFE report, and Stripe turns that into a webhook you can act on — refund it, wait and see, whatever your playbook says. The warning has always been true. It has also always arrived after the charge already happened. On September 30, 2026, Stripe shipped something with the same name attached to the opposite timing: a signal that predicts an early fraud warning before you've taken the charge at all.
That 40% is the number that makes the new signal worth paying attention to. Today, an EFW shows up as a kind of coin flip — most of the time nothing further happens, but four times in ten it escalates into a dispute you'll pay a fee on whether you win or lose. A signal that estimates that odds before the charge, rather than reporting the warning after it, moves the decision point from "how do I respond to this" to "should I take this charge in the first place."
What actually shipped on September 30
Before this release, a Radar Payment Evaluation returned exactly one fraud-related prediction: fraudulent_payment. It's been the default signal since Payment Evaluations launched, and it bundles two different bad outcomes into a single number — the odds a payment results in either a dispute with a fraudulent reason code or an early fraud warning. That's useful as a single gate, but it hides the distinction between two outcomes with very different playbooks: a dispute debits your balance immediately and starts a response clock, while an EFW is a pre-dispute signal you still have a window to act on.
The September 30 release splits that bundle into its own two signals, sitting alongside the original in the same signals hash on the Payment Evaluation object:
early_fraud_warning— the odds this specific payment will generate a real EFW from the card network laterfraudulent_dispute— the odds it becomes a dispute carrying a fraudulent reason code, with or without an EFW attachedfraudulent_payment— unchanged, still the either/or of the two above
Each one returns the same three fields: evaluated_at, a risk_level (normal, elevated, highest, not_assessed, or unknown), and a numeric score. Nothing about the response shape changed — Stripe just stopped making you infer which specific bad outcome a high fraudulent_payment score was actually warning you about.
Why the name is doing double duty
It's worth being precise about what's old and what's new here, because the naming makes it easy to conflate the two. Radar.EarlyFraudWarning — the object, the webhook, the thing most fraud teams already have wired up — hasn't changed. It's still reactive: a charge succeeds, an issuer on Visa, Mastercard, or JCB separately decides to flag it, and Stripe relays that flag to you, usually within a day or two of the original charge. The network's decision to send the report, and the issuer's separate decision whether to escalate it into a dispute, are both entirely outside Stripe's control or knowledge until they happen.
The new early_fraud_warning signal is a different kind of object answering a different kind of question. It's not Stripe relaying something an issuer told them — it's Stripe's own model estimating, from the payment's own characteristics, how likely an issuer is to send that report at all. You can request it the moment you have a tokenized payment method and a Radar Session, before you've submitted anything to a card network. That's the entire point of the rename collision: Stripe took a term everyone already understood as "the thing that arrives after a charge" and attached it to a signal designed to arrive before one.
Built for the payment Stripe never touches
The context this shipped into matters as much as the signal itself. Payment Evaluations live under Radar's multiprocessor risk signals — a track built for businesses that don't run 100% of their volume through Stripe. You can request an evaluation on a transaction regardless of which processor actually executes the charge, which is the same philosophy behind the Payment Records API we've covered before, just pointed at prediction instead of reconciliation. Where Payment Records closes the dunning blind spot for a charge that failed outside Stripe, Payment Evaluations closes the risk blind spot for a charge about to be attempted outside Stripe.
Three things are required before you can request one on a non-Stripe payment: a tokenized PaymentMethod of type card (that's the only type currently supported), a Radar Session token to collect the same advanced risk factors Stripe's own checkout flows gather, and a customer email, either on the payment method's billing details or via a Customer object. The feature itself is still in preview — Stripe is collecting signups by email rather than opening it generally — so treat anything you build against it as subject to change before it's generally available.
Source: Stripe, "A primer on machine learning for fraud detection"; Stripe, "How disputes work"; Stripe Radar product page.
That first number is the quiet reason a multiprocessor merchant gets any value from asking Stripe about a charge Stripe never processes. Ninety percent of cards moving through the Stripe network have been seen more than once, which means Stripe's models are frequently evaluating a card they have history on even when your own business has none — a vantage point a single processor's own fraud tooling can't match on a brand-new customer relationship.
| Signal | What it predicts | Existed before Sept 30? |
|---|---|---|
fraudulent_payment | Either a fraud-coded dispute or an EFW — the two outcomes combined | Yes, the only signal available |
early_fraud_warning | Specifically, that a card network issuer sends an EFW on this charge | No — added Sept 30, 2026 |
fraudulent_dispute | Specifically, that this charge ends in a dispute with a fraud reason code | No — added Sept 30, 2026 |
Radar.EarlyFraudWarning | Nothing — it reports a fraud flag an issuer already sent, after the fact | Yes, unrelated object, unchanged |
The refund math a predictive signal doesn't change
A predictive score is only useful if you know what to do with it, and Stripe's own guidance on EFWs — the reactive, post-charge kind — already lays out the math worth applying to the predictive kind too. Refunding every flagged payment regardless of size is a bad default: you'll end up refunding transactions that were never going to escalate, on top of the ones that were. Stripe's own analysis puts the optimal cutoff at charges roughly at or below your dispute fee, and calls refunding anything more than 35% above that fee generally not worth it. The timing matters just as much as the amount — a proactive refund only prevents the underlying fraud report if it's processed as a reversal within about two hours of the original capture. Refund later than that, and you can still stop a dispute from being filed, but the fraud flag itself has already gone out.
None of that changes with a predictive signal in hand. What changes is when you get to apply it. A reactive EFW gives you a window measured in hours after money has already moved. A highest risk_level on the new early_fraud_warning signal, returned before you submit the charge at all, gives you the option to never take the charge in the first place — no two-hour reversal clock, no dispute fee risk, nothing to refund because nothing was captured. That's a meaningfully better position than the best version of the reactive workflow, for the slice of traffic the model is confident about.
What this doesn't fix
A Payment Evaluation is a read, not an action. Stripe hands back three numbers and takes no position on what you do next — appropriate, since in the multiprocessor case Stripe frequently isn't the one who could block the charge even if it wanted to. You still have to decide what highest on early_fraud_warning means for your checkout flow: hold the order for manual review, decline outright, or let it through and watch it closely. And a model prediction, however good, isn't the same certainty as a card network's own fraud report — it's the thing you check before the charge, not a replacement for responding properly to the real EFW if one still arrives later, which our dispute fundamentals guide covers in more depth.
It's also worth remembering this sits one step upstream of a problem we've written about from the other direction: Stripe's newer Billing Evaluation API scores the risk that a customer won't pay a usage bill they've already run up, which only works once there's a dollar amount to evaluate. These fraud signals work earlier than that — before the first charge clears at all — which is exactly why they're the better lever for a business whose losses look like stolen-card fraud rather than a customer quietly running up a bill they never intended to pay.
For a subscription business, a fraud dispute and a voluntary cancellation end up on the same line in a sloppy churn report — a subscriber who's simply gone, revenue that stopped. They're not the same problem, and a cancellation flow was never going to catch the one that starts with a stolen card rather than a dissatisfied customer. If disputes are already showing up as a meaningful share of what you're calling churn, run the split through our churn calculator before assuming a better cancel button would have fixed it — some of that revenue was never going to be saved by anything CancelFlow does, and knowing which slice is which is the first step to actually fixing the right one.
Frequently asked questions
What's the difference between Stripe's early_fraud_warning signal and an actual Early Fraud Warning?+
An actual Early Fraud Warning (EFW) is a years-old Stripe object — Radar.EarlyFraudWarning — that fires after a charge has already succeeded, sourced from a Visa TC40 or Mastercard SAFE report the card issuer files once they flag the transaction as fraud. The new early_fraud_warning signal, added September 30, 2026 to the signals hash on a Radar Payment Evaluation, is a prediction: you request it before or during the payment lifecycle, on any processor, and Stripe's models estimate the odds this specific charge will generate a real EFW later. One is a historical fact arriving after the money moved. The other is a forecast you can act on before it does.
What signals does a Payment Evaluation return now?+
Three: fraudulent_payment, the original default signal, which bundles the odds of either a fraud-coded dispute or an early fraud warning into one number; and the two new ones added on September 30, early_fraud_warning and fraudulent_dispute, which separate that bundle into its two components. All three return the same shape — evaluated_at, risk_level (normal, elevated, highest, not_assessed, or unknown), and a numeric score — so splitting them doesn't cost you anything you already had. It just tells you which specific outcome Stripe's model thinks is more likely.
Do I need to be using multiple payment processors for this to matter?+
That's the use case Stripe built it for. Payment Evaluations are part of Radar's multiprocessor risk signals — a feature that lets you request a fraud assessment on a transaction regardless of which processor actually runs the charge. The prerequisites reflect that: a tokenized card PaymentMethod, a Radar Session token, and a customer email, none of which require the charge itself to touch Stripe. If 100% of your volume already runs through Stripe PaymentIntents, Radar is already scoring every charge automatically and this API adds less for you specifically.
Does a high-risk signal automatically block the payment?+
No. A Payment Evaluation is a read — Stripe hands back a risk assessment and takes no action on the charge itself, since in the multiprocessor case Stripe often isn't the one processing it. Deciding what to do with a highest-risk early_fraud_warning score — hold the order, decline it, route it to manual review, or let it through and refund proactively later — is still logic you write and own.
Stop losing subscribers today
One script tag. One function call. A live cancellation flow in under 10 minutes.
Start free trial →