1. Introduction to Connecting a MikroTik Router to a Hotspot Billing Platform
Running a hotspot from local user lists on a single router works until you need to answer simple questions: who is online right now, which package did they buy, and how much have they used? Central authentication, billing, and usage control answer those questions in a single place. The router stops being the place where decisions are made and becomes the place where decisions are enforced.
That split is the core idea behind MikroTik hotspot billing. The platform decides who may log in and under which limits. Your RouterOS gateway lets the traffic through, applies the limits, and reports what happened. In short, you need to connect MikroTik router to hotspot billing platform services, then prove the connection works from login to logout.
A hotspot billing system for MikroTik depends on several pieces working together:
- Registration of the router with the platform, so the platform recognizes it.
- RADIUS settings on the router, so login and usage messages reach the right place.
- AAA settings, so hotspot and PPP logins are checked centrally.
- Hotspot linkage, so the login page hands decisions to the platform.
- Profiles, so each user receives the right limits.
- Accounting, so sessions are tracked accurately.
- Testing, so you find problems before customers do.
By the end of this guide you will know how to approach a MikroTik hotspot setup that uses a RADIUS server for MikroTik hotspot logins, how to check each layer as you go, and how to isolate faults calmly when something does not behave. Each section builds on the one before it, so work through them in order.
2. Prerequisites Before Starting the Connection
Most failed integrations are not caused by a wrong setting in RADIUS or the hotspot. They come from missing groundwork. Before you touch any RADIUS or hotspot settings, gather access, confirm the network is ready, and collect the details the platform will ask for.
Think about how you will reach the router during the work. Many operators also plan for remote router access so they can make and verify changes without a site visit. Whichever route you choose, it needs to stay available while you work, because you will be changing authentication settings on a live gateway.
2.1 Required Router Access and Firmware Checks
You need full administrative access to the router. Read-only or limited accounts will get you part of the way and then block you at the exact moment you need to save a change. Confirm that your management connection is stable too. A session that drops halfway through an authentication change can leave the router in a half-configured state, and that is hard to untangle.
Next, look at the state of RouterOS itself. Confirm that the router runs a supported RouterOS release and that the hotspot and RADIUS features are present and working. Check that the system clock is sensible, since accounting records and session limits rely on accurate time. It also helps to export or back up the current configuration before you start, so you have a clean way to return if a change goes wrong.
2.2 Required Billing Platform Credentials and Network Details
On the platform side, make sure you can sign in with an account that is allowed to manage routers. Then collect the details you will need later:
- The router identity details the platform asks for when you register a device.
- The address the platform will see when your router contacts it.
- The address or name of the platform’s RADIUS service, so the router knows where to send requests.
- The shared secret, or a clear idea of how it will be generated and passed to you.
Treat the shared secret with care from the start. Plan where it will be stored, who is allowed to see it, and how you will replace it if it is ever exposed. Also confirm that the router can reach the platform over the network, because a blocked path produces failures that look like configuration errors. With these items ready, you can move to registration.
3. Registering the MikroTik Router as a Network Access Device
In RADIUS terms, your router is a Network Access Device, sometimes called a NAS. It is the device that stands between users and the network, and it asks the platform to approve logins and record usage. The platform will only answer requests from devices it knows. Registering the router tells the platform which requests to trust, and which customer or site those requests belong to.
If you manage many gateways, automated router provisioning is worth exploring as a way to repeat registration steps consistently. For a single router, doing it by hand is perfectly fine. Either way, the goal is the same: the platform must recognize your router before any authentication traffic arrives.
If you are searching for how to add MikroTik router as RADIUS client, this is that step. Some platforms use the term client and others use Network Access Device, but the purpose does not change.
3.1 Adding the Router IP Address and Shared Secret
Registration rests on two things: the address identity of the router and the shared secret. The address identity tells the platform which device is speaking. The platform matches incoming requests against what you registered, so the address must be the one the platform actually sees. If the router sits behind another network device that changes addresses, think about which address will arrive at the platform and register that one.
The shared secret is the proof that the router and platform trust each other. Both sides must hold exactly the same secret. A small difference, such as a stray space or a mistyped character, causes every request to fail without an obvious message. Handle it carefully:
- Copy it rather than retyping it where you can.
- Avoid sending it through open chat or email.
- Keep it out of screenshots and shared notes.
- Rotate it if you suspect anyone who should not have it has seen it.
3.2 Verifying Registration Status
Before you move on, confirm that the platform shows the router as registered and active. Check that the identity details look right and that the router is tied to the correct account or site. This takes a moment, and skipping it is one of the most expensive shortcuts you can take.
Here is why. If registration is missing or wrong, the platform will ignore or reject everything the router sends. Later, when you test logins, you will see failures and be tempted to blame RADIUS settings, AAA order, or the hotspot profile. You could spend a long time chasing the wrong cause. Confirm registration now, and you can rule it out later.
4. Configuring RADIUS Settings on MikroTik RouterOS
RADIUS is the conversation between your router and the billing platform. When a user tries to log in, RouterOS asks the platform whether to allow it, and the platform answers with a decision and, often, the limits that should apply. After that, RouterOS reports usage back so the platform can bill accurately. Authentication and accounting both travel over RADIUS, which is why this step matters so much.
For a wider look at the topic, see this piece on RADIUS authentication for hotspots. In this section we focus on MikroTik RADIUS configuration from the router side. If you want to know how to configure RADIUS server in MikroTik RouterOS, think of it as three jobs: tell the router where the platform is, tell it which functions to use, and confirm the two can talk.
4.1 Adding the RADIUS Server Entry
On the router, you add the billing platform as a RADIUS server. The entry points RouterOS at the platform’s address and gives it the shared secret you registered earlier. It also tells the router which services should use that server, so make sure the hotspot is included.
Keep the entry clean. Use the same secret on both sides, point to the right platform address, and avoid leaving old or test entries in place. A stale entry that points somewhere else can quietly take requests that should go to the platform. When this entry is correct, the router can send authentication and accounting requests to the right place.
4.2 Setting Authentication and Accounting Ports
Authentication and accounting are separate functions, and each has its own endpoint on the platform. Authentication handles the question of whether a user may log in. Accounting handles the record of what the user did. The router must send each kind of request to the matching endpoint.
Use the authentication port and accounting port that your platform documents for your account, and enter them exactly as given. Do not assume them from memory or from another setup. If the two are swapped or mismatched, logins may appear to work while billing records never arrive, or the reverse. Mixed-up endpoints are a common reason a MikroTik hotspot setup seems fine in testing and then fails in production.
4.3 Testing RADIUS Server Reachability
Before you rely on real logins, check that the router and platform can communicate. At this stage you are not testing a user, only the path. Success means three things: the router can reach the platform over the network, the platform recognizes the router as registered, and the shared secret matches on both sides.
Look for a clear sign on either end that a request arrived and was answered. If nothing arrives, suspect the network path or the registered address. If requests arrive and are rejected, suspect registration or the secret. Sorting out reachability now saves you from guessing later, when hotspot settings add more variables.
5. Setting Up AAA Authentication for Hotspot Logins
AAA stands for authentication, authorization, and accounting. In plain terms, authentication asks who the user is, authorization decides what that user may do, and accounting records what they did. For a hotspot, those three ideas line up with a login check, a set of limits, and a usage record.
This is where MikroTik AAA authentication comes in. RADIUS defines how the router talks to the platform. AAA settings define which router services actually use that conversation. You can have a perfect RADIUS entry and still see local checks win if the AAA scope and order are not set the way you expect.
5.1 Enabling AAA for PPP and Hotspot Services
If you are working out how to enable AAA for MikroTik hotspot login, the answer is to turn on RADIUS use for the services that matter. Keep the scope limited to the MikroTik hotspot and PPP. Enabling it for hotspot logins means the router asks the platform to approve users instead of relying only on local records. Enabling it for PPP means PPP logins can be checked centrally as well.
Only enable what you actually use. If you do not run PPP logins, do not widen the scope just in case. A tight scope is easier to test and easier to explain to the next administrator who inherits the router.
5.2 Ordering Login Methods and Fallback Behavior
Order matters because the router has to know which source to trust first. If local checks come first, a local record may approve a user before the platform ever sees the request. That can bypass billing, package limits, and accounting. If the platform comes first, the router asks it before anything else.
Fallback is what happens when the first source does not answer. In practice, you have to decide whether the router should fall back to a local method when the platform is unreachable, or refuse logins until the platform returns. Neither choice is right for every operator. Consider the trade-off: a fallback keeps people online during an outage but may allow logins that are not tracked, while no fallback protects billing but blocks everyone during an outage.
To keep behavior predictable, pick one clear primary source, decide deliberately on a fallback, write the decision down, and test both the normal path and the failure path.
6. Configuring Hotspot Authentication Through the Billing Platform
With RADIUS and AAA in place, the next job is making the hotspot itself hand login decisions to the platform. This is the heart of RouterOS hotspot configuration for a billing setup. The local hotspot service still shows the login page and controls access to the network, but the decision about who gets in comes from the platform.
6.1 Creating a Hotspot Server Profile
A MikroTik hotspot server profile is a set of behaviors that the hotspot service follows. At a high level, it controls how users are identified, how they authenticate, and which login methods are allowed. It also holds the settings that decide whether the hotspot consults RADIUS.
Create or review the profile that your hotspot service uses, and make sure you know which hotspot service it is attached to. When a router carries more than one hotspot service, it is easy to edit the wrong profile and wonder why nothing changes. Give the profile a clear name so you can tell it apart later.
6.2 Linking the Hotspot to RADIUS Authentication
This is the step many people mean when they ask how to link MikroTik hotspot server profile to RADIUS. You enable RADIUS use in the profile that your hotspot service runs on. After that, login attempts are validated by the platform, not just by local records.
If you skip this link, the rest of your work stays invisible to users. The hotspot will keep using whatever it used before, and your platform will see nothing. When something looks configured but has no effect, check that the hotspot is attached to the profile you edited and that the profile has RADIUS enabled.
6.3 Checking the Login Page Flow
Now look at the experience from the user’s side. A healthy login page flow looks like this: a user connects to the network, opens a page, and is redirected to the login page. They enter their credentials or voucher details, and the platform approves them. They are then taken onward to the open internet, or to whichever page you set for success.
Failure should be just as clear. A wrong credential should produce a readable message, not a blank page or an endless loading state. An expired or exhausted package should be rejected in a way that tells the user what happened. Walk through success and failure yourself. If the redirect never appears, the problem is in the hotspot or network setup. If the page appears but the login is rejected unexpectedly, look at registration, the secret, and the platform side.
7. Creating Bandwidth Profiles and Session Limits
Once users can log in through the platform, you need to control what they receive. Speed, data, and time controls serve three purposes: they keep usage fair so one user does not crowd out others, they let you separate packages into clear tiers, and they give you control over how long sessions last.
The platform decides which limits apply to a user, and the router enforces them. For a deeper read on that idea, see this article on router enforced speed limits. Here we focus on how to create bandwidth profiles in MikroTik hotspot setups so the right limits reach the right users.
7.1 Defining Speed and Data Limits
MikroTik bandwidth profiles describe what a user may consume. A speed limit shapes how fast a session can move data. A data limit caps how much a session or package can use in total. Together they define what a package offers.
Choose limits based on what your network can sustain and what your packages promise. Name profiles so their purpose is obvious to anyone who reads the list later. Consistent naming also helps when you compare what the platform assigns against what the router actually applies.
7.2 Mapping Profiles to User Groups
Profiles only help when they reach the right users. That is the role of a user group. A user group collects users who should share the same limits, and the profile is attached to that group.
A simple example: you might have a standard group for everyday users and a higher use group for users who bought a bigger package. Each group maps to its own profile, so the standard group gets the standard limits and the higher use group gets more generous ones. When a user logs in, the platform identifies their group and passes the matching limits to the router.
Check this mapping whenever you add a package. A user placed in the wrong group will receive the wrong limits, and the problem will look like a router fault when it is really a mapping error.
7.3 Applying Session Timeouts and Idle Limits
Time controls come in two kinds, and they do different jobs. A session timeout ends a session after the allowed time has passed, which enforces what a user paid for. An idle timeout ends a session when the user stops using the connection, which frees capacity that would otherwise sit unused by an inactive device.
You need both. Without a session timeout, a user could stay connected beyond their package. Without an idle timeout, abandoned sessions occupy capacity for no benefit. Review MikroTik session timeout settings together with your package design, and choose values that match what you sell. Whatever you choose, test it, because a limit you never tested is only a hope.
8. Enabling RADIUS Accounting and Session Tracking
Accounting is the record of what happened. It supports billing accuracy, because charges and package use depend on correct usage data. It supports session visibility, because you can see who is connected and for how long. It also supports troubleshooting, because a record of events shows you where a session went wrong.
RADIUS accounting MikroTik setups depend on the router sending usage messages to the platform’s accounting endpoint, which you set up earlier. Authentication tells the platform that a user got in. Accounting tells it what happened afterward.
8.1 Turning On Interim Accounting Updates
If you want to know how to enable RADIUS interim accounting on MikroTik, start with the concept. Interim accounting means the router sends periodic updates while a session is active, rather than only at the beginning and end. Those updates keep the platform informed about live usage.
This improves tracking reliability. If a router restarts or loses connectivity in the middle of a session, a final record may never arrive. With interim updates, the platform still holds a recent picture of the session. It also lets the platform enforce limits closer to real time, since it sees usage as it grows. Turn on interim updates in the accounting settings, and confirm the platform side accepts them.
8.2 Checking Start Stop and Update Records
A well-tracked session leaves a trail of three kinds of records:
- A start record confirms that the session began and that the router reported it.
- Update records confirm that the session stayed active and that usage was being reported along the way.
- A stop record confirms that the session ended and that final usage was recorded.
Check all three during a test session. A start without updates suggests that interim accounting is not working. Updates without a stop suggest that sessions are not closing cleanly. A stop without a start points to a tracking mismatch. Reading these records as a lifecycle gives you quick clues about where to look.
9. Testing the Full Connection and Fixing Common Errors
Each layer you checked so far proves one part of the chain. A full end to end test proves that the parts work together. Do it before you hand the hotspot to real users, and repeat it after any significant change.
When something fails, stay calm and work from the outside in. Start with registration and reachability, then move to secrets and RADIUS entries, then AAA, then the hotspot link, and finally profiles and accounting. Changing several things at once makes it impossible to tell which change helped.
9.1 Running an End to End Login Test
A MikroTik hotspot login test should use a test credential or a voucher style login created on the platform for this purpose. Connect a test device to the hotspot and follow the whole journey:
- Confirm the login page appears through the expected redirect.
- Sign in and confirm the platform approves the login.
- Confirm you gain network access.
- Confirm the profile applied matches the group and package you set up.
- Check that start and update records appear on the platform while the session runs.
- Log out, or let the session end, and confirm the stop record arrives and access ends.
Test a bad credential as well, to confirm the rejection behaves the way you expect. A test that only covers success leaves half the behavior unchecked.
9.2 Fixing Authentication Failures
If you need to know how to fix MikroTik RADIUS authentication failure, work through the common categories in order:
- Registration mismatch: Confirm the platform shows the router as registered and that the registered address matches what the platform sees.
- Secret mismatch: Confirm the secret is identical on both sides, with no stray characters.
- Server reachability: Confirm the router can reach the platform and that nothing in between blocks the path.
- AAA order and scope: Confirm RADIUS is enabled for hotspot logins and that it is not overridden by a local method placed first.
- Hotspot linkage: Confirm the hotspot service uses the profile you edited and that the profile has RADIUS enabled.
If all of those check out, review the platform side for the user account itself, since an expired or disabled user will be rejected correctly.
9.3 Fixing Accounting Gaps
Accounting problems are quieter than login failures. Users may connect without trouble while the records are incomplete. Check these categories:
- Missing updates: Confirm interim accounting is on and that the accounting endpoint is correct.
- Sessions not closing cleanly: Look at session and idle timeouts, and confirm that stop records are reaching the platform.
- Tracking mismatches: Compare what the router shows as active against what the platform shows, and look for sessions that exist on only one side.
Interim updates and regular record checks help here because they expose gaps early, while a session is still running, instead of after a billing dispute.
That completes the path. You registered the router, pointed it at the platform, set up AAA, linked the hotspot, defined profiles, enabled accounting, and tested the result. If you came here wanting to connect MikroTik router to hotspot billing platform services with confidence, the habit to keep is simple: verify each layer before building on it, and rerun your end to end test after every change.
10. FAQ
10.1 What details are needed to register a MikroTik router as a network access device
You need the router identity details the platform asks for, the address the platform will see the router using, and the shared secret. The router must also be registered on the platform side under the correct account or site. Both sides must hold the same secret.
10.2 Which ports are used for RADIUS authentication and accounting
Authentication and accounting are separate functions, and each has its own endpoint on the platform. Use the authentication port and accounting port that your platform documents for your account, and enter them as given on the router.
10.3 Why does hotspot login fail even when RADIUS settings look correct
Common causes sit outside the RADIUS entry itself. Check that the router is registered on the platform, that AAA is enabled for hotspot logins and is not overridden by a local method, and that the hotspot profile is linked to RADIUS. Also review the login page flow, and confirm the router can still reach the platform.
10.4 How do bandwidth profiles control speed and session time
A bandwidth profile defines the limits for a user or user group, including speed and data controls and session and idle timeouts. The platform tells the router which profile applies when a user logs in, and the router enforces those limits for the session.
10.5 How can you confirm accounting records are being received
Run a test session and watch the platform side. During the session, look for a start record and update records. After the session ends, look for a stop record. If any of these are missing, check the accounting endpoint, interim accounting settings, and registration.
10.6 What should you check if users stay online after their session ends
Review the session timeout and idle timeout settings first. Then confirm that stop records are reaching the platform and that the platform is tracking sessions correctly. Finally, check that the hotspot is linked to RADIUS, since a hotspot using local records will not receive the platform’s limits.