Paul Hartness

The point that a hold next to a real charge looks identical on a banking app is the one most people miss, so starting with the Payments status column is the right first move. One thing I'd add to fixing a real duplicate: when you cancel the extra subscription immediately, turn off proration on the cancel. Otherwise Stripe can leave a credit or a small final invoice on that customer, and the next email you get is "why is there another charge from you."

Using the invoice ID as the primary key is a neat way to make duplicate invoice.paid events harmless. One path I'd add: a renewal whose payment fails. No invoice.paid means no new credit row, which is correct, but the user just wakes up with zero credits and no idea why, so a short note on invoice.payment_failed with a card-update link saves you a confused support email.

Good call on not trusting the success page, since "cards get declined three days later" is exactly where tutorials stop. The step I'd add after storing past_due is telling the customer: on invoice.payment_failed, send an email with a link to update the card, then let access follow the status when Stripe finishes retrying.

Glad it helps. Future you will thank you the first time a support ticket says "my card is fine".

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.

Yes, keep the raw decline_code next to a simpler category. The category picks the reply (wait and retry vs ask for a new card), and the raw code is what you need later when a pattern looks off, like a run of do_not_honor from one bank. If you only keep the category, you can't re-sort old failures when your rules change.

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.

Love this for the 40-100 customer stage. One column I'd add: the last decline reason. When someone asks "did my card go through?", knowing it was insufficient funds versus an expired card tells you straight away whether to say "we'll retry" or "please update your card".

Good point on learning the provider's retry schedule before writing your own. Cards on Stripe have the same trap: if you add retries on top of the built-in ones, you can end up hitting the customer twice in a day. The "pending" message advice applies everywhere too. Telling the customer before the next attempt saves a lot of surprised support emails.