Hotspot vouchers are the engine of paid public WiFi across Africa. They let transient users buy short bursts of internet at a cafe, lodge, salon, matatu stage, or apartment block without signing a contract or owning a bank account. Done well, a voucher system turns one router and a few access points into a self-running revenue line. This guide walks through the full workflow: building the captive portal, generating and selling vouchers, choosing between time and data plans, letting customers self-purchase with M-Pesa, and reading the reports that tell you whether the business is healthy.
How the captive portal works
The captive portal is the login screen every unauthenticated device sees before it gets internet. On MikroTik RouterOS, the HotSpot service handles this. When a new device connects, the router intercepts its HTTP and HTTPS traffic and transparently redirects it to a login page, and it can even reassign the client IP through one-to-one NAT (the "Universal Client" feature) so devices that refuse manual network settings still work.
You configure it under /ip hotspot with an address pool for client IPs. Two features matter most for a real business. First, the walled garden lets specific destinations load without login, configured with /ip hotspot walled-garden using the dst-host parameter (with /ip hotspot walled-garden ip for raw IP and protocol rules). You should always whitelist your payment provider and your own portal here, otherwise customers cannot reach the M-Pesa or card gateway to pay. Second, login profiles under /ip hotspot user profile enforce limits per plan: rate-limit sets bandwidth (for example 3M/3M), session-timeout forces logout after a set duration, idle-timeout drops inactive sessions, and limit-bytes-total caps cumulative data.
For authentication you have two paths. Small single-router setups can use the router's local user database. Anything serious should use RADIUS by setting use-radius=yes in /ip hotspot profile, which centralizes accounts, plans, and accounting outside the box. RADIUS also unlocks Change of Authorization (CoA): when a session needs to be cut or rate-changed mid-stream (a customer is blocked, or their data runs out), the RADIUS server pushes a CoA or disconnect message to the router instead of waiting for the next login. To receive these, the router must accept incoming RADIUS on the CoA port (3799 by default). The same RADIUS layer authenticates PPPoE for your home subscribers, so hotspot and fixed plans run on one identity system.
Generating and selling vouchers
A voucher is simply a username and password (often the same short code) tied to a plan profile. On MikroTik you can run User Manager as the RADIUS server. You build a profile under /user-manager profile with a name and price, then attach a limitation under /user-manager limitation that defines download-limit, upload-limit, uptime-limit (and optional reset intervals), and you link the two with /user-manager profile-limitation. Validity (how long the plan stays usable from first logon) is set on that profile-limitation link, so set it deliberately.
To create stock, generate users in bulk rather than one at a time. Under /user-manager user, the add-batch-users command produces many accounts with randomized credentials, and generate-voucher exports printable cards or CSV/XML using a voucher template with variables like username, password, and expiry. Print these on small cards, sell them at the counter, and a customer scratches off the code and logs in.
Manual voucher printing works, but it has friction: someone has to stay near the router, reprint when stock runs low, and reconcile cash. This is where a cloud billing layer changes the economics. Iterative Billing provides built-in RADIUS with CoA for both PPPoE and hotspot auth, automated hotspot voucher generation, and a white-label customer portal, so you can mint and track voucher batches from a browser instead of the RouterOS terminal, while RouterOS v6 and v7 handle enforcement at the edge.
Time plans versus data plans
The single biggest pricing decision is whether a plan sells time or data, and the right answer depends on your venue.
Time plans (uptime-limit / session-timeout) suit places where people sit and stream: lodges, restaurants, barber shops, waiting rooms. Customers understand "1 hour" or "24 hours" instantly, and the value is the experience, not the megabytes. The risk is that heavy streamers can saturate your uplink, so always pair time plans with a rate-limit so one phone does not starve the rest.
Data plans (download-limit / limit-bytes-total) suit places where people want to download something specific and leave: print shops, transport hubs, study spots. They protect a thin or expensive backhaul because each customer can only consume what they paid for. The downside is that data caps confuse non-technical users who do not know how many megabytes a video costs.
A practical pattern is to combine both on a single profile so the session ends when either limit is hit first, for example a 24-hour plan capped at 2 GB. Validity adds a third lever: a 2 GB voucher valid for 7 days behaves very differently from the same 2 GB valid for 24 hours. Set validity deliberately so unused vouchers eventually expire rather than living forever. Research local rates and price in small denominations that match how people actually carry money.
M-Pesa self-purchase
Cards and counter sales do not scale. The unlock for African hotspots is letting the customer pay from their own phone and get online seconds later, with no staff involved. M-Pesa via the Safaricom Daraja API is the workhorse here.
The cleanest flow is STK Push (M-Pesa Express), a merchant-initiated C2B payment. The customer picks a plan on your captive portal, enters their phone number, and Daraja sends an STK prompt straight to their handset asking for the M-Pesa PIN. No paybill number, account number, or transaction code to remember. You can also support manual C2B where the customer pays a Paybill or Till and quotes a reference, useful as a fallback. SasaPay and KopoKopo offer similar mobile-money rails, and for travellers you can add card gateways like Flutterwave, Paystack or Pesapal.
Two configuration points are non-negotiable. First, register a secure HTTPS callback URL with Daraja (HTTP is rejected): M-Pesa posts the payment confirmation there, and only on a successful callback should your system activate a voucher and log the user in via RADIUS. Never trust the client to self-report payment. Second, whitelist the gateway and your portal in the hotspot walled garden so unpaid users can actually reach the payment page. Iterative Billing ships M-Pesa Daraja (STK Push, Paybill, Till), Co-op Bank, KopoKopo, SasaPay, Pesapal, Flutterwave and Paystack as built-in gateways, plus SMS notifications to deliver codes and receipts, so a customer can go from "no internet" to "online" without anyone behind a counter.
The hotspot billing system page shows the portal, voucher and M-Pesa self-purchase features described here as they appear in the product, and the hotspot profit calculator lets you test whether a site's daily buyers and bundle prices cover its bandwidth and rent.
Reporting that keeps the business honest
A hotspot only looks profitable until you measure it. Track these continuously:
- •Active sessions and concurrency to size bandwidth and spot peak hours.
- •Revenue by plan and by site to see which package and which location actually pays.
- •Voucher stock and redemption rate so you reorder before you sell out and catch unredeemed batches.
- •Failed payments and abandoned purchases to find broken callbacks or a missing walled-garden entry.
- •Data and uptime consumed per session, which RADIUS accounting records (download, upload, and uptime metrics) so you can right-size plans and detect abuse.
RADIUS accounting on the router feeds these numbers automatically when you set accounting=yes in the hotspot profile, with radius-interim-update controlling how often live usage is reported mid-session. A billing platform then rolls them into dashboards, automated invoices for postpaid or reseller arrangements, and SMS alerts.
Start small: one venue, two or three plans, M-Pesa self-purchase, and the five reports above. Once the numbers prove out, replicate the exact configuration to the next site. You can spin up the whole stack, including hotspot vouchers, built-in RADIUS, and M-Pesa, on a free trial at https://billing.iterativebilling.com/register and white-label it as your own brand.
Frequently asked questions
- Should I sell time-based or data-based hotspot vouchers?
- It depends on the venue. Time plans (for example 1 hour or 24 hours) suit places where people sit and stream like lodges and restaurants, and are easy for non-technical users to understand. Data plans (for example 2 GB) protect a thin or expensive backhaul because each customer only uses what they paid for, which suits print shops and transport hubs. A common compromise is a single profile with both limits plus a validity window, so the session ends when time, data, or validity runs out first. Always pair time plans with a rate-limit so one heavy user does not saturate your uplink.
- How do customers buy a voucher with M-Pesa on their own?
- Use the Safaricom Daraja API with STK Push (M-Pesa Express). The customer selects a plan on your captive portal, enters their phone number, and receives a PIN prompt directly on their handset, so they never type a paybill or transaction code. M-Pesa then posts a confirmation to a secure HTTPS callback URL you register (plain HTTP is rejected), and only on that successful callback should your system activate the voucher and log the user in via RADIUS. You must also whitelist the payment gateway and your portal in the MikroTik walled garden so unpaid users can reach the payment page. Manual Paybill or Till payment can serve as a fallback.
- Do I need RADIUS, or can I just use MikroTik's local users?
- A single router selling a handful of vouchers can run on the RouterOS local user database. But RADIUS becomes important as you grow: it centralizes accounts, plans, and accounting across multiple routers, records per-session data and uptime for reporting, and supports Change of Authorization (CoA) so a session can be disconnected or rate-changed mid-stream when a user is blocked or their data runs out. To receive CoA the router must accept incoming RADIUS on port 3799. The same RADIUS layer authenticates your PPPoE home subscribers too, so hotspot and fixed plans share one identity system. You enable it on the router with use-radius=yes in the hotspot profile.