Failed Payment Recovery — the porchops playbook.

OpenAI's April 2026 Workspace Agents launch commoditized the horizontal AI layer. Anthropic, Google, and Microsoft will follow within six months. Vertical operational layers — the back office configured for a specific job — are the moat for solo SaaS.

Revenue is the most urgent vertical. A solo founder can survive a month without an updated changelog. They cannot survive six months of failed payments going un-recovered. The MRR that walks out the door to dunning never comes back, and by month nine the founder is asking why they're not growing despite acquiring 40 new trial signups in March.

5–10% MRR leak per month is invisible to most founders until cohort retrospectives surface it. This playbook is what to do about it, and what to do exists in the operational layer — not the strategic layer.

Stripe returns roughly 30 decline codes when a payment fails. For the email layer, four buckets matter — each gets different copy, different urgency, different recovery expectations.

**Hard decline.** card_declined, fraud_suspected, lost_card, stolen_card. Non-recoverable through retry. Customer must update their card or the relationship ends. Tone: no-pressure, factual. Recovery rate: ~15% (mostly customers who update later, not who respond to the email immediately).

**Soft decline.** insufficient_funds, do_not_honor, processing_error, processor_temporarily_down. Highly recoverable via Stripe retries plus a friendly email a few hours later. Tone: warm, low-pressure. Recovery rate: ~50%.

**Expired card.** expired_card. The most-recoverable bucket. Clear walkthrough of how to update without canceling the subscription. Tone: helpful, direct. Recovery rate: ~70%+ in our data.

**Generic decline.** generic_decline, unknown decline reasons. Lowest-pressure email. Don't guess wrong about the cause — guessing decline-card-stolen when the issue is actually insufficient-funds damages the relationship.

Stripe Smart Retries is the optimal retry layer. It reads decline codes and retries on optimal cadences (immediate, 24-hour, 72-hour, 7-day) based on what's worked across the Stripe network. Rolling your own retry logic almost never beats Stripe's, and it costs you the time you should be spending on the email layer instead.

Configure Smart Retries on the Stripe dashboard once. Let it run. The retry cadence is technical; the email cadence is operational. Lou subscribes to the events Stripe fires after retries finish — that's the operational handoff.

If you're on Stripe Billing for subscriptions, the retry schedule is automatic. If you're managing payment_intents manually, Smart Retries works on those too. Either way, no DIY retry code is needed at our scale.

Two emails per failure. First at 24-48 hours after initial failure (post-second-retry); second at ~7 days. More than two damages the relationship; fewer leaves recovery on the table.

**First email.** Establishes context. "Hey, your card got declined for {bucket reason}; here's how to fix it." Includes the failure cause in plain language (not the technical decline_code), a payment-update link, and a one-line offer to help if the issue is more complex. Under 120 words. Subject line: clear and specific ("There was a problem with your latest payment" beats "Update needed").

**Second email.** A final nudge before the subscription pauses. "We'll pause your subscription on {date} unless this gets resolved." Tone: matter-of-fact, not threatening. Clear next step (the same payment-update link). Subject line: includes a date, not a vague "final notice".

Personalization matters. The recovery email that reads like a generic dunning template gets ignored; the one that references the customer's tenure, their plan, and their recent activity gets opened. Lou pulls these elements from the customer-graph view automatically — but the foundation is your tone profile, learned from your sample emails.

Default: founder approves every recovery email. Move to auto-send incrementally as audit-log data accumulates.

Recommended starting point for auto-send: under $500 with 3+ months customer tenure and no recent escalations (refunds, complaints, support tickets in the last 30 days). This catches the bulk of routine recoveries while keeping high-stakes accounts under founder review.

Expand thresholds gradually. After 60 days of clean auto-sends with positive recovery outcomes, raise the dollar threshold. After another 30 days, consider auto-send for new customers (under 3 months tenure) at lower dollar amounts. The audit log is what justifies each expansion.

Never auto-send to customers with active support tickets, recent refunds, escalation tags, or known billing disputes. The default suppression list is conservative; founders typically expand it (more customers excluded) rather than contract it (fewer customers excluded).

Stripe's Card Account Updater service automatically updates card numbers when issuers replace them — rebranded cards, lost replacements, expired card refreshes. It works for approximately 50% of card replacements network-wide.

Enable it. It's free with Stripe, it reduces hard-decline rates significantly, and it pairs with Lou cleanly: when the account updater succeeds, the next charge succeeds and no recovery email is needed; when it fails (issuer didn't enroll, customer changed banks), Lou drafts the recovery on the next failure.

The combined effect — Smart Retries + Account Updater + Lou — is the trifecta most $5K–$500K ARR SaaS need. Stripe is the rails (retries and updaters); Lou is the conversation (the email).

**Stripe Smart Retries** — free, technical retry layer. Pair with Lou. Don't replace.

**Churnkey** — SaaS-focused churn prevention with cancel-survey logic and customizable cancel flows. Strong on the cancel-flow surface; pair with Lou for the email layer. Both add value if you're shipping a polished cancel experience.

**Churn Buster** — template-driven dunning with lifecycle awareness. Solid template library; less reading of customer-graph-level history. Pair if you want template flexibility and don't need contextual drafting.

**FlyCode** — AI-driven retry strategy with bank-level decline-code intelligence. Strong on the technical retry layer; pairs with Stripe rather than replaces it. Less focused on the customer relationship after the recovery succeeds or fails.

**Stunning** — founder-friendly dunning emails with payment-update reminders. Good at the basics. Less depth on lifecycle context. Pair if you're early-stage and want a simple email layer.

**Profitwell / Paddle Studios** — analytics-heavy retention metrics, cohort analysis, and dunning. Strongest on the analytics layer; less opinionated on the operational draft-and-send.

Porchops fits in the email-and-relationship layer. Lou drafts cause-matched recovery emails after Stripe's retries; Cleo handles renewal touchpoints; Hank watches for silent churn. The integrated operational layer — one customer graph, one tone profile, one audit log — is what most stack-of-tools approaches don't have.

Lou recovered $4,200 for porchops in March 2026 across 9 failed-payment events. 312ms average drafting latency from Stripe webhook arrival. 73% founder approval rate without edits (Travis edits 27%; Lou learns from each diff). Zero false-positive recoveries — no email sent when the payment actually succeeded on retry.

The audit log for those 9 events shows the full breakdown: 4 expired-card recoveries (3 succeeded, 1 customer churned voluntarily), 3 soft-decline recoveries (all 3 succeeded), 2 hard-decline events (1 customer updated card after a week, 1 cancelled). Recovery rate by bucket: 75% expired, 100% soft, 50% hard. Overall: 78% on a small sample — well within the 35-55% range we'd expect at scale, with a positive bias from the small-sample effect.

These numbers are real. They'll change as porchops's customer base grows; the patterns won't. The audit log is what makes the patterns visible.