The empty-wallet problem: involuntary churn in on-chain billing

The pitch for stablecoin subscriptions has a clean three-part structure: no card expiry, no issuer declines, no chargebacks. It gets repeated often enough that it's started to feel like a complete answer to the failed-payment problem.

But it isn't.

Stablecoins remove a specific set of failure modes. Yet they introduce a different one — and no one has written the recovery playbook for it.

The failed-payment problem is bigger than most merchants track

Start with the scale of what stablecoins are being asked to fix.

Recurly estimates that failed payments will cost subscription businesses more than $129 billion in 2025, a figure derived from the revenue impact of involuntary churn across the global subscription market. Involuntary churn, the kind caused by payment failures rather than cancellations, accounts for 20 to 40% of total subscription churn depending on the business model. And 62% of subscribers who hit a payment error never return: they don't cancel, they just stop being customers.

Involuntary churn isn't a billing admin issue. It's a revenue issue, and in most subscription businesses it's more fixable than voluntary churn, because the subscriber didn't choose to leave.

What stablecoins actually fix

The card-based failure stack has several layers, and stablecoins remove most of them.

Card expiry is the simplest: a subscriber's card rotates or expires, the stored credential becomes invalid, and the next charge fails. Card-updater services exist to address this, but they're imperfect and add cost. Stablecoin pull authorizations can be designed to never expire. The on-chain permission signed at signup remains valid until the subscriber revokes it or the subscription ends — and unlike a card, neither the permission nor the subscriber's wallet (self-custody or exchange) has an expiry date baked in.

Issuer declines are more complex. When a card-based recurring charge hits a subscriber's bank, the bank can decline it for dozens of reasons: fraud flags, conservative rules applied to cross-border transactions, velocity limits, or simple network errors. None of these have anything to do with the subscriber's actual funds or intent to pay. Stablecoin pull payments remove the issuing bank from the equation. The transaction settles on-chain once the payment provider's compliance checks — fraud monitoring and sanctions screening — clear on their side. There's no issuing bank to apply conservative rules to a cross-border recurring charge.

Chargebacks disappear by design. On-chain transactions are irreversible.

These are genuine improvements. For businesses with high involuntary churn driven by card-specific failure modes, stablecoin billing reduces that churn structurally, not through better dunning, but by removing the conditions that cause it.

The failure mode that replaces them

What doesn't get discussed in the stablecoin pitch: what happens when the subscriber's wallet is empty at pull time.

In card billing, a failed charge triggers a cascade of recovery options. The card network might return a soft decline code indicating a temporary hold, prompting a retry a few days later. Smart dunning systems read these codes, schedule retries at optimal times, and in some cases automatically update the card credential if a newer one is available. Well-designed dunning sequences recover 50 to 70% of failed charges without requiring any action from the subscriber. Newer "silent recovery" approaches, where AI-driven retry logic works in the background without ever contacting the subscriber, are recovering meaningful percentages of failed card payments automatically.

In on-chain stablecoin billing, most of that doesn't apply in the same way.

When a pull authorization hits a wallet with insufficient balance, the transaction fails. No decline code says "try again Thursday." No card updater fetches a fresher credential. A billing system can move the subscription to past-due and retry during a configured grace period — but unlike card retries, which can succeed without any subscriber action, a stablecoin retry only succeeds if the subscriber has added funds. The wallet has to be topped up manually before any retry can clear.

The industry has a name for it: the empty-wallet problem. The recovery playbook for it has barely been written.

Why card dunning logic doesn't map

Existing tools don't transfer because they were built for a different kind of failure.

Card dunning systems are built around the assumption that failure is probabilistic and signal-rich. A soft decline on a Tuesday might succeed on a Thursday. A card with a specific decline code is more likely to recover with a credential update than with a retry. The data from millions of transactions lets smart dunning systems make informed decisions about when to retry and which recovery path to take.

Stablecoin billing produces a different signal: binary. The wallet has enough to cover the charge or it doesn't. There's no soft-vs-hard decline logic to interpret, no credential to update. What a billing system can do is retry during a grace period — but those retries only succeed if the subscriber acts first and adds funds. That's what makes the notification strategy so critical. With card billing, smart retries do a lot of the recovery work silently. With stablecoin billing, you have to reach the subscriber before the grace period runs out.

The 72-hour window matters more than most merchants expect. Research on card dunning shows recovery emails convert best in the first three days after a failure; effectiveness drops sharply after two weeks. The same urgency applies to stablecoin billing, but the message is different. Instead of "please update your card," it's "please add funds to your wallet before your next billing attempt." That's a harder ask. It requires the subscriber to take a financial action, not just update a credential, so the notification has to be specific, timely, and useful rather than a generic dunning template.

The on-chain recovery playbook

Good stablecoin billing doesn't manage failed payments better than card billing. It prevents them. The tools shift from reactive to proactive.

The most underused lever — not yet standard across billing providers — is the pre-charge balance check. A billing system that reads on-chain wallet balances before attempting a pull can flag at-risk subscribers two or three days before the billing date. That's recoverable information: the subscriber can be notified before the failure happens rather than after. When evaluating a stablecoin billing provider, this is worth asking about specifically.

That notification has to come from the merchant. The billing provider fires the alert; the merchant writes the message and owns the channel. A plainly worded email or in-app message giving the subscriber a specific amount, a specific date, and a clear action converts. A vague warning that something might go wrong does not.

When a payment fails despite this, the subscription should move to past-due and retry automatically during a configured grace period. If the subscriber tops up their wallet in time, the subscription recovers without any additional friction. If the grace period ends without a successful retry, the subscription cancels and the merchant is notified. This flow should be configured before launch, not figured out after the first wave of failures.

Some billing implementations use on-chain spend caps: a subscriber authorizes a subscription with a defined maximum the payment provider can pull per cycle. If that cap is $50, the provider can't draw more than that regardless of what the billing system requests. For the subscriber, this is a clear, predictable boundary on what they've authorized. For the merchant, it's a useful design choice — subscribers who know exactly what they've authorized are more likely to keep their wallet funded.

What a real billing layer does differently

A billing platform built for on-chain subscriptions should give merchants visibility into the failure before it becomes churn.

Subscriber-level analytics should surface wallet balances and flag at-risk accounts ahead of billing dates. Real-time failed-payment alerts should tell merchants immediately when a pull fails, not at the end of a billing cycle. Webhook events at every state transition (active, past-due, retrying, failed, canceled) keep the merchant's own systems in sync so notification flows trigger at the right moment.

This is a higher bar than card billing platforms have historically needed to meet, because the recovery options are narrower. In card billing, smart retry logic does a lot of the work in the background. In stablecoin billing, the merchant and the platform have to do more of it before the charge runs.

The platforms that build for this (pre-charge checks, real-time visibility, subscriber-level alerts, configurable grace periods) will run lower involuntary churn rates than those that port card dunning logic into an on-chain context and assume it transfers. It doesn't.

The honest take on stablecoin subscriptions

Stablecoin subscriptions eliminate a real and significant class of payment failures. The businesses that move to on-chain billing will recover the involuntary churn driven by card expiry, issuer declines, and cross-border authorization failures. For businesses with international subscriber bases or high card-specific churn, the impact is material.

But the empty-wallet problem is real, and pretending otherwise leads to billing infrastructure that isn't built to handle it. The merchants who approach stablecoin billing with clear-eyed awareness of both what it fixes and what it introduces will build better recovery flows, set better expectations, and retain more subscribers.

The ones who repeat the "no failed payments" line without qualification will find out the hard way.

Confirmo Subscribe is built with real-time analytics, failed-payment alerts, and configurable grace periods: the tools that make on-chain recovery practical, not theoretical.

See how it handles it