Most failed payments aren't churn
Most failed payments aren't churn — they're an expired card or a temporary hold from the issuer. The customer wanted to pay you. The card just didn't go through.
The fix is a four-step retry sequence with branded, polite, well-timed emails. It's also the kind of thing that's annoying to build and even more annoying to keep running correctly under deploys, retries, and Stripe webhook replays.
This app does it for you, idempotent by construction.
What you get
- Stripe Connect OAuth — one-click install, no API keys to handle.
- Default 4-step dunning sequence — day 1 retry + gentle email, day 3 retry + firmer, day 7 final attempt, day 8 past_due notice. Per-merchant schedule overrides.
- Per-merchant email branding — logo, primary color, sender name, reply-to address.
- Custom email template overrides — full subject and body per stage if you want it.
- Idempotency-keyed retry ledger — append-only, replay-safe. Replayed cron tick? No-op. Mid-cycle redeploy? Safe.
- Audit log per recovery — every retry attempt logged with timestamp, status, and the idempotency key that ran it.
- Per-merchant kill switch — pause dunning for any merchant in one click.
- Subscription state tracking — active to past_due transitions are mirrored locally, not just hoped about.
- Webhook signature verification and token encryption at rest with Fernet.
Who this is for
This app is for you if:
- You run a SaaS or subscription business on Stripe Billing and lose more subscriptions to failed payments than you'd like.
- You want dunning emails customers see as coming from your brand, not a third-party tool.
- You care about idempotency and audit trails because your support team gets blamed when a customer gets two emails on the same day.
It's not for you if:
- You're not on Stripe Billing.
- You want a full revenue-recovery suite with phone calls, win-backs, and chat. We're focused on the email + retry layer specifically.