Discussion on "Don't open Stripe for every support email. Keep three billing columns on the user."

Praneet Brar · 2026-10-14T07:10:39.129Z

Say you have 40 paying customers. Not huge, but enough that billing emails start showing up every week. "What plan am I on?" "When do I renew?" "Did my card go through, the app says something weird."

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

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.

Makes sense, the raw code is what saves you when a rule changes later. I'll keep decline_code in its own column next to the simple category, thanks for spelling that out.

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

Small change, big time saver. We ended up with plan, last payment and status too. Did you sync them on webhook or on a schedule?

webhook for the normal path, plus a nightly job that re-reads the subscription and fixes anything that drifted, since a missed webhook during a deploy is the usual way those columns go stale. and yeah current_period_end is probably the next column i'd add, "when do i renew" is the question that still sends you to the dashboard. how often does your nightly check actually catch something?

Not often, maybe a handful of rows a month, and almost always right after a deploy or a webhook endpoint timeout. That rarity is the point though, since those few are exactly the users who would email asking why their plan looks wrong. Logging each fix it makes also tells you when the webhook path itself needs attention.

logging each fix is a good idea, a few rows after every deploy would show you the webhook path is the weak spot. do you get pinged when the nightly job fixes more rows than usual?

The point about storing your own plan name instead of the Stripe price id is underrated. It's what makes a later price change or a yearly plan a non-event instead of a grep through the codebase. One thing I'd add: keep a current_period_end column too, since "when do I renew?" is probably the most common billing email and it saves the one remaining trip to the dashboard.

Good call on current_period_end. 'When do I renew?' is probably the most common billing question, and that column answers it without opening Stripe.

Search Hashnode

Don't open Stripe for every support email. Keep three billing columns on the user.

Responses11