THE BILLING PLATFORM
Architecture
How the billing platform works — three areas, six processes, shared state, and the event pipeline that connects them.
The platform processes subscription changes, invoice finalizations, and payment attempts across three functional areas. Data flows through six processes forming a lifecycle from customer action to revenue. Five shared database tables sit at the gravitational center — every area reaches inward to read and mutate this shared state.
Six core processes form a lifecycle from customer action to revenue. Three interface layers, four data stores, and the data flows that connect them.
Three billing areas form a dependency triangle bound by shared mutable state. Each is a distinct failure domain with different integration mechanisms.
Five database tables at the gravitational center. Every area reaches inward — coupling is in the data, not the code paths.
The customer-facing surface — 79 touchpoints across Dashboard, iAPI Gateway, and NinjaPanel. Sees billing state without understanding it.
Every subscription mutation flows through a unified 4-stage pipeline. 126 touchpoints across HTTP, Twirp, gRPC, Temporal, and cron.
The event compression pipeline — 196 Stripe event types compress through a single surface before fanning out to 5 subsystems.
The only payment method using a completely separate processor. Five lifecycle stages — each diverges from the Stripe path. Where it breaks and why.
Three areas, six processes, five shared data stores. The architecture section maps the full system — from the high-level lifecycle down to individual area internals and the shared state that binds them together.