Stripe subscriptions need operational guardrails

Checkout is only the first state

A subscription product looks simple from the outside: a user chooses a plan, pays, and receives access. In production, the important work starts after checkout.

Stripe can emit plan updates, pending updates, payment failures, subscription deletions, proration invoices, and renewal invoices. If those states are not modeled carefully, a customer can see the wrong plan, receive the wrong credits, or lose access unexpectedly.

The read model has to match billing reality

ZShip keeps a subscription read model in the auth service so frontend pages, API keys, and provider access checks can make fast decisions. The payment service owns Stripe orchestration and syncs the resulting state back into that read model.

That split keeps product checks simple while still respecting Stripe as the source of billing truth.

Webhook observability matters

Operators need to know whether key events have arrived. A missing invoice.paid or customer.subscription.updated event is not just a log detail; it can affect access and credits.

That is why the admin payment surface includes webhook audit visibility and key event health checks. Before charging real customers, run Stripe test mode through upgrades, downgrades, renewal, cancellation, resume, and failed payment cases.