The Subscription Graveyard Starts With a Failed Payment

Somewhere in your customer base, a credit card is about to expire. Another customer's payment will decline because they hit their limit buying holiday gifts. A third will fail because their bank's fraud detection flagged an unfamiliar charge. These aren't edge cases; according to Recurly's analysis of 1,200 subscription businesses, 7.2% of subscribers are at risk each month due to failed payments.

The difference between recovering that revenue and losing those customers comes down to how you handle the failure. Aggressive dunning annoys customers, while passive approaches let subscriptions lapse silently. The right strategy balances persistence with respect.

Why Payments Fail

Understanding the causes of payment failure helps you respond appropriately. Not all failures are equal, and treating them the same leads to suboptimal recovery.

Expired cards are a leading cause of failures. Credit cards have fixed expiration dates, and customers forget to update their payment details before the old card expires. These failures are entirely recoverable once the customer updates their card.

Insufficient funds cause another significant portion of failures. The customer's card is valid but declined because they've reached their credit limit or overdraft limit. These failures often resolve on their own when the customer pays down their balance. Retrying a few days later frequently succeeds.

Fraud prevention triggers account for many unexplained declines. Banks flag charges that deviate from a customer's typical spending pattern, and a legitimate subscription renewal sometimes gets caught in the filter. This is especially common for international transactions, first-time charges from a new vendor, or any change in price—switching from monthly to annual billing often triggers fraud checks because the charge amount jumps significantly. Customer verification often clears these blocks.

Lost or stolen cards require full payment method replacement. The customer may not even realise their card was compromised until they see the failed charge notification. These take longer to resolve but are still recoverable with clear communication.

Genuine account problems, where customers have left your service without canceling, or where the underlying account is closed, represent a small portion of failures. These are rarely recoverable through technical means.

The Dunning Sequence

Dunning is the process of attempting to collect overdue payments. The term sounds aggressive, but effective dunning is actually about customer communication rather than debt collection. You're reminding customers about a payment they likely intended to make.

A typical dunning sequence combines automatic payment retries with customer notifications. The payment processor retries the charge on a schedule, while your system sends emails that explain the situation and guide customers to resolution.

The retry schedule matters. Retrying immediately after a failure rarely works; whatever caused the decline probably hasn't changed in the last few seconds. Retrying the next day is better. Retrying in three to five days is often optimal for insufficient funds cases, giving customers time to pay down their balance. Most payment processors offer "smart retries" that schedule attempts based on historical success patterns for similar decline codes.

The communication cadence runs parallel to retries. A first email immediately after failure alerts the customer to the problem. A second email a few days later reminds them if the issue persists. A final warning before service interruption gives urgency without being premature. Each email should be clear about what happened, why it matters, and how to fix it.

Crafting Effective Recovery Emails

The emails you send during dunning determine whether customers fix the problem or ignore it until their access is revoked. Effective recovery emails share several characteristics.

Lead with what happened, not with blame. "Your payment didn't go through" is better than "Your card was declined." The first framing treats the failure as a glitch to resolve; the second implies the customer did something wrong.

Explain the consequence clearly but without alarm. "If we can't process payment by [date], your access to [product] will be paused" is informative. "YOUR ACCOUNT WILL BE SUSPENDED" is aggressive and off-putting.

Make resolution easy. Include a direct link to update payment methods. Don't make customers log in and navigate to find billing settings. The fewer steps between reading the email and fixing the problem, the higher your recovery rate.

Provide context customers might need. If the charge amount is included, they can verify it matches their expectations. If your company name shows differently on statements than in the product, mention that so customers don't mistake your charge for fraud.

Consider timing and frequency carefully. Sending three emails in three days feels like harassment. Sending one email and then cutting off access feels abrupt. Space communications appropriately and increase urgency gradually.

Grace Periods and Service Continuity

What happens to a customer's access while payment is failing? The answer involves tradeoffs between revenue protection and customer experience.

Immediate suspension is the strictest approach: the moment payment fails, access is revoked. This protects against extended free usage but creates a harsh experience for customers who simply forgot to update an expired card. A legitimate customer locked out of your product at a critical moment will be frustrated, regardless of whose fault the payment failure was.

Grace periods provide time for recovery without service interruption. During the grace period, the customer retains access while retries and dunning proceed. A typical grace period is seven to fourteen days, long enough for most failures to resolve but short enough to limit exposure.

Some products implement degraded access during grace periods rather than full access. Core functionality works, but premium features are restricted. This reminds customers something is wrong without completely blocking their work.

The right approach depends on your product and customer base. Products with high switching costs can be stricter; customers will fix payment issues to maintain access to irreplaceable data or workflows. Products with easy alternatives need gentler handling; frustrated customers will simply leave.

Revenue Recovery Metrics

Tracking payment recovery helps you understand how your dunning process performs and where to focus improvements.

Initial failure rate measures how many payment attempts fail on first try. This metric is largely outside your control, driven by your customer base's payment method characteristics. But watching trends can reveal problems: a sudden spike might indicate an issue with your payment processor configuration.

Recovery rate measures what percentage of failed payments eventually succeed. Recurly's research found that automated decline management saved 69.4% of subscribers at risk of involuntary churn. If your recovery rate falls significantly below this benchmark, your dunning process needs attention.

Time to recovery tracks how long it takes to resolve payment failures. Faster is better, both for cash flow and customer experience. If most recoveries happen in the first three days, extending your retry period to three weeks isn't adding value.

Final churn rate from payment failure shows how many customers you ultimately lose due to payment issues rather than intentional cancellation. This is the metric dunning aims to minimise. Some payment churn is inevitable, but high rates suggest process problems.

Proactive Prevention

The best dunning strategy is preventing failures in the first place. Several practices reduce the volume of failures you need to handle.

Card account updater services automatically refresh stored card details when customers receive new cards. Nearly 30% of payment cards in the U.S. are reissued each year due to expiration, loss, or fraud—account updaters capture these changes in the background, preventing failures before they happen.

Expiration warnings alert customers before their card expires. A simple email a month before expiration, prompting them to update their payment method, prevents many failures before they happen.

Retry timing based on card type can improve recovery rates. Corporate cards are more likely to succeed on weekdays when finance teams are active. Consumer cards may do better after typical paydays. Smart retry configurations apply these patterns automatically, scheduling attempts when similar cards historically succeed.

Clear charge descriptions prevent fraud flags. If your statement descriptor is "CORP12345" instead of your company name, customers and their banks are more likely to flag charges as suspicious. Use descriptors that customers will recognise.

Building the Recovery Stack

Implementing payment recovery involves coordination between your payment processor, your application, and your communication systems.

Your payment processor handles retries and provides webhook notifications when payments fail or succeed. Configure retry schedules appropriately and ensure you're receiving failure webhooks reliably. Most processors offer detailed decline codes that help you understand why payments failed.

Your application needs to track subscription status and respond to payment events. When a payment fails, the subscription enters a grace period. When retries succeed, it returns to normal. When the grace period expires without recovery, access is suspended.

Your communication system sends emails based on payment events. This might be built into your application, handled by your billing platform, or managed through a dedicated email service. Whichever approach, ensure emails are triggered reliably and track engagement metrics.

The integration between these components needs to be robust. A missed webhook or failed email can mean lost revenue. Test failure scenarios explicitly, not just happy paths.

---

When you're using Salable with Stripe, payment recovery runs automatically. Stripe's smart retry logic handles retry scheduling, while Salable manages grace periods and subscription state transitions. You configure the rules; the system executes them. To see how failed payments flow through the stack, check out the subscription management documentation.