Building in Public: I just shipped the foundation of a Smart Dunning Decision Engine

UPDATE

Just shipped Phase 4 of Smart Dunning in RetryFix — we can finally see why payments are failing.

After several weeks of focused work, Phase 4 is now live in production.

What we built

We added automatic capture of real Stripe decline codes on every invoice.payment_failed webhook (and during onboarding backfill). These codes are now stored in a new failure_reason column on the FailedPayment table.

This gives our rule-based engine actual signals to work with instead of guessing based only on invoice amount.

Examples:

• insufficient_funds → gentler cadence
• expired_card → more aggressive cadence

Why this was important

Even after introducing the rule-based engine in Phase 3, we still had a blind spot. A failed payment was just “failed”. Now we know the reason, which makes smarter retry timing possible.

How we implemented it (low risk by design)

• Added a nullable failure_reason column (idempotent migration)
• Pure helper extract_decline_code() that works with both Stripe SDK objects and plain dicts
• Fail-soft lookup in the webhook: temporarily switch to the merchant’s secret key, retrieve the PaymentIntent, restore the previous key
• Same pattern applied to the onboarding backfill path
• New kill switch DUNNING_CAPTURE_FAILURE_REASON (defaults to true)
• The webhook never breaks if the lookup fails — we just log it and continue with failure_reason = NULL

No changes to existing dunning schedules. Only new failed payments are affected.

Current status

• Deployed to production
• New failed payments are now populating failure_reason
• Rule-based engine (when enabled) can immediately use the new data
• Existing in-flight dunning steps are untouched

What’s next (Phase 5)

We’re already well into a weighted ScoringDecisionEngine. Instead of hard if/elif precedence, signals (value + decline code + merchant risk) are combined into a continuous score that maps to the same cadence bands.

We’re also adding full per-signal explainability so we can see exactly why a particular schedule was chosen.

Lessons learned so far

• Start simple ([1,3,7]), then iterate
• Make every change reversible and observable
• Capture real signals early, even if the decision logic isn’t using them yet
• Fail-soft is essential when touching webhooks and external APIs

This entire Smart Dunning journey started because I was tired of losing revenue on failed payments that could have been recovered with better timing and intelligence.

If you’re building a subscription SaaS, I’d love to hear how you currently handle failed payment recovery. What’s working well? What’s painful?

Happy to answer questions about the architecture, the rollout, or the journey so far.

#indiehacker #buildinpublic #SaaS #payments #dunning

————————2

For few months, RetryFix has used a very simple retry schedule: try again after 1, 3, and 7 days. It works okay, but it’s completely static. Every failed payment gets the same treatment, regardless of the amount, the failure reason, the customer’s history, or the merchant’s preferences.

I’ve always known this was a limitation. Good dunning should be contextual. A $9 failed payment probably deserves different handling than a $299 one. A temporary “insufficient funds” error is very different from a hard decline. So I’ve started replacing the hardcoded logic with something much more intelligent.

What I just shipped

I’ve completed the core foundation of a Smart Dunning Decision Engine. This is a clean, testable Python module that now sits at the heart of our retry logic.

Phase 1 created the domain models and a stable DecisionEngine protocol. Phase 2 delivered the first real implementation (DefaultDecisionEngine) that reproduces the existing [1, 3, 7] behaviour exactly. I also built a thin adapter layer so the rest of the application talks to the engine through a clean interface instead of directly to the old hardcoded loop.

The important part is what this unlocks. Because the decision logic now lives in its own isolated module (following a Ports & Adapters approach), I can start swapping in smarter implementations without touching the rest of the codebase.

The plan going forward

I’m going to build this iteratively and openly:

• Next: Rule-based decisions (different schedules based on invoice amount, failure reason, merchant plan, etc.)
• Then: Weighted scoring
• Eventually: Light machine learning (multi-armed bandit style) that learns what actually works for different segments

I’m doing this in public because I think the journey of moving from simple rules to more intelligent systems is interesting for other SaaS founders. I’ll share the architecture decisions, the trade-offs, what works, and what doesn’t.

If you’re also thinking about moving away from static retry logic, or you’ve built something similar, I’d love to hear your thoughts. What’s worked (or failed) for you when trying to make dunning smarter?

You can try the current version of RetryFix here: https://retryfix.com

More updates coming as I build out the next layers.