How to Run a Paid WiFi Business in Uganda

Fluxisystems team October 8, 2026 42 min read

1. Introduction

Your hotspot is up. The router is blinking, the access point is covering the room, and people are connecting all day. The trouble is that nobody is paying.

If that sounds familiar, you are in the right place. Running a paid wifi business in Uganda is not mainly a router problem. You already know how to power a router and insert a SIM. The hard part is the money and the record: getting a customer to pay on their phone, switching their access on at the right moment, switching it off at the right moment, and being able to prove afterwards what happened.

This guide walks through the whole chain in the order a customer meets it. First, what the business is and whether it fits you. Then what you need in place before you build. Then packages and pricing, the customer-facing sign-in screen, mobile money collection, activation and expiry, vouchers, daily failures, your numbers, growth, and common mistakes. A set of short answers to the questions operators ask most sits at the end.

Read it on your phone next to the equipment if you like. Each section stands on its own, so you can jump to the problem in front of you.

2. What a Paid WiFi Business Actually Is in Uganda

A paid WiFi business sells controlled access to an internet connection. A customer pays, gets access for a set amount of time or data, and loses that access when the allowance runs out. You are not selling a password. You are selling a session that starts when payment is confirmed and ends on schedule.

That sounds simple, but it is different from sharing your WiFi password with friends or leaving a network open. Here we define the model so you can tell whether it matches what you are running or planning.

2.1 The core model: captive portal, vouchers, and mobile money

The model rests on three legs.

The first leg is the captive portal. This is the page that appears when a customer joins your network but has not yet paid. Their phone connects to the WiFi, then a sign-in page opens automatically, and until they get through that page, the router will not let their traffic reach the internet. Think of it as a counter at the door of your network.

The second leg is the voucher. A voucher is a prepaid code. It might be printed on paper and sold over the counter, or it might be issued on screen after a payment. Either way, it represents a defined amount of access, and it can be used once.

The third leg is mobile money, which is how the money reaches you. The customer approves a payment on their own phone, and your system is told the payment went through.

Put together, this is what hotspot billing basics means in practice: a portal that captures the user, a package they choose, a payment that is confirmed, and a router that enforces the result. Each leg depends on the others. A portal with no payment is just a login page. Payment with no router enforcement is a gift. A router with no record is a business you cannot audit.

2.2 Who buys and what they are actually paying for

Your buyers in Uganda usually fall into a few groups, and each wants something slightly different.

Students want enough time to study, download notes, and join a class. They care about a price that fits a tight budget and a connection that does not drop mid-session.
People on the move need a quick, reliable window. Someone waiting for a bus in Kampala or passing through Jinja wants to pay, connect, finish a task, and go.
Small traders use the connection for orders, mobile money, and messages to suppliers. They value stability during working hours more than raw speed.
Staff in nearby offices or shops may use the hotspot for work tasks or to save their own mobile data.
Visitors want a hassle-free way to get online without asking anyone for a password.

Notice what none of them are buying: raw bandwidth. They are buying time or data of a predictable quality. A student who pays for an evening wants the connection to behave for the whole evening. If it works well, they come back. If it fails in the middle, they remember it.

That is why the quality of your service matters as much as your price. You cannot count customers you have not met, so do not guess at market size. Watch who actually walks in and what they ask for.

2.3 Hotspot, cybercafe, or community network: where this model fits

Three formats use paid access, and their economics differ.

A single-shop hotspot is a small business that adds WiFi to something else it already sells, such as food, phone repairs, or a salon. Customers come for the main service, and WiFi is an add-on. Paid access here helps cover the connection cost and keeps a few heavy users from slowing everyone else down.

A walk-in cybercafe sells connectivity as its main product. Customers sit at the premises, often for long sessions, and staff are present at the counter. Here the money flow is constant and staff handling cash is part of the daily routine, so counter control and end-of-day reconciliation matter a lot.

A community or estate network serves homes or a compound, for example in a Wakiso estate. Customers are spread out, not in front of you, so you cannot look at them across a counter. They need to pay remotely, get access without help, and trust that the system will treat them fairly.

Paid access tends to beat free access when your connection has a real cost and a limited capacity, when a few users can crowd out the rest, and when you want a record of who used what. Free access can make sense when WiFi is a small courtesy and the cost is trivial. The test is simple: if the connection is costing you money and people are using it, the question is not whether to charge but how.

3. Before You Build: What Must Be in Place

Before spending money, check that you are ready. This section covers requirements and trade-offs so you can judge your own situation. It is not a shopping list with model numbers.

3.1 Hardware checklist: router, access points, and power backup

You need three categories of equipment, and each has a job.

The router. This is the brain of the setup. It must be able to enforce sessions, meaning it can say yes or no to each customer and cut them off when their time or data runs out. It must also support a captive portal and a walled garden (a short list of pages and services that customers can reach before they pay, such as the payment page itself). On top of that, it must be able to ask an outside billing system whether a user is allowed in. That last step is done with RADIUS, which we explain in Section 7.1.

If you plan to use FLUXI to run the billing side, the router has to be a MikroTik running RouterOS. That is the only router platform FLUXI manages. If you use something else, FLUXI will not manage it.

Access points. An access point is the device that spreads the WiFi signal around. One router may not cover your whole space. Walls, floors, and distance weaken the signal, so extra access points fill the gaps. What matters is that coverage reaches where your customers actually sit, and that the access points work with your router instead of fighting it.

Power backup. Power cuts are a fact of life for many Ugandan operators. A small battery backup keeps the router, access points, and modem alive through short outages. What it must do is run the network equipment for long enough to ride out a brief cut or to shut down in an orderly way. It does not need to run your whole shop.

Choose equipment by asking what each item must be able to do, then get quotes from local suppliers.

3.2 Internet supply: shared upstream, dedicated line, or managed connection

Your upstream is the internet connection you buy and then resell as WiFi. You have three broad options.

A shared upstream is a connection that many customers of the provider share, such as a mobile data SIM or a basic subscription. It is usually the cheapest to start. You have little control over quality, and it may slow down when the provider’s network is busy. When it fails, you often wait with no one to call.

A dedicated line is a connection reserved for you. It costs more, but it behaves more consistently, and the provider usually treats faults as business issues. You gain control and predictability, but you carry a bigger fixed cost whether customers show up or not.

A managed connection is one where a provider looks after the equipment and the link as a service. You pay for that convenience. You gain support when things break, and you usually give up some freedom to configure things your own way.

Compare them on three questions. What does each cost over a month? How much control do you get? How does each behave when it fails?

That last question matters most. Your customers will not blame the provider. They will blame you. If the upstream drops during the evening rush, every paid session is affected, and you will be the one answering questions at the counter. So choose an upstream you can rely on for the way you plan to sell. We do not name or price providers here, because offers change. Ask for current terms from the providers in your area.

3.3 Registration, licensing, and tax basics for a Ugandan hotspot

A business that serves the public in Uganda should be aware of a few general categories of obligation. These include registering the business in some form, tax matters, any local trading permission from your local authority, and rules about how you handle customers’ personal data, such as phone numbers.

We will not tell you what applies to you. It depends on how your business is structured, how big it is, and where it operates. Requirements can also change.

The sensible approach is to check current requirements with the relevant Ugandan authorities before you operate publicly. Authorities such as the Uganda Revenue Authority, the Uganda Registration Services Bureau, your local authority, and the Uganda Communications Commission may be worth contacting. Ask each of them directly whether anything applies to you, and use their official websites and offices for specifics.

This article is not legal advice, and it is not a substitute for official guidance.

3.4 Budgeting the first month of running costs

Write your budget as a list of categories, with a blank next to each one for your own figure. Do this before you launch so surprises do not eat your first month.

Your categories are:

Bandwidth. What you pay your upstream provider.
Power. Electricity, plus fuel or battery replacement if you use a backup source.
Equipment. The router, access points, and backup power, spread across the time you expect to use them. Include repairs and replacements.
Transaction fees. The charge taken on each mobile money payment you collect.
Airtime and data. SIM top-ups, and any data you buy to keep the setup connected or managed.
Time. Your hours and any staff hours. Time is a cost even when you do not pay yourself a wage.

Put your own number beside each line. Where you do not know a number, write “ask supplier” and find it out. A budget with honest blanks is more useful than a confident budget built on guesses.

When you finish, add a small cushion for things that go wrong. A router will fail, a payment will confirm late, and a power cut will last longer than expected. The cushion keeps one bad week from ending the business.

4. Decide Your Packages and Pricing

Pricing is the single biggest lever on whether this business survives. A bad price can turn a busy hotspot into a loss. A good price keeps customers happy and leaves you something at the end of the month.

4.1 Hourly, daily, weekly, and monthly plans

Time-based packages come in four standard shapes.

Hourly suits the quick visitor who needs a short window.
Daily suits the person who works or studies near you for a whole day.
Weekly suits regulars who come most days.
Monthly suits your steadiest customers, such as nearby traders or staff.

A mix usually works better than a single tier. A single plan forces everyone into the same box. The visitor who needs a few minutes pays too much, and the regular who stays all week gets no reward for loyalty. A mix lets customers pick the plan that matches how they use the connection, and it spreads your income across short and long relationships.

Packages also differ in what they measure.

A time-based package sells a length of time. The session ends when the clock runs out.
A data-based package sells an amount of data. The session ends when the data is used, whatever the clock says.
A hybrid package sells both, and ends at whichever limit arrives first.

Time-based packages are the easiest to explain to a customer. Data-based packages protect you better against heavy downloaders. Hybrid packages give you both protections but need clearer wording on the sign-in page. Choose the shape that matches how your own customers behave. We carry no price points or named tiers here, because yours depend on your costs and your area.

4.2 Setting prices in UGX against local willingness to pay

Do not try to find a perfect number on day one. Use a method instead.

Start with three questions. How much can your customers realistically afford to pay in UGX? What is an hour or a day of their time worth to them? What does connecting cost them elsewhere, such as buying mobile data on their own phone, or going to a competitor down the road?

Your price should sit where those three answers overlap, and it must also cover your own costs. The cost side comes from your budget in Section 3.4. If your price is below your cost, no amount of customers will save you.

Then test. Launch with a starting price, watch how customers react, and adjust. If almost everyone buys your cheapest option and nobody buys the rest, your ladder may be badly spaced. If people hesitate at the payment screen and walk away, the price may be too high. If you sell out quickly and still feel stretched, it may be too low. For more on the thinking behind pricing WiFi packages and working out what to charge, the key habit is the same: change one thing at a time and watch what happens.

We state no UGX figures here on purpose. Your numbers must come from your own costs and your own customers.

4.3 Speeds, data caps, and fair use rules

Without limits, a few heavy users can use most of your connection and leave everyone else with a crawl. Per-user bandwidth shaping fixes this. The router divides the connection so each customer gets a fair share and no single phone can hog the lot.

A data cap is a limit on how much data a package includes. A fair use rule is a written statement of what is reasonable on your network, for example that a package is meant for browsing, messaging, and normal work, not for running large downloads all day. Its purpose is to set expectations so a customer is not surprised when a limit applies.

A rule only works if the router enforces it. A cap that cannot be enforced in the router is not a cap. It is a sentence on a poster. If the limit lives only in your head or on the sign-in page, customers can ignore it, and you will have no way to stop them.

So set your limits where the router can act on them. Decide the speed each customer gets and the data each package includes. Then confirm that the router really applies them. We describe these as concepts and give no speeds or cap figures, because the right values depend on your upstream and your customers.

4.4 Overnight and off-peak pricing

Your connection sits idle during quiet hours. Off-peak and overnight pricing is a way to earn from that idle capacity. You offer a lower price in the quiet window, and customers who can shift their usage, such as someone downloading a large file, come at that time.

To define the window, watch your own usage. Look at when the network is busiest and when it falls quiet, then draw the off-peak window around the quiet stretch. Do not copy someone else’s hours. A cybercafe near a campus and a shop in a trading centre have different rhythms.

Be honest about the risk. Off-peak customers use shared equipment when fewer people are around. If the router freezes at night, nobody may be there to restart it. If a customer pays overnight and something goes wrong, who answers? Before you offer overnight pricing, decide who covers faults in that window, and make sure the equipment can recover from a power cut or a reboot without staff on site. If you cannot cover it, do not sell it.

4.5 Pricing choices that quietly destroy your margin

Some pricing mistakes look fine until the end of the month. Watch for these.

Prices below the true cost of bandwidth. If each sale costs you more than it brings in, selling more makes things worse.
Packages that are generous in peak hours. If your most generous deals run when the network is most crowded, your best-paying customers get a worse experience, and your costs rise when capacity is tightest.
Unlimited packages on constrained links. A package with no limit on a small link invites a few heavy users to crowd out everyone else. If you offer one, make sure the link can support it.
Prices that ignore failed and abandoned sessions. Some customers start paying and never finish. Some payments fail. Some sessions break after a power cut. Those events cost you time, fees, or goodwill even when no money arrives. Your price needs to carry that cost.

Add these up, and you can see how a hotspot can look busy and still lose money. Check your prices against your real costs regularly, not just when you launch.

5. Set Up the Customer-Facing Access Point

The customer-facing layer is everything a person sees from the moment they open their phone’s WiFi list to the moment they are online. This is where people decide whether to complete sign-up or give up and walk away.

5.1 SSID naming and captive portal branding

The SSID is simply the name of your WiFi network, the one that appears in a customer’s WiFi list.

Name it so customers recognise it. Use your business name or a clear version of it. A customer in your shop should look at the list and know at once which network is yours. A vague or confusing name causes mistakes, and it makes it easier for a lookalike network to trick people.

Brand the portal page as well. Show your business name and keep the look simple. A branded page tells the customer they are in the right place, and it looks more legitimate when they are about to type a phone number or approve a payment.

There are practical reasons for both. Recognition means fewer customers connecting to the wrong network. Trust means more people finish payment. Clear naming also helps support: when a customer says “I am on your WiFi,” you know what they mean, and you can ask them to check that they chose the right network.

5.2 Landing page essentials: what a new user sees first

The landing page is the first thing a new user sees. On a small phone screen, it has to do a lot with very little space.

The first screen should show:

What this network is. Your business name, so the customer knows they are in the right place.
How to get connected. One clear instruction, such as “choose a package” or “enter your code.”
The options and prices. A short list of packages with their price in UGX, easy to read without scrolling for ages.
How to get help. A phone number or a place to ask, so a stuck customer is not left alone.

Keep it short and legible. Use large text and big buttons. A customer standing in a queue with one hand on their phone will not read paragraphs. If they cannot tell in a few seconds what to do, they will give up.

5.3 Onboarding by voucher code, phone number, or both

There are three ways to sign a customer in.

Voucher code. The customer types in a code they bought or received. It needs the least from the customer’s phone: no mobile money balance and no payment prompt. At the counter, it means you hand over a code and take payment yourself. It suits a cybercafe or a small shop with staff present.

Phone number. The customer enters their mobile money number, picks a package, and approves a payment prompt on their handset. It needs no staff at the counter. It suits a community network or a busy shop where you cannot serve everyone by hand.

Both. The sign-in page offers a code field and a payment option side by side. Customers who prefer cash use a code, and customers with mobile money pay directly. For most operators in Uganda, offering both is the safest choice, because you do not turn anyone away.

A single-use code works once and then stops working. The voucher lifecycle is the full journey of a code in generic terms: it is created, printed or issued, sold or handed out, redeemed by a customer, and finally expires. Each code should be redeemable once. We cover the lifecycle in detail in Section 8.

Many of your customers will sign up on a weak or slow mobile connection, and some may have almost no mobile data left. Design for them.

Minimal pages. Keep the sign-in page light. Large images and heavy scripts slow everything down.
Minimal typing. Typing on a phone is slow. Ask only for what you need, such as a phone number or a code.
No large downloads. Do not make customers download an app or a large file to sign in.
A path that works when the connection is poor. If the page struggles to load, the customer should still have a way forward, such as a simple code field or a clear message that tells them what to do.

This is where the walled garden matters. A walled garden is a short list of addresses that customers can reach before they have paid. It lets the sign-in page, the payment flow, and anything else needed to complete sign-up load without full internet access. Without it, a customer may be stuck at a page that cannot load the thing it needs. Keep the list short. Everything outside the walled garden stays closed until the customer has paid.

6. Set Up Payment Collection with Mobile Money

This is the part most operators have never done before. It involves a handset in a customer’s hand, a message travelling through a telecom network, and your system waiting for an answer. We explain it carefully and concretely.

6.1 Supported methods: MTN Mobile Money and Airtel Money

The two mobile money options that matter in Uganda are MTN Mobile Money and Airtel Money. Customers expect to pay with whichever one they use, and if you only support one, some of them cannot buy from you. Supporting both is what customers expect.

Think of each as a collection rail: a route along which a customer’s payment travels to reach you. You do not build the rail. You connect to it. What matters to you is that a customer can approve a payment on their own handset and that your system is told the outcome.

FLUXI, a billing platform built for Uganda and UGX, names both MTN Mobile Money and Airtel Money on its public site, and it collects through MarzPay, which is its only active collections integration. That is context for the operator, not a requirement. The mechanics in the sections below apply however you set up your collection.

6.2 How the payment prompt reaches the customer

Here is the collection loop, step by step.

The customer identifies themselves. They choose a package and enter their mobile money phone number.
A payment request is raised. Your system asks the mobile money network to request payment from that number. The request carries a reference, a unique label that ties this payment to one specific session.
The customer confirms on their own handset. A prompt appears on their phone, and they approve it, usually by entering their mobile money PIN.
The confirmation comes back independently. The mobile money network tells your system the payment succeeded. This message is often called a callback. It arrives separately from the customer’s browser.

Two points deserve emphasis.

First, a customer should never see a payment prompt they did not start. If random prompts appear on people’s phones, they will lose trust, and some will report it. The request must only be raised after the customer chose a package and entered their own number.

Second, the reference must tie the payment to one specific session. If the reference is vague, you cannot tell which customer paid for what. That leads to the wrong person getting access, or the right person getting none.

One more design point matters for the customer’s experience. The customer’s browser is never blocked while waiting for the telecom to answer. The page returns right away and shows a waiting message, and the callback, or a later reconciliation check, moves the state forward. This is how FLUXI works, and it is a good pattern for any setup.

6.3 Confirming payment and granting access immediately

The payment confirmation arriving from the mobile money network is the trigger for access. Not the customer saying they paid, not a screenshot, and not a staff member’s word. The confirmation is the only event that should switch access on.

Your business must be able to see that confirmation arrive. Do not just assume it did. You need a record that shows the payment, the reference, and the time it was confirmed. If you cannot see it, you cannot check it later.

Once confirmation arrives, access should follow quickly. We give no latency figures, because speeds depend on the networks involved and nobody should promise one. What you can expect is that access follows soon after confirmation, and you should plan your counter routine around that.

There will also be a short gap in which a payment is confirmed but the customer is not yet online. That is a normal, expected state. It resolves itself as the system catches up. It is not a fault, and it should not trigger panic. Tell customers to wait a moment and keep the page open.

6.4 Handling delayed, duplicate, and failed payment prompts

Mobile money does not behave like a card machine. Confirmations can arrive late, arrive twice, or never arrive. That is normal. A good setup expects all three and handles each one separately.

A delayed confirmation. The customer approved the prompt, but your system has not heard back yet. This happens when a network is busy. Do not ask the customer to pay again. Tell them the payment is being confirmed and to wait. The confirmation, or a later check against the provider, will move things forward.

A duplicate callback. The mobile money network sends the same confirmation more than once for a single payment. This is common. If your system treats each message as a new payment, one payment could grant access twice, or credit twice.

This is why fulfilment must be idempotent, meaning that doing the same thing twice has the same result as doing it once. It must be enforced at the database level, so that the database itself refuses to record the same payment a second time. Application-level checks alone are not enough. Two copies of the same message can arrive at nearly the same instant, and code that checks first and writes second can let both through. FLUXI treats payment fulfilment as idempotent at the database level for exactly this reason.

A payment that never confirms. The customer approved, or thought they approved, and nothing ever arrives. Sometimes the customer never approved at all, or the prompt timed out on their phone. Your system should check the payment’s real status with the provider, and then either confirm it or mark it as failed. Do not guess.

While the customer waits, tell them honestly what is happening, for example “your payment is being confirmed, please wait a moment.” Staff should not grant access by hand on a customer’s say-so, and should not ask for a second payment until the first has been checked.

Messages to the customer are a convenience, not the foundation. When a voucher code is issued after payment, it is always shown on screen. A text message with the code is queued separately and is never sent inside the payment request itself, so a slow SMS can never hold up the customer. The SMS is a convenience, not the only channel. The on-screen code is never left out.

6.5 Fees, float, and settlement: what actually lands in your account

Three ideas explain the gap between what a customer pays and what you finally receive.

A transaction fee is a charge taken on each collection. It reduces what you keep from every sale. Because it applies to each payment, it matters more on small packages than on large ones, so it belongs in your pricing decision.

Float is the balance held on your mobile money float account. If it runs low, the account may stop accepting payments, so you need to keep it topped up. Treat float as working capital that you must plan for, not a bonus.

Settlement is the process by which collected money moves into your merchant account. There is usually a gap between the moment a customer pays and the moment the money lands where you can use it. Plan your cash flow around that gap.

Reason about all three as shares of your own pricing. For each package, ask: of what the customer pays, how much do fees take, how much is tied up in float, and when will the rest settle? We state no fee rates, no percentages, and no settlement timings, because they are not verified and they change. Use the real terms from your provider, and check them regularly.

7. Activate, Monitor, and Expire Access Correctly

This is the router-enforced part of the flow. It is where many home setups quietly fail. Nothing looks broken, yet money leaks out every day.

7.1 What happens on the network at activation

When access is granted, several things happen on the network.

The session starts. The router records that this customer is now allowed online. The router then enforces the time or data limit for the package they bought. The customer’s traffic is shaped, so they get their fair share of speed, and accounted for, so the system knows how much time or data they have used.

The mechanism that lets the billing system and the router talk to each other is RADIUS. In plain terms, RADIUS is a standard way for the router to ask a central system, “Is this person allowed in, and for how long?” The billing system answers, and the router follows the answer. During the session, the router also sends usage updates back, which are called accounting events.

FLUXI implements RADIUS, including accounting events, and works with MikroTik RouterOS as its router platform. The idea matters beyond any product: the router should never decide on its own who gets in. It should ask the system that holds the payment record.

7.2 Clean expiry and automatic disconnection

Expiry must happen automatically, without a staff member, at the exact time the customer paid for. If a customer buys an hour, the hour should end when the hour ends.

A session that fails to end costs you money quietly. The customer keeps using bandwidth they did not pay for, and you pay your upstream for it. Nobody notices, because nothing looks wrong.

A stale session is a session that the router still shows as active although it should have ended, or that the billing record thinks is over while the router keeps letting traffic through. From the network side it looks like a user who is still connected long after their allowance ended. A restart of the session, or a reconciliation pass that compares the router’s list of active users against the billing record, can clear it.

Paid time must also survive a reboot. Imagine a router restarting during evening peak. A customer who had paid for a full evening should come back online with their remaining time, not lose it and not get extra. If a reboot wipes the record of who paid for what, you will either shortchange honest customers or hand out free time. Both are bad. Make sure the record of paid time lives somewhere that does not disappear when the router restarts.

7.3 Spotting and fixing users who bypass the portal

Some users try to avoid paying. The common bypass routes are:

A hidden or unsecured network. Someone connects to a second network on the same equipment that was not set up to require payment.
An open SSID. An open network name with no portal in front of it lets anyone straight through.
One login shared across many devices. One customer pays, then gives the login to friends, so many people use one paid session.

Router-enforced session limits and walled gardens close the easy routes. If every network name on your equipment sits behind the portal, and the walled garden only opens what is needed to pay, there is no side door. If each login can only run a limited number of devices at a time, sharing stops being free.

To look for suspicious patterns, check your records. One account with far more devices connected at once than you would expect is a strong sign of sharing. Odd activity at unusual hours, or many devices appearing and disappearing on one login, is another. Look at the pattern before you act, because it may have an innocent explanation.

7.4 Blocking repeat abusers without punishing honest users

Your goal is to stop sharers, not to upset customers who play fair. A person with a phone and a laptop is a normal customer. A person with a large number of devices on one login is not.

Use two tools. A device limit caps how many different devices one account can use. A concurrent session limit caps how many sessions can be active at the same time. Set them high enough for an honest customer on a couple of devices, and low enough that a sharer runs into the limit quickly.

Before you take action against a paying customer, review their account history. Check when they connected, how many devices they used, and whether the pattern is repeated or a one-off. A customer who hit the limit once while switching phones deserves a friendly explanation, not a ban. A customer who repeatedly runs many devices on one paid login may deserve a firmer response. Look at the record, then decide.

8. Run the Voucher Side of the Business

Printed vouchers still have a role in a modern hotspot business. Running that side well means keeping control of the codes and the money they represent.

8.1 When printed vouchers still make sense

Printed vouchers remain useful in several situations.

Customers without a reliable mobile money handset. Some people do not have a phone that can take a payment prompt, or prefer not to use one.
Places with poor mobile coverage for payments. If the payment prompt struggles to reach the handset, a printed code the customer already holds still works.
Prepaid trust. A customer holding a code knows what they bought before they connect.
Lower per-transaction cost. A cash sale at the counter avoids the transaction fee that mobile money collections carry.

Carrying a printed voucher line next to mobile money is a valid business choice. It is not a leftover from an older way of working. Running both lets each customer choose whichever suits them.

One more point: printed vouchers can sit unsold for a long time, and that is normal. It is simply inventory, like any stock on a shelf. A voucher that has not sold yet is not a fault, a leak, or a warning sign.

8.2 Batch generation and keeping codes secure

The voucher lifecycle runs in a simple order:

Generate a batch. Create a group of codes in one go.
Print the codes. Put them on sheets or cards.
Distribute or sell them. Hand them to staff or sell them over the counter.
Redeem each code exactly once. The customer enters it, and it is then used up.
Let codes expire on schedule. Unused codes should not stay valid forever.

The security of the business depends on two things. Codes must be unguessable, so nobody can invent a working code by trying combinations. And each code must be redeemable only once, and that rule must be enforced at the database level, so the database itself refuses a second redemption even if two people try the same code at the same moment.

FLUXI supports vouchers, including print batches, redemption, and expiry. Whatever tool you use, check that single-use is enforced where it cannot be bypassed, and keep printed sheets somewhere safe until they are sold.

8.3 Staff sales, unsold stock, and end-of-day reconciliation

When staff sell vouchers over the counter, you need to know who sold what. Give each staff member their own batch or sheet range, record what they were given, and record what they hand back. That is staff accountability.

At the end of the day, balance the books. Count the remaining stock. Compare the cash you hold against the digital record of what was activated. This cash reconciliation is how you catch mistakes and theft early. If the numbers do not match, you want to find out that evening, not at the end of the month. For more on staff reconciliation and balancing the counter day against the record, the principle is simple: the record, not memory, decides what was sold.

One rule is firm. Fees, commissions, and settlement should be tied to the trusted activation event, meaning the moment a voucher or session was actually activated in the system, and never to a staff-reported “sold” flag. A staff member saying a code was sold is a claim. A code being activated is a fact. FLUXI keys platform fees, commissions, and settlement to the activation event for this reason.

Remember that unsold printed stock is normal. When you count remaining stock, do not treat a long-sitting voucher as a problem. Count it, record it, and move on.

9. Handle the Day-to-Day Failures

Things will go wrong. The promise of this guide is that most failures are survivable if you expect them. Here are the ones you will meet most.

9.1 Power cuts and what backup actually buys you

Power backup protects a few things. It keeps the router, access points, and modem running through a short cut, so customers stay online. It also gives you time to shut equipment down properly if a cut drags on.

It does not protect everything. It will not keep your whole shop running, and it will not last forever. A battery that runs flat in the middle of a long outage leaves you with the same problem as having no backup, only later.

A graceful shutdown and restart matters because of paid time. If the router loses power abruptly, it may lose track of sessions in progress. If it shuts down in an orderly way and comes back cleanly, it can restore who is online and how much time each customer has left. That is how you preserve paid time across an outage.

Tell customers what is happening. A simple notice at the counter, or a message on the sign-in page, saying the power is out and service will return, saves many questions. Honest, early communication keeps people patient.

9.2 Upstream outages, throttling, and running out of data

There are three different upstream failures, and they need different responses.

The link is down. Nothing gets through. Your router may show no connection at all, or a test to any website fails.
The link is throttled. The connection is up but painfully slow, because the provider has slowed it. Pages load, but badly.
The allocation is used up. If you buy a limited amount of data each month, and it runs out, your connection may stop or slow sharply until you buy more.

To tell them apart, check the router first. If it cannot reach the internet at all, the link is down. If it can, but speeds are terrible even with few users, suspect throttling or congestion on the provider’s side. Then check your provider balance or usage to see whether the allocation has run out.

While the upstream is down or throttled, tell your customers plainly. Do not keep selling packages you cannot deliver. Consider pausing sales on the sign-in page, or telling people at the counter before they pay. If paid sessions are running while the link is down, consider how you will make it right afterwards.

When the month’s allocation runs out, buy more if you can, or pause sales until you can. Selling access you cannot supply costs you refunds and reputation.

9.3 When a customer paid but cannot connect

Follow this triage in order.

Confirm the payment was received. Look at your payment record. Is there a confirmed payment for this customer and reference?
Confirm the session was created. Did the system start a session for them after confirmation?
Confirm the account is within its device limit. Is the customer using more devices than their login allows?
Confirm the customer is on the right network. Many problems come from a customer joining the wrong network name.

While you investigate, give the customer a calm, clear message, such as “your payment is being checked, please keep the page open and give us a moment.” Do not blame them, and do not ask them to pay again.

Remember that a paid but not yet online state is expected, not exceptional. Because the confirmation travels separately from the customer’s browser, there is often a short gap between paying and getting online. Many cases resolve on their own while you are still checking.

9.4 When the network is up but payments stop confirming

Here, customers can connect and the internet works, but payments are not confirming. You need to find out which part has failed. There are three suspects.

The collector. Is the payment request even reaching the customer’s phone? If no prompts arrive, the problem is on the collection side.
The network. Is your own connection to the outside working? If the link is up, this is unlikely.
The confirmation path. Do prompts arrive and get approved, but the confirmations never reach your system? Then the problem is on the return route.

A reconciliation pass against the provider’s status query is how you recover confirmations that were delayed or lost. Instead of waiting for a callback that may never arrive, your system asks the provider directly about the status of each pending payment, and then updates its own records. FLUXI runs reconciliation as a scheduled path, with a live provider status query as the backstop, so confirmations that were missed can still be recovered.

Tell waiting customers the truth: their payment is being checked, and access will follow once it is confirmed. Do not ask them to pay a second time before the first has been checked.

9.5 Device limits and shared connections

A device limit is the maximum number of devices one paid account can use at the same time. Set it so honest customers are unaffected. A person with a phone and a laptop, or a phone and a tablet, should work without trouble.

Shared logins stretch a single paid session. One person pays, and many people use it. You lose the income from those others, and the network slows down for everyone.

To spot sharing, look at the number of devices per account and the pattern over time. An account that suddenly shows many more devices than usual deserves a look. To resolve it, start with the record. Contact the customer politely, explain the limit, and offer a second package if they genuinely need more devices. Do not cut off a legitimate customer on a hunch. Check first, then act.

10. Know Your Numbers and Control Costs

You do not need an accountant to run a small hotspot. You need a little discipline. This section gives you the minimum.

10.1 Bandwidth cost versus what you are charging

The core ratio compares two things: what your bandwidth costs you, and what your customers pay you for it.

The inputs are:

What you pay your upstream provider for a period.
How much of that capacity customers actually use.
What customers pay, in total, over the same period.

Divide your bandwidth cost by what customers paid. If bandwidth takes most of what you collect, you have little room left for power, fees, and equipment.

Heavy users skew the ratio. A small number of customers can use a large share of the data while paying the same as everyone else. That pulls your real cost per customer up. Caps and fair use rules protect the ratio, because they limit how much any one customer can take. We state no prices, fees, or figures here. Plug in your own.

10.2 A rough monthly profit calculation for a small hotspot

Here is the shape of a simple monthly calculation. Fill in each line with your own numbers.

Total collections for the month: your figure
Minus bandwidth cost: your figure
Minus transaction fees: your figure
Minus power and equipment: your figure
Minus any revenue share you owe: your figure
Equals what is left: the residual

Be careful with the first line. Total collections should come from your trusted record, not from memory or from staff reports. Use confirmed payments and activated vouchers.

If the residual is small or negative, look at the lines. Is bandwidth too high for what you charge? Are fees eating the small packages? Is equipment being replaced too often? The calculation tells you where to look.

We state no UGX amounts, no revenue figures, and no profit outcomes. Your result belongs to your own business.

10.3 The tools you actually need day to day

You need only a few tools, grouped by what they do.

Seeing who is connected and for how long. A live view of active sessions.
Seeing payments and vouchers. A record of confirmed payments and of vouchers generated, sold, redeemed, and expired.
Reconciling the day. A way to compare cash and digital records at closing time.

Understand the difference between a tool that reports and a tool that enforces. A report tells you what happened. An enforcing tool, such as a router that cuts off an expired session, makes it happen. You need both, and you should not confuse them. A dashboard that shows an expired user still online has not removed them.

Also remember that a record nobody trusts is worse than no record. If staff and owner argue about whether the numbers are right, the numbers are useless. Keep your record clean, check it daily, and fix errors when they appear.

11. Grow Beyond the First Router

Many operators start with one router and one counter. Growth is a progression, and each step has a condition.

11.1 Adding sites and more access points

Start by adding access points on one site. If coverage is patchy, add an access point before you think about a new location. Make sure your upstream can carry the extra users, because more coverage means more demand on the same link.

Then consider extending beyond your first location to multiple sites. Before a second location is worth running, several things should be true. Your first site should run smoothly without you standing next to it. Your payments and expiry should work reliably. Your records should balance day after day. If the first site still needs constant rescue, a second will only double the trouble.

Each new site also needs its own upstream, its own power plan, and someone responsible for it. Treat each as a small business with its own costs.

11.2 Moving from a single manual setup to a managed system

A managed system changes how you run the business in three ways.

Per-tenant separation. Each site’s data is kept apart from the others. FLUXI enforces this at the database level, so one tenant’s records cannot be read through another’s. This matters when different sites, or different owners, share the same platform.

Remote management. You can look after sites without visiting them. FLUXI supports remote access to routers over a private tunnel. The transport depends on the router software version: WireGuard on RouterOS 7.x, and SSTP on RouterOS 6.x.

Visibility across sites. Instead of logging into each router one at a time, you want a single view that shows what is happening everywhere. When you compare managed systems, ask whether they give you that.

Keep in mind that these changes only help if the basics below them are sound. A managed system makes good habits easier to repeat. It does not replace them.

11.3 When to automate instead of hiring more staff

The decision is simple. Automate the repetitive work first. Collecting payments, reconciling them, and expiring sessions are tasks that follow rules and repeat all day. A machine does them without tiring and without mistakes. Adding a person to do them costs wages and still leaves room for errors.

Hire for the work that needs a person. Counter sales need a friendly face. Customer support needs someone who can listen, explain, and solve a problem. Fixing hardware on site needs hands.

If you find yourself thinking about hiring because collection, reconciliation, or expiry is overwhelming, stop and ask whether automation could take that load first.

12. Common Mistakes to Avoid

Here are the most damaging errors in one place, each with its consequence.

12.1 Charging too little and working yourself broke

If your price is below the true cost of bandwidth, power, and transaction fees, you will earn revenue but no profit. The more you sell, the more you lose. And raising prices later is harder than setting them correctly. Customers get used to a price, and a sudden increase feels unfair. Set your price from your costs from the start.

12.2 Trusting the software instead of the record

A dashboard is only as good as the record underneath it. If the counts are not verified, the stock has not been confirmed, and the day has not been reconciled, small errors pile up into real loss. Check the record against reality often. Count stock. Balance the day. Trust the checked record, not the screen alone.

12.3 Granting access before payment is confirmed

If you let someone online because they said they paid, or because a request was made, you are handing out uncompensated use. Anyone can trigger that. The network must enforce the trusted event, which is the confirmed payment, and not the request. Wait for confirmation, every time.

12.4 Running the entire business on paper

A paper-only operation has no session history. It cannot recover from a device reboot or a router failure, because nothing remembers who paid for what. It leaves no reconciliation trail, so errors stay hidden. And it gives you no basis for defending your revenue figures if anyone asks. Paper can support a business, but it cannot be the whole record.

13. Frequently Asked Questions

13.1 How much does it cost to start a paid WiFi business in Uganda?

The cost depends on your own figures and supplier quotes, so we state no amounts. The categories to price are the router and access points, power backup, internet supply, and the working capital you need for float and early running costs. Get quotes for each from local suppliers, and add them up. That total is your real starting cost.

13.2 How much should I charge per hour or per day?

Use a method rather than a number. First work out your cost per hour of served bandwidth, then add power and transaction fees. Then test the result against what local customers are willing to pay and what their time is worth to them. Adjust as you learn, and state your final prices in UGX on the sign-in page.

13.3 MTN Mobile Money or Airtel Money: which one should I support first?

Both are expected in the Ugandan market, so you should support both to avoid losing customers. If you can only start with one, let your own customers decide. Ask which one most of them use, and begin there. Do not assume one is bigger or faster than the other.

13.4 Do I need business registration to run a hotspot?

Check current registration and tax requirements with the relevant Ugandan authorities before you operate publicly. What applies depends on your structure and scale. This article is not a substitute for official guidance, and it gives no legal advice.

A shared network password is one secret that everyone knows, so once it is out, you cannot control it. Per-user access is different: each customer has their own credentials. What actually stops sharing is per-user credentials combined with router-enforced device and session limits. The router then refuses extra devices on one login, so sharing stops being free.

13.6 What do I do when a customer pays but gets no access?

Work through the triage in order. Confirm the payment arrived, confirm the session exists, confirm the customer is on the right network, and check whether the account is at its device limit. A paid but not yet active state is normal, and it resolves itself. Reassure the customer and ask them to wait while you check.

13.7 Is a voucher system still worth it if I accept mobile money?

Yes. Some customers cannot pay by mobile money, and others prefer to pay in cash. A prepaid code also settles the question of what the customer bought. The two can run side by side, so each customer uses the route that suits them.

13.8 Can I run a paid hotspot without a dedicated internet line?

Yes. A shared or managed upstream can carry a small hotspot. The trade-off is less control and more exposure to upstream throttling and outages. That is why you should match your package limits to what your actual upstream can deliver.