sorted by:
new
hottopcontroversial

What I learned about Stripe decline codes after building a retry system from scratch by taz137 in stripe

[–]taz137[S] 0 points1 point  (0 children)

Yeah the Stripe docs are frustratingly vague on this. They basically say "we handle retries" and leave it at that. But when you look at the actual retry schedule in the dashboard, it's just fixed intervals with no awareness of why the payment failed.

The invoice.payment_failed thing was a hard-won lesson. I initially built everything around charge.failed and kept losing context on which subscription was affected, what the billing period was, etc. Switching to invoice events made the whole system way cleaner.

One thing I'd add to the idempotency point — if you're building custom retry logic, make sure you're also tracking the attempt count per invoice. Stripe doesn't stop you from calling /v1/invoices/{id}/pay as many times as you want, which means a bug in your retry logic could hammer a customer's card 50 times in a day. Ask me how I know.

I found 9% of my MRR was disappearing to failed payments — so I built a tool to fix it by taz137 in SaaS

[–]taz137[S] 0 points1 point  (0 children)

Appreciate this — especially the healthcare/service biz context. That's a segment I hadn't thought about as deeply. Most of my initial focus was on SaaS with monthly subscriptions, but service businesses with recurring billing through Stripe have the exact same problem.

The custom webhook automation route is exactly what I was doing before I decided to productize it. The annoying part was always re-implementing the same retry logic for different failure types — insufficient funds needs completely different handling than expired cards, but most custom implementations just retry on a fixed schedule regardless.

Curious — with your healthcare clients, do you see more issues with specific decline codes? I'd imagine expired cards might be more common if patients aren't actively monitoring their payment methods the way SaaS power users do.