Software Development Tech in Kenya

Building Konnekted: Subscriber Billing Infrastructure for Kenyan WISPs

S
Samuel Kimani
May 10, 2026 3 min read

What a WISP actually needs from its software

Kenyan Wireless ISPs operate on thin margins. The technical work, subscriber management, RADIUS auth, MikroTik queues, M-Pesa billing, is mostly the same across every operator. Without a platform, each ISP either pays a consultant a recurring fee for hand-rolled scripts or builds the same thing themselves. Konnekted is the platform layer that lets ISPs focus on the network, not the billing engine.

Layer 1: FreeRADIUS for authentication and accounting

Every subscriber session is mediated by FreeRADIUS. Login attempts hit a NAS (Network Access Server, almost always a MikroTik router in this market), the NAS calls RADIUS, RADIUS calls our database, and the answer goes back. The same path carries accounting packets every few minutes so we know which subscriber is online and how much bandwidth they've consumed.We patched FreeRADIUS to read from MySQL with multi-tenant scoping baked in. Every query carries an ISP ID; one FreeRADIUS instance serves every Konnekted-hosted operator. The alternative, one RADIUS instance per ISP, adds operational toil that doesn't scale to a multi-tenant SaaS.

Layer 2: MikroTik for enforcement

RADIUS says yes or no; MikroTik enforces. When a subscriber's package changes (upgrade, downgrade, suspension), our system pushes the new queue tree and IP firewall rules to the relevant MikroTik via the RouterOS API. Same path for disconnects, when M-Pesa autopay fails three times, we push a disable to the queue and the subscriber loses internet within seconds.The RouterOS API is finicky. It's a binary protocol with stateful sessions, and routers will sometimes accept a write and silently not apply it. Every MikroTik write in Konnekted is followed by a read-back to verify, and a Horizon worker reconciles router state against expected state every five minutes for every router. Drift gets flagged and auto-healed.

Layer 3: M-Pesa for collection

Subscribers pay via STK Push (initiated automatically on renewal day) or by sending to a Paybill that maps to their account. We support both because some subscribers prefer the prompt and some prefer pushing payment on their own schedule. Both paths flow through the same reconciliation engine we use elsewhere, Konnekted is one of the products that benefits most from the C2B reconciliation infrastructure we built first for VePay.Hotspot vouchers are a separate path. We generate stateless time-limited tokens that include the package code in the payload; the hotspot login portal validates the token, registers a temporary subscriber, and expires it automatically. No subscriber record on disk for one-off vouchers, important when an ISP sells thousands of one-shilling hotspot codes a day.

The integration glue

The hardest part isn't any single layer, it's state consistency across all three. A subscriber paying via M-Pesa should be online within 30 seconds. A failed payment should result in a disconnect within five minutes. A package change should reach the router before the subscriber's next session. We model the subscriber as a state machine, and every transition is a job that updates RADIUS, MikroTik, and the billing record in a single transactional unit. When any step fails, the whole transition rolls back and an alert fires.

Related posts

May 11, 2026

How M-Pesa C2B Reconciliation Actually Fails in Production
May 11, 2026

KRA eTIMS API: A Survival Guide for Kenyan SaaS
May 09, 2026

Tikiti at Volume: How We Handle Concurrent STK Pushes at Event Start

Need software built?

Tell us what you need. We respond within 24 hours with a realistic quote.

Start Your Project Chat on WhatsApp