Comment by Paul Hartness on "Why Stripe Test Mode Lies: A Solo Dev's 36-Hour Payment Infrastructure Trench Warfare"

The one that catches most people: test mode never shows you a renewal failing a month later. In production, a chunk of failed renewals are temporary declines that a later retry recovers, and the rest need the customer to update their card. Neither shows up until you've had real subscribers for a few billing cycles.

So true — billing cycle two is the real launch. Test mode teaches you how subscriptions start; production teaches you how they fail. The past_due vs canceled distinction bit me too. At first I was revoking access on the very first invoice.payment_failed, which nuked users whose bank would've approved Stripe's retry two days later. Now I keep entitlements alive through the retry window (Smart Retries + dunning emails enabled) and only flip to canceled when Stripe says the subscription is genuinely dead. And the card-update half is why I eventually added a "payment failed — update your card" screen that deep-links to the billing portal. Tiny feature, outsized churn saver.

Did you bake a grace period into your own entitlement logic, or do you let the payment provider's retry schedule handle it entirely?

Ha, "cycle two is the real launch" is going on a sticky note. past_due vs canceled is the one that bites everyone: treat past_due as "still a customer, still recoverable" and you avoid locking people out who'd have paid on the next retry. Good luck with cycle two.

Search Hashnode