FyberPay

ISP billing and network automation, built solo.

A multi-tenant SaaS that runs an internet provider end to end: subscribers and plans, M-Pesa and Paystack billing with dunning and invoicing, and live network automation that provisions and controls customer routers.

In plain EnglishFyberPay runs the business side of internet providers: it takes the customer's mobile-money payment, issues the invoice, and then actually switches their connection on or off at the router. If the customer stops paying, the system walls their connection; when they pay, it lets them back on, automatically.

Lead engineer and operator.

FyberPay running in production — live at fyberpay.com

The exhibits

Drag to spin. Click any screenshot to inspect it full size. Every one is the live product.

FyberPay tenant dashboard — The tenant dashboard: payments landing, subscription states, network health, one screen.Drag to spin · click to inspect · 1/6

FyberPay payments ledger — The tenant dashboard: payments landing, subscription states, network health, one screen.Drag to spin · click to inspect · 1/6

The problem on file

An ISP's billing system is only honest if it ends at the network. A subscriber pays through M-Pesa on their phone; that webhook has to survive retries, land exactly once in the ledger, extend the right subscription in the right tenant, and then reach their router as a RADIUS change-of-authorization packet that actually restores their bandwidth. Miss any link and either a paying customer sits offline or a non-paying one rides free. The hard part is not any single integration. It is that money, state, and hardware all fail independently, and the system has to reconcile all three without a human watching.

What it is, in numbers

HTTP endpoints

876

payment rails, one interface

hand-written SQL migrations

263

test cases

8,200+

event listeners on a transactional outbox

services in the prod compose

The marquee piece

Every idempotency tutorial says: cache the response under the client's Idempotency-Key header. That textbook version has a flaw nobody mentions: the header is fully attacker-chosen, and the cached value is a raw response body. A key collision, or a leaked key, hands one caller another caller's response.

FyberPay's interceptor namespaces every entry by who is asking, for which tenant, for which operation, before the client's key even matters. A cache hit is only possible for the same principal replaying the same request, so cross-tenant leakage is structurally impossible even on key reuse.

That is layer one of three. Layer two is the database: mobile-money receipt numbers carry unique constraints, so a replayed webhook cannot double-credit. Layer three is a transactional outbox: side effects publish as typed events claimed with FOR UPDATE SKIP LOCKED, so a crash between recording a payment and extending a subscription cannot lose either half.

Architecture

The full loop: a payment is not done until the router says so.

The hidden ninety percent

The hidden ninety percent· what most portfolios skip

01Circuit breakers classify failures before counting them. A run of wrong-PIN declines is customer behavior, not provider outage; it must not open the breaker and bounce healthy traffic to another rail. Each gateway hand-classifies its error space, and breakers are per-tenant so one ISP's broken router cannot trip the circuit for everyone else.
02Deploys assert the schema before touching containers. Migrations once ran fire-and-forget, so a failed migration could leave a green deploy serving 500s. Now a schema-shape assertion aborts the deploy first, and only changed services are recreated; the SSTP and FreeRADIUS containers used to drop every tunnel on every deploy until they were exempted from routine restarts.
03CI parses the FreeRADIUS config against a real Postgres on every PR, because that config ships straight to production, where a stray brace is a total authentication outage for every subscriber of every tenant.
04The accounting reconciler backfills what the platform never sees. Captive-portal logins go browser to MikroTik to FreeRADIUS and never touch the API, so voucher usage and hotspot last-seen times are reconstructed from RADIUS accounting rows on a cron.
05Dunning is a state machine shared between backend and frontend (none, retrying, walled garden, suspended), with credit-aware renewal and a 30-minute reconciler that un-walls anyone whose balance has cleared through any side channel.
06Change-of-authorization is hand-rolled RADIUS over raw UDP: packet codes, MD5 authenticator, 2-second timeout, 3 retries. The alternative was an unmaintained npm package on the exact code path that disconnects a paying customer.
07Demo data is a first-class tenant state, not a flag. Sandbox tenants are excluded by every automation that iterates organizations, a rule written after seeded demo numbers received real OTP messages.

In production

01Runs the full loop for live ISP tenants: payment rails in, invoices and dunning in the middle, RADIUS and MikroTik control out.
02263 idempotent migrations, an engineer-facing changelog keyed to every promotion, and three written incident post-mortems.
03Test discipline unusual for a one-engineer codebase: roughly 8,200 cases; API test code is 81 percent the size of API production code.

Take away

A billing system is only honest if it ends at the network, so this one does.