Billing usage by hand, for customers who would rather pay by mobile money?
A metered multi-tenant platform with mobile-money billing
A multi-tenant platform that charges each customer exactly for what they use, and gets paid by card or mobile money.
Tenants and usage
Billing period: October 2026
Billed this month
USD 6,345
+12.4% on September
Metered requests
6.4 M
Collected
78%
Invoice INV-0931Settled
Water utility · T-014
USD 1,240.00
+6.8% on September- Metered requests
- 1.82 M
- Rate
- USD 0.60 per 1,000
- Storage
- 48 GB
Usage, last 6 months
Mobile moneySettled 14 Oct · reconciled daily
- Type
- Solution
- Sector
- Fintech & telecoms
- Capabilities
- Software & Platforms, Cloud & Platform
- Built for
- Businesses offering a digital service to many organizations
§1Context and challenge
Context and challenge
A business wants to offer a digital service to many organizations, each isolated from the others, priced by usage, and payable the way customers in the region actually pay: mobile money and bank transfer as well as cards.
The challenge
Build tenancy, exact usage metering, invoicing and multiple payment rails into the platform from the start, so the business can grow without manual billing or security shortcuts.
What changes
A service that onboards customers itself, bills accurately every month, reconciles payments automatically and gives operators a clear view of every account.
What we deliver
Platform architecture, tenancy and metering, billing and payment integration, and the operator console.
§2Solution and architecture
Our solution.
Each customer is a tenant with its own users, roles and limits. Every billable action is metered into an append-only usage ledger; a billing service turns usage and the customer's plan into monthly invoices that are frozen once issued. Payments arrive through card and mobile-money providers via webhooks, are reconciled against invoices, and failures trigger retries and notifications. Operators work from an admin console with its own audit trail.
Platform architecture
Platform architecture. Components:
- Customer console (interface)
- Service API (interface): Per-tenant keys
- Operator console (interface)
- Tenancy + service core (core): Roles · limits
- Usage ledger (store): Append-only
- Billing (service): Plans · invoices
- Payments (service): Card · mobile money
- Reconciliation (process)
Connections:
- Customer console to Tenancy + service core
- Service API to Tenancy + service core
- Operator console to Tenancy + service core
- Tenancy + service core to Usage ledger
- Usage ledger to Billing
- Tenancy + service core to Billing
- Billing to Payments
- Payments to Reconciliation
§2.1The interface
What your team works in.
The interface we deliver, shown here with sample data.
Tenants and usage
Billing period: October 2026
Billed this month
USD 6,345
+12.4% on September
Metered requests
6.4 M
Collected
78%
Invoice INV-0931Settled
Water utility · T-014
USD 1,240.00
+6.8% on September- Metered requests
- 1.82 M
- Rate
- USD 0.60 per 1,000
- Storage
- 48 GB
Usage, last 6 months
Mobile moneySettled 14 Oct · reconciled daily
§3Engineering decisions
The decisions that matter.
D1
Metering is a ledger
Usage is recorded as immutable events and aggregated, never edited, so every invoice line can be traced back to what happened.
D2
Invoices freeze when issued
Corrections are credits, not edits. Customers, operators and auditors all see the same history.
D3
Payment rails behind one interface
Card and mobile-money providers sit behind a common payment interface, so adding a rail doesn't touch billing logic.
D4
Tenant isolation everywhere
Every query, key and object is scoped to a tenant at the lowest layer, and tested, so one customer can never see another's data.
§4Implementation approach
Implementation approach
01
Model
Define tenants, plans, meters and the invoice lifecycle with the business.
02
Foundation
Build tenancy, keys, metering and the operator console before the first customer.
03
Billing
Add invoicing and the first payment rail; reconcile end-to-end in a sandbox.
04
Scale
Add payment rails, self-service onboarding, and load and security testing.
§5How we measure success
The measures we agree with you before we start, and report against.
- Invoices issued without manual adjustment
- Payments reconciled automatically
- Time from sign-up to first use
- Tenant-isolation test coverage
Next solution
A shared registry for public servicesHave this problem?
Tell us how it shows up in your organization. We'll show you how the solution fits your systems and what it takes to put it to work.