How Billing Gateway is built

Almost every small hotspot, WISP, guest Wi-Fi in this market runs on one of two free tools: Mikhmon, which runs on a computer at the shop, or MikroTik's own User Manager, which runs on the router itself. Both work. Both share the same structural weakness — all the state lives at the site.

That produces four failures, and operators describe all four without ever connecting them to a cause:

The tunnel is outbound. Standard Starlink is behind CGNAT, so there is no public IP to reach and no port to forward. The router dials out to the platform over WireGuard instead, which means a site needs nothing more than a working internet connection.

Only control traffic crosses it. Customer browsing leaves through the local WAN as normal. What travels over the tunnel is RADIUS, accounting and the occasional API call — so bandwidth cost stays flat regardless of how much a site sells, and so does hosting cost. That single fact is why the pricing is per router rather than per voucher in most cases.

One endpoint, three protocols. The API routes on Service-Type and Framed-Protocol, so hotspot, PPPoE and WPA2-Enterprise share the same authorization path and differ only in which action handles them and which attributes come back.

The onboarding screen then polls for the router's first heartbeat and moves the tenant to their dashboard the moment it arrives. So the technician immediately gets a definite answer instead of wondering whether it worked.

The conventional FreeRADIUS setup writes credentials and limits into radcheck and lets the server read them. That works, but it means every voucher, price change and suspension has to be synchronized into RADIUS tables and anything synchronized can potentially end up inconsistent if not done right.

Instead, FreeRADIUS calls the application at authentication time via rlm_rest, and the application answers with the correct attributes to apply.

The trade-off I made: a network round trip and an application dependency on the authentication path, in exchange for no synchronization, no inconsistencies over time, and policy decisions — including whether the tenant's own account is in good standing (evaluated against live data at the moment someone tries to connect)

FreeRADIUS reads the prefix, assigns each value to the right internal list, and the pap module validates against the password it was handed, so the request never touches radcheck at all. Missing keys are simply absent rather than requiring an empty object.

The interesting part is that Max-All-Session and Max-Total-Octets go back as control attributes, not reply attributes. FreeRADIUS intercepts them with sqlcounter, sums the session's prior usage from radacct, and sends the router only the remaining amount.

So a one-hour voucher used for forty minutes, then disconnected and reconnected, gets twenty minutes; not another hour. The router enforces a countdown it was handed; the arithmetic happens centrally, where it survives reboots, resets and replacement hardware.

That is the whole problem from the first section, closed. On a router-based system the counter lives on the thing that keeps rebooting; here the router is told the answer and never has to remember it. The billing gateway cloud does most of the work!

RADIUS is UDP, and FreeRADIUS retries when a reply is slow. A retry that activates a voucher twice, or debits an account twice, is a correctness failure people notice immediately — so activation sits behind two layers: a short-lived cache lock keyed on the voucher code, and a lockForUpdate() inside the transaction to prevent race conditions.

An already-active voucher takes a separate path: it returns the same attributes without charging again. Someone whose phone drops and reconnects is not a new sale, and should not look like one in the ledger.

Plans define what a voucher is worth — price, duration, data cap, speeds, device limit. Those values are copied onto the voucher at generation rather than read through the relationship at authentication.

It denormalizes deliberately. An operator who raises prices on Monday has already sold Sunday's printed batch at Sunday's price, and those vouchers must honour it. Editing a plan cannot retroactively change what a customer already paid for, and deleting one cannot invalidate vouchers sitting in a drawer unlike for subscriber logic.

Activation produces accounting work — a transaction, an invoice, ledger entries. None of it is needed to answer the question "can this person get online?", so it is dispatched to a queue after the transaction commits. The customer is online while the books are still being written asynchronously.

Rejections (Invalid vouchers/subscribers) return with control:Auth-Type = Reject and a reply message. It keeps the rejection reason inside the RADIUS protocol, where the captive portal can show the customer something specific — "this voucher has expired" rather than a generic failure.

One database, tenant-scoped, with a panel per tenant. The unusual part is where the tenant comes from: not a session, not a subdomain, but NAS-IP-Address on the incoming RADIUS request.

The router identifies itself, the router resolves to a tenant, and the tenant carries the billing context for the whole request. Nothing about the customer's input decides whose account is charged — which matters, because the customer's input is a six-character code typed into a captive portal by a stranger.

The platform started per-activation: a small fee deducted from a prepaid wallet each time a voucher was first used. It is a fair model. It scales with the customer's success, costs nothing on a quiet day, and the arithmetic favoured almost every tenant — most were paying meaningfully less than a flat fee would have cost them.

Some asked for the flat fee anyway. Predictability was worth more to them than being right about the price, and a number a technician can quote to a client without opening a spreadsheet is worth more than a number that is technically fairer.

It is now a fixed monthly price per router, which also matches the cost curve: hosting scales with routers and concurrent sessions, not with vouchers sold.