Discussion 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.

The zombie Pro user case is a great example of why out-of-order webhooks bite. Fetching the live subscription state by subscription_id instead of trusting the payload is a clean fix. The $2 real purchase and refund test is cheap insurance too. Congrats on launching EpicNotes.

The zombie-user bug is a great catch. Trusting webhook order feels reasonable right up until a retry lands late, and re-fetching the live subscription by ID is the kind of fix that’s only obvious after you’ve been burned. I’m a solo dev on Supabase too and haven’t wired payments into my product yet, so this goes straight into my notes. Did you also store processed event IDs to skip duplicates, or was the re-fetch enough on its own?

Thank you! And honestly — re-fetch alone WAS enough for state correctness, and that's the part I'd emphasize to anyone pre-payments: if every handler re-fetches live state by subscription ID instead of trusting the payload, processing becomes convergent. A duplicate event just re-fetches the same truth and writes the same row. Duplicates become harmless no-ops against the DB.

Where it still bites is side effects. The DB converges, but nothing stops a duplicate from re-sending the "Welcome to Pro" email, double-logging an upgrade analytics event, or burning a redundant Stripe API call. So no — I didn't originally store event IDs, and I learned the hard way that state idempotency ≠ side-effect idempotency.

What's on the backlog now: a small processed_events table (event_id PK, type, created_at, processed_at). Handler checks it first and returns 200 early on duplicates, plus an ordering guard — only apply if event.created is newer than the last applied timestamp for that subscription, so a stale retry can't overwrite fresher state under concurrent delivery.

Since you're pre-payments on Supabase, the combo I'd wire from day one: (1) verify signatures, (2) re-fetch live state, (3) event-ID store for side effects. It's maybe 30 lines of Edge Function and it deletes an entire class of 2 AM bugs. Happy to share my handler skeleton if it's useful — good luck with the wiring, it's about to get interesting!

"State idempotency != side-effect idempotency" is the line I needed. I'd have assumed the re-fetch covered everything and then wondered why someone got two welcome emails. The ordering guard on event.created is a nice touch too. And yes, I'd love the handler skeleton. Signatures, re-fetch, event-ID store from day one is going straight into my Supabase Edge Function plan. Thanks for writing it all out!

Hey Usama, just circling back on the handler skeleton. Still keen to see it whenever you get a minute, no rush. And congrats on getting EpicNotes live!

Search Hashnode

Why Stripe Test Mode Lies: A Solo Dev's 36-Hour Payment Infrastructure Trench Warfare

Responses8