Billing Should Not Block Login
Billing systems produce state: subscription status, invoice state, payment events, and plan mappings.
Login is an enforcement path. When billing state directly controls login, ordinary billing delays can become user-facing lockouts.
Common failure mode
Teams often build this shape:
- Stripe webhook arrives
- Database updates a paid boolean
- Login middleware checks paid
- If false, login is blocked
This looks clean. It is brittle. It converts stale billing state into customer lockout.
Why this breaks
- Webhook delays, retries, or provider outages
- Clock skew and event ordering issues
- Transient database failures
- Partial deploys or migration windows
- Mismatch between upstream billing truth and local cached state
These are normal operational events. If billing state is directly connected to login enforcement, normal events become access failures.
Signal-only framing
- “Plan is Standard” is a fact.
- “Subscription is past_due” is a fact.
- “User may access feature X” is enforcement.
- “User may log in” is enforcement.
Login, paid feature access, account suspension, and degraded mode are different enforcement surfaces. Your application owns those choices.