Stripe Can Now Score a Customer's Risk of Not Paying Their Usage Bill. At Signup, It's Still Blind.
Stripe's new Billing Evaluation API flags usage-based customers unlikely to pay — but it has no invoice amount to evaluate until usage already exists.
Usage-based and hybrid billing solve a real problem — customers pay for what they consume instead of guessing at a seat count — but they create a problem nobody talks about until it happens to them: the bill comes after the usage, not before it. A customer on a flat subscription has to keep paying to keep using the product. A customer on a postpaid usage plan can keep consuming right up until the invoice finalizes, and if they never intended to pay it, you've already given away the thing they came for. Stripe just shipped an API that tries to catch that customer before the invoice generates, not after.
Every one of those hybrid plans has the same structural weakness: the base fee renews on schedule and looks healthy on a revenue dashboard, while the usage portion is the part that's actually at risk of never getting collected. Stripe's new Radar.BillingEvaluation object, released in preview on September 30, 2026, is built specifically for that gap — what Stripe's own docs call "pay-as-you-go abuse": a customer who racks up consumption with no intention of paying for it when the bill comes due.
What the API actually returns
You call POST /v1/radar/billing_evaluations with a payment_details object (the amount and currency of the anticipated charge, plus a tokenized payment method) and a customer_details object identifying the customer — by Customer ID, by a v2 Account ID, or with the customer's attributes passed inline if neither object exists yet. An email address is required one way or another; leave it out and the request returns a 400. Stripe responds with a single signal:
signals.non_payment_abuse.risk_level— one ofnormal,low,elevated,highest,not_assessed, orunknownsignals.non_payment_abuse.evaluated_at— a timestamp for when the assessment ran
That's the entire response. There's no score out of 100 the way Radar's general fraud scoring works, no reason codes, and critically, no way to look the evaluation back up later — the endpoint supports create only. If you want a record of which accounts got flagged and when, you're writing risk_level and evaluated_at to your own database at call time, because Stripe isn't holding that history for you. The client_device_metadata_details parameter is optional and mostly irrelevant here anyway, since Stripe notes evaluations typically run server-side against a future charge, where there's no live Radar session or browser to fingerprint in the first place.
The three moments where it actually works — and the one it doesn't
The detail that matters most for implementation is that this signal needs a dollar amount to evaluate, and at signup, you don't have one yet. Stripe's documentation lays out exactly where in the billing lifecycle the signal becomes usable, and it isn't at the start:
| Billing stage | What you pass | Recommended action on high risk |
|---|---|---|
| Signup / card saved | Nothing — no invoice amount exists yet | Use Stripe's separate free trial abuse signal instead; block the payment method setup if that flags high risk |
| Mid-cycle, usage accruing | The actual or estimated amount accrued so far | Issue an early invoice, require a prepayment, or pause the service |
| Before the next invoice finalizes | The upcoming invoice amount from invoices/upcoming | Flag the renewal for manual review or require a credit top-up before usage continues |
That first row is the catch most teams will miss on a first read of the changelog. Non-payment abuse scoring is unavailable at signup because there's nothing to score — no usage, no invoice amount, no basis for the signal. Stripe's existing free trial abuse signal already covers that moment, evaluated against the SetupIntent instead of a payment amount. The two signals are complementary, not redundant: a customer can pass trial screening cleanly, start a real paid subscription, and still get flagged two weeks later once their usage bill is big enough to be worth walking away from. A team that wired up free trial abuse protection last year and assumed non-payment risk was "handled" has a real gap sitting between those two signals, and it's exactly the gap where postpaid usage accumulates fastest.
Stripe is also direct about accuracy: the signal gets better the closer payment_details.amount is to the real invoice total. Evaluating once at the start of a billing cycle and never again is the weak version of this. The documentation's own recommendation is to re-evaluate as usage accrues and pass the latest projected amount each time — which means this isn't a webhook you wire up once, it's a polling or event-driven check you run repeatedly across the cycle, with the signal getting more trustworthy the later you call it.
Source: Business Research Insights, Usage-Based Pricing Market Report (2026)
Why "non-payment abuse" isn't the same thing as fraud
It's worth being precise about what this signal is actually measuring, because it's easy to lump it in with Radar's general fraud scoring and assume one covers the other. Our guide to Stripe's dynamic risk threshold covers Radar's standard 0–100 fraud score, which asks a narrow question: is this specific payment attempt fraudulent — a stolen card, a bot, a card-testing attack? That score exists whether you're on flat subscriptions or usage billing, and it runs at the moment a charge is attempted.
non_payment_abuse asks a completely different question: is this customer, using a card that may authorize and settle just fine, likely to simply not pay once the bill is big enough to matter? That's closer to a credit-risk judgment than a fraud judgment. A card can pass every fraud check Radar runs and still belong to someone who has no intention of paying a $400 invoice for compute they've already consumed — the card isn't stolen, the cardholder just isn't going to pay, and a traditional fraud score has no mechanism to catch that because nothing about the authorization itself looks wrong.
That distinction maps onto a failure mode we've already covered from the usage side: our piece on usage-based billing churn is about accounts whose consumption quietly flatlines to zero with no cancel event to catch it. This is close to the mirror image — accounts whose consumption is very much not at zero, running right up to the limit, with the business supplying real compute, storage, or API calls against a bill that's never going to clear. One failure mode hides because nothing happens. This one hides because, until the invoice finalizes, everything looks exactly like a normal, actively-engaged customer.
What to actually do with a flagged account
The response options Stripe recommends scale with how far into the cycle you are, and they're worth deciding on before you need them, not while a specific account is mid-dispute internally about whether to cut them off:
- Elevated risk, mid-cycle: tighten usage limits or flag the account for a human to glance at — not worth interrupting service over on its own.
- Highest risk, mid-cycle: require a credit top-up or prepayment before usage continues, or pause the service outright. This is the point where acting a cycle early is cheaper than writing off a cycle's worth of compute.
- Elevated or highest, pre-renewal: route the invoice to manual review, or require payment method re-verification before the next cycle's usage starts accruing against it.
Stripe also ships deterministic test cards for sandbox testing — pm_card_riskLevelHighest and pm_card_riskLevelElevated, along with specific card numbers that map to the same levels — so you can build and test the branching logic above without waiting for a real abusive account to show up in production first. Worth doing before this goes live, given the endpoint fails open: if you haven't tested what your code does with a not_assessed or unknown response, you'll find out the first time Stripe's evaluation service has a bad five minutes, not before.
None of this replaces ordinary dunning for payments that fail outright — a declined card after the invoice finalizes is still the same problem it's always been, retries and all. What this signal is for is the window before that: the accrued usage sitting on an account that hasn't been billed yet, where the only options are to act now or write off whatever gets consumed between now and the invoice. For any SaaS business running hybrid or usage-based pricing on Stripe, that's a real gap closing, and if the accounts you flag end up cancelling anyway, the context from this signal — not using it, never going to pay for it — belongs in your cancellation flow data as its own category, not folded into ordinary voluntary churn where it'll quietly distort every retention number downstream of it. Our churn calculator is a quick way to see what even a small share of unpaid usage is actually costing you once it's separated out from the churn you're already tracking on purpose.
Frequently asked questions
What is Stripe's Billing Evaluation API?+
It's a new Radar object, Radar.BillingEvaluation, that assesses the risk of a specific upcoming charge going unpaid before you attempt to collect it. You send customer_details and payment_details for the anticipated charge (an accrued usage amount or an upcoming invoice total), and Stripe returns a non_payment_abuse signal with a risk_level of normal, elevated, highest, low, not_assessed, or unknown, plus an evaluated_at timestamp. It shipped in preview on September 30, 2026, and requires a Radar Pro plan.
How is this different from Stripe's free trial abuse prevention?+
They cover different, non-overlapping points in the billing lifecycle. Free trial abuse prevention evaluates a customer when they save a payment method, before any usage has accrued — there's no invoice amount to assess yet, so it scores the signup itself. The Billing Evaluation API's non_payment_abuse signal only works once there's a real dollar figure to evaluate: usage accrued so far mid-cycle, or an upcoming invoice amount before it finalizes. A customer can pass trial screening cleanly and still get flagged weeks later once their usage bill is actually big enough to be worth skipping.
What happens if a Billing Evaluation request fails or times out?+
The endpoint fails open. A 4xx or 5xx response from Stripe doesn't block your billing flow — you can retry the request or proceed without the risk signal. That's the right default for not breaking billing over a dependency hiccup, but it also means a spike in evaluation failures is invisible unless you specifically log and alert on it separately from your normal error tracking.
Can I retrieve or list past Billing Evaluations?+
Not right now. The API only supports create — there's no retrieve or list endpoint for evaluations you've already run. If you want historical reporting on which accounts got flagged and when, you have to capture risk_level and evaluated_at yourself at call time and store it against the customer or invoice, rather than relying on Stripe to hold that history for you.
Stop losing subscribers today
One script tag. One function call. A live cancellation flow in under 10 minutes.
Start free trial →