Good list. The one I see most often that does not get talked about enough: mishandling customer.subscription.updated events during plan changes.

When a customer upgrades or downgrades mid-cycle, Stripe fires customer.subscription.updated with the new plan details. But the invoice for the prorated amount comes separately as invoice.paid. If your webhook handler updates entitlements on subscription.updated but the prorated payment fails (card declined, insufficient funds), the user gets the upgraded plan without actually paying for it. The fix is to gate entitlement changes on successful payment confirmation, not on subscription status changes alone.

Another one specific to anyone doing attribution or referral tracking through Stripe: client_reference_id in Checkout Sessions is your friend, but it disappears if you only listen to invoice.paid without linking it back to the original checkout.session.completed event. If you need to know WHO referred a customer (for affiliate commissions, partner tracking, etc.), you have to capture that reference at checkout completion and store it, because later subscription events will not carry it.

The idempotency point is huge too. Stripe explicitly says they may send the same event more than once. I have seen production systems double-credit accounts or double-count referred customers because the handler did not check if it already processed a given event ID.

The "trusting the success redirect" one is the most dangerous because it feels correct. The Checkout session has a success_url, the user lands on /thank-you, the app grants access. Then someone bookmarks that URL or hits it directly and gets Pro for free. Seen it happen in production.

The fix people reach for first -- checking the Checkout session status in the success page handler -- is better but still fragile. If your webhook handler and your success-page handler both write subscription state, you now have two writers racing. The webhook might arrive before the redirect, or 30 seconds after, or (if your endpoint was down) not until the next retry window. If the success-page handler already wrote "active" and the webhook handler also writes "active," fine. But if either one also sets metadata, plan details, or trial end dates, you get inconsistent state depending on which one won last.

One pattern that's held up well: the success page handler does NOT write state. It polls or waits for the webhook-written state to appear (with a short timeout and a "we're activating your account" spinner). The webhook is the single writer. If the webhook never arrives within ~30 seconds, you show a "your payment is confirmed, we're finishing setup" message and let the webhook handler do the actual provisioning whenever it lands. One source of truth, no race.

The idempotency point is also underrated. Stripe retries with the same event ID, but most handlers don't check whether they already processed that ID. On a slow endpoint, you can get the same invoice.paid event three times and create three billing records.