How MikroTik and M-Pesa billing fit together for a Kenyan ISP

The four systems that must agree

A reliable billing workflow is not a direct cable between M-Pesa and a router. It is a controlled sequence across a payment gateway, the ISP customer database, an authorization service, and MikroTik RouterOS. Each system has a distinct responsibility, and treating those responsibilities separately makes failures easier to recover.

1. 1. Payment gateway: accepts the payment request and sends a signed or otherwise verifiable result to your server.
2. 2. Billing platform: matches the reference to a customer, invoice, or voucher and records the transaction idempotently.
3. 3. Access service: decides whether the subscriber is entitled to connect based on validated customer and package state.
4. 4. Router control: applies the approved profile, secret, session, or hotspot action without exposing device credentials to the browser.

A payment flow that can survive retries

Gateway callbacks may arrive late, more than once, or in a different order from the customer's browser response. The callback—not the success screen—should be the authoritative payment signal. Store the external transaction identifier, validate the amount and account reference, and make repeated callbacks safe by refusing to create duplicate financial records.

Only after the transaction is accepted should the system update the invoice or voucher and request an access change. If RouterOS is temporarily unavailable, keep the payment successful and queue or surface the access action for retry. Never make a customer's money disappear merely because a router call timed out.

PPPoE and hotspot need different activation rules

PPPoE usually maps a known subscriber to a package, credentials, profile, address pool, and renewal state. Hotspot purchases more often create or activate short-lived access such as a voucher. Both can share payment infrastructure, but they should not share ambiguous references or lifecycle rules.

Security boundaries that matter

Keep gateway secrets, RouterOS credentials, and RADIUS database access on server-side services. Validate request bodies at every public API boundary, restrict callbacks by the verification methods the gateway provides, and redact credentials and personal details from logs. Organization and staff permissions should be checked again on the server even when the interface hides an action.

A staged rollout checklist

1. 1. Import a small group of customers and verify package and account references.
2. 2. Test successful, failed, duplicate, delayed, and mismatched payment callbacks.
3. 3. Confirm access changes against a non-critical router or test profile.
4. 4. Reconcile gateway totals against platform transactions before expanding.
5. 5. Document the manual recovery path for support and finance teams.