The SaaS Payment Recovery Playbook

Recovery starts with knowing a charge has failed. The primary signal is Stripe's invoice.payment_failed webhook, which fires within seconds of a subscription renewal failure. Subscribe to this event and route it into your recovery pipeline.

Secondary signals include customer.subscription.updated (status changes to past_due) and charge.failed (for non-subscription charges). All three should be captured and consolidated into a single 'failed charge' object in your internal system.

Within the detection phase, also capture the decline code, the customer record, the invoice amount, and any metadata you need to personalize later recovery actions. The more context you capture up front, the more sophisticated your recovery logic can be.

Once a failure is detected, the first action is almost always a retry — but not a generic one. Route the charge to a retry schedule based on the decline code.

For insufficient_funds: retry at 48 hours, 5 days, and 8 days. This catches payday cycles across biweekly and monthly pay schedules.

For processing_error and try_again_later: retry at 2 hours, 12 hours, and 24 hours. These are transient and usually succeed quickly.

For card_velocity_exceeded and withdrawal_count_limit: retry at 24 hours and 72 hours. Wait for the bank's velocity window to reset.

For generic card_declined and do_not_honor: retry at 24 hours and 4 days. These often clear with a single retry after the bank's automated flag resets.

For expired_card, stolen_card, lost_card, transaction_not_allowed: skip retries entirely. Go straight to customer email.

Cap all retry schedules at 4 attempts total. Beyond 4 attempts, the incremental recovery rate is negligible and you risk triggering Stripe account-level decline thresholds.

Retries alone recover 30-40% of failures. Adding customer emails pushes that to 60-75%. The email layer is not optional.

Email 1 (sent immediately after first failure, for hard declines, or after 24 hours of failed retries for soft declines): a warm, conversational message explaining that payment failed and providing a one-click update link. Do not use scary language. Do not threaten account suspension yet. Frame it as 'your account is still active, just a quick fix.'

Email 2 (sent 3 days after email 1, if still unresolved): a reminder that gently mentions the grace period. 'Your subscription is still active for now, but we will need updated payment info within [X days] to keep it that way.'

Email 3 (sent 7 days after email 1, final attempt): a clear but still friendly final notice. 'This is the last email before your account is paused. If you would like to reactivate, here is the link.' Use 'paused' instead of 'canceled' — it implies reversible.

Every email should be branded, mobile-optimized, and include a direct link to update payment (ideally the Stripe Customer Portal). Use the customer's first name and reference the specific product.

Configure a grace period in your Stripe subscription settings before final cancellation. 7-14 days is the standard range. Longer grace periods recover more revenue but delay the signal for voluntary churn; shorter grace periods cut off revenue faster.

During the grace period, the subscription status is past_due but access should remain active. Suspending access immediately on payment failure creates angry customers and destroys the recovery window.

At the end of the grace period, if payment still has not recovered, transition the subscription to unpaid or canceled status. This is the final formal churn event.

If the grace period expires without recovery, the subscriber has lapsed — but they are not necessarily gone forever. A structured win-back sequence recovers an additional 5-15% of lapsed subscribers.

Win-back email 1 (day 1 post-lapse): acknowledge the pause and provide a simple reactivation link. 'Your account has been paused because we could not process your payment. Everything is still saved — update your card to reactivate.'

Win-back email 2 (day 7 post-lapse): appeal to investment. 'You have [X months of history / Y saved projects / Z team members] in [Product]. We are keeping everything safe, but we would hate to see you lose it. Reactivate in 30 seconds.'

Win-back email 3 (day 21 post-lapse): offer an incentive if it makes business sense. 'We would love to have you back. Here is a free month on us.' Incentives can recover an additional 3-5% beyond the base rate.

After 30 days post-lapse, recovery probability drops to near-zero. Stop the sequence and accept the loss.

A recovery program you do not measure is a recovery program you cannot improve. Track the following metrics monthly:

Failed charge volume (count and dollars) — the size of your opportunity.

Recovery rate overall and by decline code — where your stack is working and where it is failing.

Time to recovery (median hours) — faster is better for customer experience.

Revenue recovered (dollars) — the number you report to the team and the board.

Email engagement (open, click, update-completion rates) — signal for email quality issues.

Pipe these into a dashboard and review monthly. If your overall recovery rate is below 60%, investigate. If time to recovery is above 72 hours, investigate. Continuous optimization is how recovery rates climb from 60% to 75% over time.

Implementing this playbook in-house requires significant engineering effort: webhook handlers, retry scheduling infrastructure, email templating and sending, customer portal integration, analytics dashboards, and ongoing maintenance. Realistic estimate: 2-4 weeks of initial build and 2-4 hours per month of maintenance, forever.

Revive implements this entire playbook out of the box. You connect Stripe via OAuth in 30 seconds, and every phase above — detection, retries, emails, win-back, measurement — runs automatically. At $29/mo, the ROI is immediate for any business with more than $5K MRR.

The question is not whether to run this playbook. Every SaaS on Stripe should. The question is whether to build it or buy it. For 95% of businesses, buying is the correct answer.