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.
Billing truth should be read as a signal. It should not be welded directly to authentication or login enforcement.
Your application should explicitly define what happens when billing state is missing, stale, contradictory, or unavailable.
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.
- 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.
- “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.
- It does not mean unpaid users should keep premium access.
- It does not mean billing truth should be ignored.
- It does not mean every system should fail open.
- It does not mean SimpleStates enforces anything.
It means state reading and enforcement decisions should stay separate, explicit, and observable.