Revenue pillar
The Revenue canon — the strategic-level read on the four corners of revenue at $5K-$500K ARR.
Read →Failed Payment Recovery — the PorchOps playbook.
Failed payment recovery is the operational layer between Stripe's retries and a recovered customer. Stripe handles the retry attempts; you need an opinionated email layer that reads each customer's history, drafts a contextual recovery, and ships once the failure lands. This is the deepest read on PorchOps's wedge — Lou's job in detail, with the technical mechanics, the email tactics, and the audit-trail patterns.
Vertical wins when horizontal commoditizes.
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.
What the playbook guarantees.
- Drafts, then you send
Every recovery email stops in your approval queue. The drafting step carries drafts-only in the definition itself, so it holds whatever else is switched on in the workspace.
- Drafted on the webhook
The run starts when Stripe reports the failure, not on a nightly batch. It can wait behind your other running playbooks when the tier's concurrency cap is full, and the trace says so when it does.
- Opt-outs refuse at the tool
A recipient who has opted out of AI communication is refused by the draft and send tools themselves, whatever the model decided, and the refusal is not override-aware.
- No address, no draft
When the customer has no email on file, Lou stops the run and says so, rather than reconstructing an address that would look real all the way to your queue.
- Logged end to end
Classification, draft, approval and send are each an event in the audit log, tied to the run that produced them.
- No recovery rate — yet
We have not run enough real recoveries to publish one, so we don't. When there is a rate it will be measured, dated, and yours to check against your own baseline.
The decline-code buckets.
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. The recoveries in this bucket are mostly customers who update later on their own; the email is a reminder, not a save play.
Soft decline. insufficient_funds, do_not_honor, processing_error, processor_temporarily_down. The card is fine and the customer still wants to pay, so Stripe's retries plus a friendly email a few hours later is the whole play. Tone: warm, low-pressure.
Expired card. expired_card. The bucket where a customer usually just needs telling: nothing is wrong except a date. Clear walkthrough of how to update without canceling the subscription. Tone: helpful, direct.
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.
Use Stripe Smart Retries. Don't roll your own.
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. Founder voice.
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 off. Move incrementally.
Today, the founder approves every recovery email: the send step is drafts-only and the auto-send threshold below is designed but not yet wired. The rest of this section is how to move once it is, written down now because the shape of the ramp is the part worth getting right before anyone can use it.
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).
Free, automatic, paired with Lou.
Stripe's Card Account Updater service automatically updates card numbers when issuers replace them — rebranded cards, lost replacements, expired card refreshes. Coverage depends on the issuer and the network, and neither Stripe nor we publish a figure we could stand behind here.
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).
Where PorchOps fits.
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; Hank flags the paying customers who have gone quiet. Renewal tracking and expansion detection are designed and not built. The integrated operational layer — one customer graph, one tone profile, one audit log — is what most stack-of-tools approaches don't have.
What Lou actually does, step by step.
- Stripe webhook payment_intent.payment_failed fires.
- Lou pulls the customer record (Stripe Customer object) and the customer-graph history (tenure, MRR, prior failures, lifecycle stage, last 7 days of usage).
- Lou identifies the failure cause from the decline_code and maps it to one of four buckets (hard / soft / expired / generic).
- Lou checks the founder's tone profile and recent emails for voice samples.
- Lou drafts the recovery email — subject, body, payment-update link, signature.
- Draft lands in the founder's inbox via the PorchOps dashboard. Founder reviews, edits if needed, sends with one click.
- Once auto-send ships and a recovery falls within the threshold, Lou will send without founder review (a copy landing in the founder's inbox regardless). Until then this step is always the approval queue.
- Lou logs the recovery: original draft, founder edits, send timestamp, recipient, decline-code bucket, dollar amount.
- When the customer pays (or doesn't), Stripe fires payment_intent.succeeded or invoice.payment_failed again. Lou logs the outcome.
- Six weeks later, the audit log tells you which decline-code buckets recover at what rate, which tactics work, which customer segments need different copy.
Common questions about the playbook.
How many recovery emails per failure?
Two. First at 24-48 hours after initial failure (post-second-retry), second at ~7 days. Three crosses from helpful to nagging; one leaves recovery on the table.
Stripe Smart Retries or Lou?
Both. Stripe handles the retry attempts (technical layer); Lou handles the email layer (operational). They're complementary. Stripe's network-data-driven retries beat hand-tuned ones almost always; spend the time you save on the email.
When should I enable auto-send?
Not yet — auto-send is not wired for this playbook. Every recovery email holds for your approval today, and the guidance below is the design for when the threshold ships: 30 days of audit-log data first, then under $500 with 3+ months tenure and no escalations, expanding gradually on what the log shows. Never auto-send to customers with active support tickets.
What recovery rate should I expect?
We won't give you a number, because we don't have one. PorchOps has not run enough real recoveries to publish a rate, and a rate borrowed from somebody else's book of business is not a forecast of yours — the decline-code mix drives it, and yours is not theirs. Treat any vendor quoting a flat recovery rate without a bucket breakdown the same way.
Should I enable Card Account Updater?
Yes. It's free in Stripe, it runs off the card networks' own update feeds, and it pairs with Lou — when account updater succeeds, no email is needed; when it fails, Lou drafts the recovery. Enable it on day one.
What tone works for recovery emails?
Founder voice, not marketing automation. Specific ("your Pro plan, $50/mo"), short (under 120 words), and clear about the next step. Lou learns your voice from 3-5 sample emails — provide samples, edit the first few drafts, then it aligns closely.
Multi-currency?
Lou reads Stripe in multi-currency. Recovery emails render in the customer's billed currency. Decline-code mappings cover Stripe's full code library. English-only at MVP; Spanish/French/German on the roadmap once we have customer demand.
Keep going.
Lou's full profile
The Lou profile: BLUF, what Lou does, the playbook in plain English, and the founder controls.
Read →Dunning strategies cluster
What we recommend at $5K, $50K, and $500K ARR. The strategy is additive, not replacement.
Read →Expansion signals cluster
The other half of revenue: when usage is telling you to ask for more.
Read →
You did the hard part. We'll do the rest.
Get started free
We admit a new cohort of founders each week. Every account runs real inference, so we grow capacity honestly. If this week is full, leave your email and we'll write when a spot opens.
Built with ♥ by a team of five. We don't train AI or sell customer data.
PorchOps · made in california, pennsylvania, and ontario