Failed payment recovery for SaaS. Deterministic retry schedule, email template, and escalation flag. No ML. No data leaves your machine.
Failed payments silently kill 3-5% of MRR every month.
Stripe retries once by default. Most SaaS founders never configure a dunning sequence. The result: customers who would have paid churn silently because their card expired or had insufficient funds.
Manual recovery is inconsistent and unscalable.
One failed payment gets a reminder. The next gets nothing. There is no system, no schedule, no escalation path. Just a founder checking Stripe dashboard once a week.
Feed it a Stripe webhook event for a failed payment. Get back a decision:
Retry the charge after N hours with a specific email template.
Stop retrying. Escalate to a human or ask for updated payment method.
Flag for human attention. Do not let it slip through.
$ echo '{"event":"invoice.payment_failed","amount":2900,"currency":"eur","customer_id":"cus_123","attempt_count":1,"failure_code":"card_declined"}' | python dunning.py
{"action": "retry", "retry_after_hours": 24, "email_template": "friendly_reminder", "escalate": false}
Deterministic rules. No model, no API call, no data leaves your machine. Same input to same output, every time.
Retry in 24h. Friendly reminder email.
Retry in 72h. Firm reminder email.
Retry in 168h. Final notice. Escalate.
No retry. Escalate to human.
No retry. Ask for updated payment method. Escalate.
No retry. No email. Escalate immediately.
Retry as scheduled. Most cards recover within 72h.
An LLM deciding who gets a retry is a black box you cannot audit.
When a decision engine says "no retry", you need to know why. A rule you can read is a rule you can trust, debug, and improve.
EUR49 one-time. Runs locally. No subscription, no cloud, no data collection.
Buy now - EUR49