Stripe's Credit Group Alerts: The Churn That Never Touches a Failed Payment
Stripe's Metronome shipped credit group alerts in August 2026. Running out of prepaid AI credits isn't a payment failure — and most dunning stacks never see it.
Every involuntary churn guide, including the ones on this blog, is built around the same mental model: a card gets charged, the charge fails, dunning kicks in, and you have a retry window to fix it before the customer notices anything went wrong. That model assumes a payment attempt happened. Prepaid credit balances break the assumption entirely — the customer's access disappears without a single charge being attempted, declined, or retried, because the money already left their account when they bought the credits in the first place.
That growth number is why this stopped being a niche edge case. Prepaid credits used to be something only a handful of API-metered products worried about. Now they're the default pricing shape for a huge share of AI-native SaaS, and Stripe just shipped the first piece of infrastructure built specifically to give you visibility into a customer's balance before it hits zero — not after.
What Stripe's credit group alerts actually ship
In August 2026, Stripe's changelog for Metronome — the usage-based billing engine Stripe acquired and now sells as a first-party product — added credit group alerts. The mechanism is simple: you define a threshold on a customer's credit group balance (a specific product or credit type), and Stripe fires a notification the moment that balance crosses below it. A second, separate notification fires when the balance moves back above the threshold, so a low-balance alert that's still open tells you the customer hasn't topped up yet, and a resolved alert tells you they have.
That sounds like a small plumbing change. It isn't, for one specific reason: it's the first time this kind of alerting has been a first-class, built-in primitive rather than something every credit-billed SaaS had to hand-roll against its own usage database. Before this, "warn the customer before they run out" meant building your own balance-polling job, your own threshold logic, and your own notification pipeline — on top of whatever usage metering you'd already built. Most teams shipped the metering and the hard cutoff, and never got around to the warning.
Why this is a different churn mechanism than a failed payment
The reason credit exhaustion deserves its own category, rather than folding into your existing involuntary churn playbook, is that none of the machinery built for payment failures applies to it.
| Property | Failed card payment | Exhausted credit balance |
|---|---|---|
| What triggers it | A charge attempt is declined by the card network or issuing bank | A metered usage event would take the balance below zero |
| Stripe event fired | invoice.payment_failed | None by default — requires credit group alerts or custom metering logic |
| Retry window | Up to 28 days of Smart Retries before cancellation | None — enforcement is typically instant |
| Who has to act | Nobody, if a retry succeeds automatically | The customer, always — they must actively buy more credits |
| Where dunning email templates point | "Update your payment method" | Nothing, unless you built a separate template |
The last row is the one that costs the most revenue in practice. A failed-payment customer gets an email that tells them exactly what happened and exactly what to do about it, because you've almost certainly built that flow — it's covered in every Stripe dunning guide, including ours. A customer whose credits ran out during a Tuesday afternoon API call gets a 402 or a blocked response in whatever tool they're using, with no accompanying email, no accompanying banner, and frequently no accompanying explanation beyond whatever generic error message their client library surfaces. They don't know if it's a bug, an outage, or something they need to fix. A share of them close the tab and never come back to find out.
The market context: why this is happening to more SaaS companies now
Credit-based pricing spread fast because it solves a real problem for AI-native products: usage-based pricing gives customers budget certainty they don't get from pure per-call metering, while still letting a vendor's costs track consumption instead of seat count. Sell a block of credits upfront, meter consumption against it at different rates per feature, and both sides get something — the customer gets a spending ceiling they chose themselves, the vendor gets margin protection against a heavy user burning unlimited inference cost on a flat monthly fee.
Source: PricingSaaS 500 Index, 79 of 500 tracked B2B and AI companies on a credit model at end of 2025, up from 35 at end of 2024.
That's the adoption curve that made credit exhaustion a mainstream churn category almost overnight. It also explains why the industry's dunning tooling hasn't caught up: Stripe's Smart Retries, card-expiry reminders, and card account updater were all built for a world where the failure mode is a declined charge. A credit balance hitting zero doesn't decline anything. It just stops working, and it stopped working for a customer who was, by definition, actively using your product heavily enough to burn through a prepaid block — the opposite profile of a disengaged, about-to-churn account.
This is not the same failure mode as usage-based churn's early-warning problem
It's worth being precise about the difference between this and the usage-decline problem we've covered before in our guide to usage-based billing churn. That piece is about accounts whose consumption quietly flatlines toward zero over weeks, with no forcing event and no urgency — a slow leak that never trips an alarm because nothing dramatic happens. Credit exhaustion is the opposite shape entirely: it's a sudden, hard stop that happens to your most active accounts, the ones burning through usage fast enough to hit a wall mid-cycle. One is a quiet accounts that never rings a bell. The other is a loud event that currently rings no bell either, purely because nobody built the bell.
What a working alert ladder actually looks like
Credit group alerts give you the primitive. What you do with it is the part that determines whether it reduces churn or just generates noise. A single threshold at zero is functionally the same as having no alert — by the time it fires, the customer is already blocked. The useful pattern is a ladder of thresholds, each with a different message and a different urgency:
| Balance threshold | Message | Channel |
|---|---|---|
| 50% remaining | Informational — "here's your usage pace this cycle" | In-app only, low urgency |
| 20% remaining | Actionable — "at current pace, you'll run out around [date]" | Email + in-app banner |
| 5% remaining | Urgent — direct link to top up, one click | Email + in-app + Slack/webhook if B2B |
| 0% / exhausted | Recovery — "here's exactly what happened and how to restore access" | Email + in-app blocking screen, not a bare error |
The 20% threshold is the one doing most of the work. It's early enough to give a customer time to act before anything breaks, and it's the first point where the message can include a real number — a projected run-out date based on their actual burn rate over the current cycle — rather than a vague "you're running low" nudge that's easy to ignore. Metronome's own resolved-notification behavior matters here too: without it, you'd have to build your own logic to stop nagging a customer who already topped up, which is exactly the kind of gap that turns a helpful alert system into an annoying one nobody trusts.
The zero-balance moment deserves more than a generic error
The highest-leverage fix in the whole chain is also the cheapest to build: what the customer actually sees the instant their balance hits zero. A raw 402 response or a client-library exception is what most teams ship by default, because it's what happens if you build the metering and stop there. The alternative — a dedicated, human-readable screen or API response that says exactly what happened, exactly how much it will cost to restore access, and puts the top-up action one click away — is the difference between a customer who tops up in the next five minutes and one who assumes something's broken, opens a support ticket, or quietly looks at a competitor while they wait for a reply.
This is the same principle behind why mixed interval subscriptions need clear per-component billing visibility, and why a confusing invoice creates distrust even when the math is correct: the moment something billing-related goes wrong is the worst possible moment to hand a customer an unexplained wall. Credit exhaustion is that same moment, just triggered by a balance instead of a card.
Where this fits into your churn reporting
If you run any credit-based product on Stripe, the first thing worth checking is whether a credit-exhaustion cutoff is currently being logged anywhere as churn at all. In most setups it isn't — the subscription object stays active, the customer didn't click cancel, and the account just goes dark until someone notices the invoice stopped growing. That's the same blind spot our churn calculator is built to help you separate out: a churn rate that only counts cancellation events will systematically understate how much revenue you're actually losing to customers who got locked out and never came back, because that loss never generates a cancellation to count.
None of this is a cancellation-flow problem in the traditional sense — nobody visited a cancel page. But it's exactly the kind of moment CancelFlow's underlying philosophy is built around: the point where a customer is about to leave is the point where the right information and the right offer matter most, whether that point is a cancel button or a blocked API call. A credit-exhaustion screen that explains what happened and makes recovery trivial is doing the same job a good cancellation flow does — it's just doing it before the customer ever had to go looking for a way to leave.
Frequently asked questions
What is credit exhaustion churn?+
Credit exhaustion churn is subscriber loss that happens when a customer's prepaid usage credits (or a metered credit balance tied to a subscription) run out and their access is cut off mid-cycle. Unlike a failed card payment, no charge attempt occurs and no decline code is generated, so standard dunning systems — which are built to react to payment_failed events — never fire. The customer just hits a wall, and a meaningful share of them never come back to top up.
Why doesn't Stripe dunning catch running out of credits?+
Stripe's Smart Retries and failed-payment emails are triggered by an invoice.payment_failed event, which only fires when a card, bank transfer, or other payment method is actually charged and declined. A prepaid credit balance hitting zero isn't a charge event at all — it's a metering event inside your usage tracking (or Metronome's, if you use it as your usage engine). If you're only listening for payment failures, credit exhaustion is invisible to your recovery stack by design, not by oversight.
What does Stripe's credit group alerts feature actually do?+
Credit group alerts, shipped through Metronome (a Stripe product) in August 2026, let you create notifications on a customer's credit group balance that fire automatically when it drops below a threshold you configure per product or credit type. The alert also fires a separate resolved notification when the balance moves back above the threshold, so you can distinguish a customer who's still running low from one who already topped up.
How is running out of credits different from a card getting declined?+
A card decline is retried automatically and the customer typically keeps access during the retry window — Stripe's default gives you up to 28 days before anything lapses. A credit balance hitting zero is usually enforced instantly and locally, inside your own application logic, the moment the next metered call would take the balance negative. There's no retry window built in anywhere, because there's nothing to retry — the fix requires the customer to take an action (buy more credits) that nothing prompts them to take unless you build the prompt yourself.
Stop losing subscribers today
One script tag. One function call. A live cancellation flow in under 10 minutes.
Start free trial →