Nothing erodes user trust faster than a billing bug. Charge someone twice and no amount of good UX buys back the confidence. So my Stripe philosophy after several integrations is simple: be aggressively boring.
Let Stripe host everything it offers to host
Stripe Checkout and the Customer Portal exist so you don't build card forms, proration logic, or cancellation flows. Use them. Custom billing UI is a liability you adopt, not a feature you ship — and Stripe's hosted pages convert better than what a small team will build anyway.
Webhooks: assume duplicates, assume disorder
Every webhook handler I write is idempotent — processing the same event twice must be harmless. Store processed event IDs, check before acting, and never trust event order: a subscription.updated can arrive before the checkout.session.completed that caused it.
Subscription state lives in my database, synced from webhooks, and the app reads only from there. Calling the Stripe API on every page load is how you turn their downtime into yours.
The checklist
One price ID per plan, no clever metadata. Test clocks for trial and renewal flows before launch. A manual 'resync from Stripe' script for the day a webhook is missed. And a log line for every billing decision the system makes — future you, debugging a refund at midnight, will be grateful.
Boring billing lets you spend the excitement budget where users actually see it.