How we consolidated four products' billing onto a self-hosted core without paying a percent of every transaction

The situation

A Canadian platform operator was running four customer-facing products, each of them on its own billing-as-a-service tenant from one of the larger billing platforms in the category. The model worked for the first product. By the fourth, the cost compounded uncomfortably: each tenant took a percent of revenue, each tenant held its own slice of the customer relationship in a separate vendor database, and every cross-product question — “what does this customer pay across the portfolio?” — required code that reached into four vendor APIs and reconciled them by email address.

Three constraints made the conventional answer hard. Customers were on negotiated multi-product agreements that the vendor UIs could not represent without manual workarounds. Data residency had moved from a nice-to-have to a contractual obligation, and the billing platforms operated outside the operator’s sovereign region. And quota enforcement on the products’ hot paths needed to land in under fifty milliseconds — billing-as-a-service quota APIs added two hundred milliseconds at the median and considerably more at the tail.

The operator wanted to keep the per-product pricing logic and the per-product UI; the customer relationship, the audit trail, and the residency posture were what they wanted to bring inside.

FIG. 02 / SELF-HOSTED BILLING CORE — the customer record, the multi-product subscription, the invoice computation, and the dunning lifecycle all live inside the operator’s tenant. Each of the four products registers its own pricing tiers with the core; no per-product billing UI is maintained.

What we built

We deployed a self-hosted billing core inside the operator’s sovereign tenant and migrated each product’s subscription model onto it as a separate registered product within one billing core. Each product kept its own pricing tiers, its own connectors, and its own customer-facing UI. The core handled the things that needed to be portfolio-wide: the customer record, the multi-product subscription, the audit-grade invoice, the dunning lifecycle, and the cache-backed quota engine that answers “is this call within plan?” in under fifty milliseconds on the products’ hot paths.

The architecture deliberately avoided two failure modes we have seen on prior consolidation projects. First, the core does not own pricing logic — each product registers its own pricing tiers and its own connectors with the core, so a future product joins the platform without a schema change to the core. Second, the payment processor is plug-pluggable. The core does not lock the operator into a single processor; processors are per-product and per-customer when that’s required, and switching one out is a configuration change rather than a re-implementation.

For each product’s UI, we used the platform’s embeddable billing widget library. The plan-selection widget, the self-service portal, and the operations usage panel all call the billing core directly — no per-product billing UI to maintain, no synchronisation between vendor portals and product surfaces.

How we cut over without revenue interruption

Cutover ran in four phases over eight weeks. Phase one stood up the core and migrated historical invoice data, with a recomputation pass to verify that every prior month’s invoice could be reproduced exactly from the migrated state. Phase two brought the smallest product onto the core in shadow mode — every billing event written to both the legacy tenant and the new core, every invoice issued from both systems, with a parallel-comparison validator flagging any divergence. Phase three rolled the smallest product to production on the core only, while the other three remained on their legacy tenants. Phase four migrated the remaining three products in weekly waves; each product’s vendor tenant was decommissioned the week after its dunning lifecycle had been verified end-to-end on the core.

No customer saw a billing artefact change without a notice cycle. No invoice was misissued. The dispute-resolution workflow on legacy invoices remained operational throughout the cutover.

What this pattern is good for

This pattern works when three things are true: the operator has a multi-product portfolio (or expects to be one within twelve months), the percent-of-revenue platform fee on incumbent billing-as-a-service has crossed the operator’s “this is now a structural cost” threshold, and at least one of residency, sub-second quota enforcement, or contract-shaped pricing logic is a constraint the incumbents cannot satisfy. If the portfolio is single-product and the residency posture allows a foreign-cloud billing tenant, the consolidation does not pay back fast enough to justify the engagement.

If those three are true, the engagement typically pays back within the first year on platform-fee savings alone, and the operator owns the customer relationship for the lifetime of the platform. The pattern is not industry-specific; we have applied the same architectural shape to telecom, energy, and SaaS portfolios where the per-product billing-as-a-service stack had become the operationally limiting layer.