1. Introduction to MikroTik Captive Portal for Paid WiFi
A captive portal is the gatekeeper of your paid WiFi. When a customer joins your network and opens a browser, the portal catches that request and sends them to a login page instead of the open internet. Only after they sign in or pay does the router let their traffic through. On a MikroTik router, this job belongs to the HotSpot feature.
Why does the setup matter so much? Because every part of the customer journey runs through it. If the login page does not appear, customers think the WiFi is broken. If the payment page is blocked, they cannot pay. If sessions end at the wrong time, they complain. A portal that is only half right costs you customers and creates support work.
This guide shows you how to configure MikroTik captive portal for paid WiFi in a clear, practical order. You will cover the server, profiles, login methods, pages, pre-login exceptions, payment linkage, and testing. There are no commands here. The focus is on what you decide and check at each stage, so you can apply the ideas on your own router with confidence. If you also use FLUXI for MikroTik hotspot billing, the same foundations apply, because billing only works well when the portal underneath it is sound.
2. Required Hardware and RouterOS Access
Before you touch any HotSpot setting, make sure the basics are ready. You need a MikroTik router running RouterOS that is already doing its core job: connecting to your internet source and serving your local network. A captive portal sits on top of a working network. It cannot fix one that is not working yet.
You also need reliable access to the router. That means you can sign in with an administrator account, reach the configuration tools you prefer, and stay connected while you make changes. Plan your work for a quiet period so a mistake does not interrupt paying customers.
2.1 Router Roles and Interface Assignment
Think of your router as having roles. One side faces the internet. Another side faces your customers. Your management access may use a separate path. HotSpot belongs on the customer-facing side only.
Interface assignment is simply deciding which physical or wireless connection carries customer traffic and will be covered by the portal. Get this clear before you start. If you apply HotSpot to the wrong interface, you may lock yourself out of the router or leave customers outside the portal entirely. Write down which interface serves customers, which serves the internet, and which you use to manage the router. A short note now saves a long troubleshooting session later.
2.2 Administrative Access and Configuration Backup
Secure administrative access matters because the router controls who pays and who connects. Use strong credentials, limit who can sign in as an administrator, and avoid sharing one login across a whole team. A weak admin account puts your entire paid service at risk.
Take a configuration backup before you make any HotSpot change. A backup gives you a safe way back if a new setting blocks customers or breaks your login flow. Keep the backup somewhere other than the router itself, and make a fresh one before each major round of changes. Think of it as your undo button.
3. Creating and Enabling the HotSpot Server
This section covers how to create and enable HotSpot server in MikroTik RouterOS as a logical sequence of decisions. You choose where the server will run, decide where client addresses come from, define how customers reach the login page, and then enable the server and confirm it responds.
At each point, ask a simple question: does this choice match my network layout? A HotSpot server that sits on the wrong interface or hands out addresses from the wrong source will not serve customers well, no matter how good the rest of your setup is. Work in order, check each choice, and only enable the server when you are satisfied. This is the heart of any MikroTik HotSpot server setup.
3.1 Selecting the Interface and Address Pool
The interface tells the server which customers it is responsible for. Customers who connect through that interface will be intercepted by the portal. Choose the customer-facing interface, not the one that connects to the internet or the one you use for management.
The address pool is the set of addresses available to hand out to connecting devices. Each customer device needs an address before it can reach the login page. If the pool is missing, mismatched with the network, or too small for your expected number of users, devices may connect to WiFi but never get far enough to see the portal. Make sure the pool fits the customer network and has room for the devices you expect at your busiest times.
3.2 Setting the DNS Name for Login Redirects
The DNS name gives the router a recognizable name to use when it redirects customers to the login page. Instead of showing a raw technical address, the browser lands on a clean, consistent destination. That makes the login step feel smoother and more trustworthy to customers.
If you are wondering how to set DNS name for MikroTik HotSpot login redirect, start with the purpose. The name needs to resolve correctly for customers who are not yet logged in, so the redirect actually reaches the router. Choose a name you control and can keep stable. Then confirm from a customer device that the redirect lands where you expect. A missing or incorrect name is one of the most common reasons customers see an error instead of a login page.
4. Configuring HotSpot Server Profiles
A server profile is a bundle of behavior that your HotSpot server follows. It shapes how the portal treats customers when they arrive, how they log in, and how their sessions behave. Because the server uses the profile every time, a good profile gives every customer the same predictable experience.
That consistency matters for paid access. When all customers follow the same rules, you can explain those rules clearly, and you can spot problems quickly. A well-planned MikroTik HotSpot server profile also keeps you from fixing the same problem again and again on different parts of your setup. Treat the profile as the place where your service policy lives.
4.1 General Profile Settings
General profile settings cover the basics: how the server presents itself, which login behaviors it allows, and how it handles common customer actions. These settings sit in the background, but customers feel them. They affect whether the redirect works smoothly, how the login page loads, and how the portal behaves once someone is signed in.
Go through the general settings with your customer journey in mind. For each one, ask what a paying customer would notice if it were wrong. Keep your choices simple and consistent. Do not change several settings at once, because then you cannot tell which change caused a new problem. This is a core part of RouterOS HotSpot configuration.
4.2 Session Limits and Idle Timeouts
Here is how to configure session limits and idle timeouts in MikroTik HotSpot at a practical level. A session limit controls how long a customer can stay connected in one sitting. An idle timeout controls what happens when a connected device goes quiet. If it stays inactive long enough, the router can end that session and free the connection.
These limits help you manage shared access fairly. Without them, abandoned sessions can hold on to capacity that active paying customers could use. With them, your network stays tidy and your service rules stay clear.
Set limits to match what you promise customers. If your plan says a customer gets a certain amount of time, your limits should support that promise rather than quietly work against it. Overly strict idle rules can cause unexpected disconnects. Rules that are too loose can leave unused sessions open. Decide what fits your service, then test it from a customer device.
5. Setting Authentication and Login Methods
Authentication is how the router decides whether a customer may use the network. For paid WiFi, you choose how customers prove who they are and how the router checks that proof. Your choice affects how easy login feels for customers and how much control you have as an operator.
Take your time here. A method that is simple for customers may give you less control. A method that gives you tight control may add steps for customers. Understanding hotspot authentication handling helps you weigh these choices clearly. Think about your customers, your staff, and how you want to manage accounts day to day. The sections below look at each option so you can choose with a clear view of the tradeoffs. These decisions define your MikroTik HotSpot authentication methods.
5.1 HTTP and HTTPS Login Options
HTTP login and HTTPS login describe how the login page and the customer’s credentials travel between the device and the router. HTTPS protects that exchange from being read in transit, while HTTP does not offer that protection.
When choosing, think about what customers type into the login page and how much protection you want around it. Consider also how customer browsers and devices react to the option you pick, since a login flow that confuses browsers will confuse customers. Whichever you choose, test it on more than one kind of device before you open the service to paying users.
5.2 Trial Access and MAC Based Login
Trial access lets a new visitor try your service briefly before they pay. It can build confidence and reduce hesitation, especially when customers are unsure the WiFi works well. The tradeoff is that trial access can be misused if it is too generous, so keep it modest and in line with your business goals.
MAC login recognizes a device by its hardware address so the customer does not need to sign in every time they return. It is convenient for repeat visitors. The tradeoff is that device addresses are not the same as people, so it suits some situations better than others.
If you want to know how to enable trial access and MAC login in MikroTik HotSpot, begin by deciding whether each one fits your service. Then enable only what you need, confirm it behaves as you expect, and make sure it does not let people bypass payment by accident.
5.3 Local Users and External Authentication Sources
Local users are accounts stored on the router itself. They are simple to understand and need no other system, which suits small operations. The downside is that account handling stays on the router, so growth can make it harder to manage.
External authentication means the router asks another system to confirm who a customer is. This can centralize account handling and make larger or more automated setups easier to run. It adds another system to maintain and keep available.
Match the choice to your size and how you create accounts. A small operator handling a few accounts by hand may be well served by local users. An operator who wants accounts created and managed elsewhere may prefer an external source.
6. Customizing the Login and Status Pages
The login page and status page are the face of your service. They are what customers see when they connect, and often the only part of your system they ever notice. Clear pages cut confusion, reduce support questions, and help customers complete payment with fewer mistakes.
A good login page tells customers what to do next. A good status page tells them where they stand once connected. Both should be easy to read on a phone, since that is where most customers will see them. Clear pages are a key part of reliable captive portal design, because the best technical setup still fails if customers cannot understand the page in front of them. This is the core of MikroTik HotSpot login page customization.
6.1 Locating and Editing Default Page Files
RouterOS ships with default page files, and they are your starting point. Customization begins with understanding where those files fit in your workflow: they are the templates the router shows to customers, and your edits change what customers see.
Edit with care. Keep a copy of the original default files before you change anything, so you always have a clean version to return to. Make small changes, one at a time, and check the result after each one. Avoid removing parts of the page you do not fully understand, because some elements support the login process itself. Work on a test device first, not on a live customer session.
6.2 Adding Usage Instructions and Service Terms
Customers should not have to guess how your service works. Add short usage instructions to the login page that explain how to pay, how to log in, and what to do next. Use plain words and short sentences.
Service terms belong there too. Tell customers the key rules of your service, such as how access is granted and what happens when a session ends. Keep the terms brief and easy to find, rather than hiding them in long text. When customers know the rules up front, they ask fewer questions later, and disputes become easier to settle.
7. Configuring Walled Garden Access
The walled garden is a short list of exceptions that the router allows before a customer logs in. Normally an unauthenticated customer cannot reach anything except the portal. The walled garden opens specific doors so that certain destinations remain reachable.
For paid WiFi, this is essential. A customer who has not paid yet still needs to reach the place where they pay. If the router blocks that destination, the customer is stuck, no matter how well the rest of your portal works. Good MikroTik walled garden configuration keeps the payment path open while everything else stays closed to unpaid users.
7.1 Allowing Payment Related Hosts Before Login
Customers can only pay if their device can reach your payment destinations before they log in. So you need to know how to allow payment hosts in MikroTik walled garden before login. Start by identifying every destination a customer’s device must reach to complete a payment. Then allow those destinations in the walled garden.
Be thorough. A payment page often relies on more than one destination, and missing one can leave the page half loaded or broken. Allow what is needed for payment to work, and nothing more. The aim is a narrow, deliberate opening rather than a wide one.
7.2 Reviewing Allowed and Blocked Destinations
Review your walled garden regularly. List what you allow and ask whether each entry is still needed for payment. Remove anything that no longer serves that purpose, since every unnecessary exception is a possible way around payment.
Then check from the other side. Confirm that destinations customers need are open, and that general internet access stays closed until a customer is authenticated. If payment fails, look for a missing allowance. If unpaid users get through, look for an entry that is too broad. The goal is to keep payment flow open and unpaid access closed.
8. Linking Payment Confirmation to Access Activation
Behind every paid WiFi service is a simple business rule: access follows confirmed payment. A customer pays, the payment is confirmed, and only then does the network grant access. The portal is where the customer sees this, but the logic behind it is what protects your revenue.
Treat this as a flow, not a single step. Payment is confirmed, an account or access entitlement is created, and the customer can log in and use the service. Keep that order strict. Activating access before confirmation invites lost revenue, and delaying activation after confirmation frustrates customers who have already paid. If you want to read more on how to connect router billing platform tools to a MikroTik router, that is a good next step once your portal is working. This section covers the logic only, so adapt it to the way your own payment process confirms payments.
8.1 Account Creation After Confirmed Payment
Account creation should always follow confirmed payment, never come before it. Once the payment is confirmed, the customer receives the login details or access they paid for. That is the core of how to link payment confirmation to WiFi access activation in MikroTik: confirmation triggers activation, and nothing else does.
This order protects you from giving away access that was never paid for, and it protects customers from confusion about whether their payment worked. It is the foundation of MikroTik paid WiFi access activation. Make sure customers understand what happens after they pay, so they know to expect their access and what to do with it.
8.2 Duration Limits and Session Expiry Behavior
Duration limits define how long a paid customer’s access lasts. Session expiry is what happens when that time ends. Be clear with customers about both, because surprise is the main cause of complaints.
Tell customers how long their access lasts and what they will see when it ends. Make sure your limits match what you sell, and that the expiry experience guides customers to pay again rather than leaving them wondering what went wrong. After you set these rules, test them from a customer device so you know the real behavior matches the promise.
9. Testing, Monitoring, and Ongoing Maintenance
A captive portal is not a set-and-forget feature. Testing and monitoring are normal habits for any operator who wants stable paid access. Test after every change, watch how the service behaves, and review it on a regular schedule. This is the heart of MikroTik HotSpot monitoring and maintenance.
Small problems grow when nobody looks. A walled garden entry that stops working, a profile limit that causes disconnects, or a page that breaks on a certain device can all go unnoticed until customers complain. When you learn how to monitor active hotspot users, you catch these issues earlier and fix them before they affect your revenue.
9.1 Connection Testing From an Unauthenticated Device
The best way to see what your customers see is to become one. Here is how to test MikroTik captive portal from unauthenticated device: use a phone or laptop that has never logged in to your service, join the WiFi, and open a browser.
Watch each stage closely:
- Does the device connect and receive an address?
- Does the browser redirect to your login page?
- Does the page load fully and look correct?
- Can you reach the payment destination before logging in?
- After you log in, does access open as expected?
Test on different devices and browsers, since they do not all behave the same way. If any stage fails, you have found where to look.
9.2 Reviewing Logs and Active HotSpot Sessions
Logs record what the router has been doing, including login failures and other events. Review them to spot patterns, such as repeated failed logins or unusual activity. Active sessions show you who is connected right now. Reviewing them helps you see unexpected disconnects and notice whether usage is heading toward the limits of your setup.
Make this a habit rather than a reaction. Look at logs and active sessions on a regular basis, and again whenever customers report a problem. Over time you will learn what normal looks like, which makes abnormal behavior much easier to see.
10. FAQ
10.1 What causes the login page to fail to appear after connecting?
Usually the cause is in setup, not in the customer’s device. Check that the HotSpot server is attached to the correct customer-facing interface and that devices receive an address. Then confirm the DNS name resolves properly for unauthenticated customers. Finally, make sure your login flow is ready and the server is enabled. Testing from an unauthenticated device usually shows quickly which part is failing.
10.2 How are separate HotSpot servers used on multiple interfaces?
You can run a separate HotSpot server for each customer-facing interface. Each server handles only the customers on its own interface, so you can manage each area on its own terms. This keeps customer flows separate and makes it easier to see where a problem is happening. Plan each server’s interface and address pool carefully so they do not overlap.
10.3 Which login method should be selected for username and password access?
Choose the method that supports username and password login and fits your customers’ devices and your comfort with the protection it offers. Think about how customers will receive and enter their details, and whether your accounts are local or external. Then test the login on several devices before you rely on it.
10.4 Why is a payment site still blocked before login?
Most often, the walled garden does not cover every destination the payment page needs. Review your allowed entries and compare them with everything the payment page uses. A missing destination can leave the page blocked or partly loaded. Also check that your entries are correct and still in place. Retest from an unauthenticated device after each fix.
10.5 How are login page changes applied and reverted?
Apply changes carefully and in small steps, checking the result after each one. Always keep a copy of the original default files and a current configuration backup. If a change causes problems, restore the earlier copy and check again. Safe editing habits make reverting quick and low risk.
10.6 What should be checked when users disconnect unexpectedly?
Start with your profile limits, since session limits and idle timeouts can end a connection that customers expected to continue. Then review session behavior and your duration rules, and compare them with what you told customers. Look at the logs for related events, and check active sessions to see what happened to the affected users.