Thanks, Paul — that's the failure mode we see most after the first launch week.

We treat past_due / unpaid as a soft gate: keep read access to the customer's own data, block new paid actions, and flip to hard revoke only after the last Stripe retry fails (or after an explicit customer.subscription.deleted). That way a card update during the retry window doesn't strand them behind a login wall that the webhook can't reach.

Worth deciding that matrix (active / past_due / unpaid / canceled) in the same PR as the webhook handlers, not after the first dunning email lands.