1. Introduction: Why Centralized Authentication Matters for Hotspot Billing
If you run pay per use WiFi, you have probably had this moment. A customer says they paid, the login page accepted their details, and yet the internet does not work. Or the opposite happens: a customer’s plan has expired and they are still online. In both cases, the problem usually sits in the gap between what the login screen shows and what the backend actually decided.
That gap is why centralized authentication matters for hotspot billing. When every router or access point makes its own decisions with its own local list of users, you end up maintaining the same rules in many places. Plans drift out of sync, usage is counted inconsistently, and troubleshooting becomes guesswork. Centralized authentication moves those decisions into one place, so every access point asks the same question and gets the same answer.
This article explains how RADIUS authentication for hotspot billing works, in practical router administration terms. RADIUS handles three jobs, and it helps to keep them in simple language from the start:
- Authentication answers the question “who is this, and are their credentials valid?”
- Authorization answers “what is this person allowed to do, and under what limits?”
- Accounting answers “what did this person actually use, and for how long?”
Once you can separate these three jobs, login failures and billing gaps become much easier to track down. We will walk through the components, the exchange between them, the policies applied after login, the accounting records that support billing, and the failure points you are most likely to meet.
2. Core Components of RADIUS Based Hotspot Authentication
RADIUS authentication for hotspot billing depends on three parts working together: a device that guards the network, a server that makes decisions, and a store that holds account records. Keeping these roles separate in your mind is the single most useful habit for troubleshooting. If you are setting up MikroTik hotspot billing or any similar arrangement, these same three roles apply in the same way, even though the screens and menus differ.
2.1 Role of the Network Access Device
The network access device is the piece of equipment that customers actually connect to. In a hotspot, that is your router or access controller. Its role has two sides.
First, it requests access decisions. It does not decide on its own whether a user may come online. When a customer tries to log in, the device packages up what it knows and asks the RADIUS server for a verdict.
Second, it enforces that verdict. If the server says yes, the device lets the customer through and applies the limits the server sent back. If the server says no, the device keeps the customer blocked. The device also reports usage back to the server during the session, which we cover in the accounting section.
For you as an administrator, this means the device is the messenger and the enforcer, not the judge. If a plan rule is wrong, fixing it on the device alone will rarely help.
2.2 Role of the RADIUS Server
The RADIUS server role is to be the central decision maker. It receives requests from the network access device, checks them, and sends back a response. This is what makes centralized authentication for hotspot billing possible: one server, one set of policies, many devices asking it questions.
The server does more than say yes or no. It also decides under what policy a user is allowed in, such as how long the session may last and what speed or access rules apply. And it receives the accounting records that later feed usage based billing.
Think of the RADIUS server as the front desk of a building. The device is the door that opens or stays shut, and the server is the person who checks the guest list and hands over the right badge.
2.3 Role of the User Account Store
The user account store is where the account records live. It is the source the RADIUS server checks during credential validation. Depending on your setup, it might hold usernames and passwords, device addresses, or voucher codes, along with the plan each account belongs to.
The RADIUS server does not invent answers. It looks up the account in the user account store and compares what the user supplied against what is recorded. If the account exists, the credentials match, and the plan is still valid, the server can approve access. If the record is missing, expired, or wrong, the server has nothing to approve.
This is why many “mystery” login failures turn out to be simple record problems. The user typed something correctly, but the account store holds something different, or holds nothing at all.
3. How Hotspot Login Differs from RADIUS Policy Decisions
One of the most common sources of confusion for hotspot operators is treating the login page and RADIUS as the same thing. They are not. The login page is the front of the house. RADIUS is the back office. If you want a refresher on the front end, how captive portals work is a good companion topic, but here we focus on where the portal stops and RADIUS begins.
3.1 Captive Portal Credential Collection
Captive portal login is credential collection. A customer connects to your WiFi, tries to open a website, and gets redirected to a page asking for something: a username and password, a voucher code, or a simple confirmation. The captive portal gathers that information and passes it along.
That is all the captive portal does in this story. It collects. It does not know whether the credentials are valid, whether the plan has run out, or how much the customer is allowed to use. It simply hands over what the customer entered so the network access device can ask the RADIUS server.
So when a customer says “the login page is not working,” ask a sharper question. Is the page failing to load, or is it loading fine and the backend is rejecting the details? Those are two different problems with two different fixes.
3.2 RADIUS Authentication and Authorization Checks
RADIUS authentication and authorization are the checks that decide the outcome. Authentication confirms that the credentials are genuine. Authorization decides whether access is allowed and under what policy.
A user can pass authentication and still be denied on authorization. For example, the password is correct, but the plan attached to the account has ended. The identity is real, but the permission is gone. Likewise, two users can both authenticate successfully and receive different limits, because their plans differ.
When you troubleshoot, keep this two-step picture in mind. First ask whether the server believed the credentials. Then ask what the server said the user was allowed to do. Many billing disputes live in that second question.
4. Stages of a RADIUS Authentication Exchange
At its heart, how RADIUS authentication works for hotspot billing is a request and a response. The network access device asks, the RADIUS server answers, and the device acts on the answer. Let us walk through it in order.
4.1 Access Request and Credential Validation
Everything starts with a RADIUS Access Request. This is the message the network access device sends to the RADIUS server when a customer tries to get online. Understanding how Access Request and credential validation works gives you a clear mental model for most login problems.
At a generic level, here is what is in a RADIUS Access Request:
- User identity: the username, voucher code, or device address the customer supplied or that the device observed.
- Credential material: the password or secret the customer entered, protected in transit rather than sent in plain view.
- Device identification: details that tell the server which network access device is asking.
- Session context: information about the connection attempt, such as which interface or access point the customer arrived through.
The device and server also share a secret, which lets the server confirm that the request really came from a trusted device. We return to that in the troubleshooting section.
Once the request arrives, the server performs credential validation. It looks up the identity in the user account store, compares the supplied credentials with what is recorded, and checks whether the account is in a usable state. Only then does it decide how to respond.
4.2 Access Accept, Reject and Challenge Responses
The server answers with one of three responses. Here is Access Accept vs Reject vs Challenge explained in practical terms.
A RADIUS Access Accept means the credentials passed and access is allowed. Importantly, an Accept usually carries more than a yes. It can include the authorization profile for the session, such as time limits and speed rules. The device reads these and applies them.
A RADIUS Access Reject means access is denied. The credentials may be wrong, the account may be unknown, or the plan may no longer permit access. The device keeps the customer blocked. When you see a customer stuck at the login screen, a Reject is often what happened behind the scenes.
A RADIUS Challenge response means the server needs more before it can decide. Instead of approving or denying, it asks for additional input, and the exchange continues with a follow up request. Many simple hotspot setups never use challenges, but it is useful to recognize them so you do not mistake a request for more information for a failure.
A quick way to remember them: Accept opens the door with instructions, Reject keeps it shut, and Challenge says “one more thing, please.”
5. Authorization Profiles Applied After Successful Authentication
Authentication proves who someone is. What happens next depends on the authorization profiles applied after authentication. An authorization profile is the bundle of rules the server attaches to a successful login, and it is how session limits are applied after authentication. This is where your plans become real. If you offer data cap internet packages or other plan types, the profile is the mechanism that tells the access device what each customer is entitled to.
The key idea is that the device does not need to know your plans in advance. The server sends the rules along with the Accept, and the device enforces them for that session.
5.1 Session Duration Controls
Session duration controls set how long a customer may stay connected. The server includes a limit in the authorization profile, and the network access device ends the session when that limit is reached.
This is what makes a time-limited plan work in practice. A customer who bought a short plan and a customer who bought a longer one both log in the same way, but their profiles carry different duration limits. When the limit is reached, the device closes the session and the customer must log in again under a valid plan.
If customers complain that sessions end too early or run too long, check the duration value the server is actually sending, and confirm the device is honoring it.
5.2 Bandwidth and Access Policy Assignment
Bandwidth policy assignment tells the device how much speed capacity a user’s session is allowed to consume. Access policy assignment goes beyond speed and covers what the user is permitted to reach or do while connected. In generic terms, both are attributes returned in the authorization profile and applied by the device for the length of the session.
The practical benefit is consistency. Instead of configuring limits user by user on each device, you define a policy once on the server and assign it to plans. Every device that receives the Accept applies the same rules.
When a customer reports getting the wrong speed or the wrong level of access, look at which profile their account was assigned. A wrong plan assignment on the account is a far more common cause than a fault in the device.
6. Accounting Flow That Supports Usage Based Billing
Authentication and authorization decide who gets in and under what rules. RADIUS accounting records what happens next. This is how RADIUS accounting supports usage based billing: the network access device sends a stream of messages to the server describing each session, and the server keeps those records as the basis for billing. If you want to see sessions as they happen, you can monitor active hotspot users, but the billing record itself comes from the accounting flow described here.
The accounting flow for RADIUS accounting for billing has three moments: a session starts, it continues, and it ends.
6.1 Session Start Records
A RADIUS session start message is sent by the network access device when a customer’s session begins, right after access is granted. The session start record marks the moment a session came into existence.
Its purpose is to open the billing record. It tells the server that this user is now online, through which device, and under which session. Without a start record, the server has no clear beginning to measure usage from.
6.2 Interim Updates During Active Sessions
RADIUS interim updates are periodic messages the device sends while a session is still active. They carry a running picture of usage so far.
Here is why interim updates matter during active sessions. Imagine a customer stays online for a long stretch, and the device loses power or the link to the server drops before the session ends cleanly. If you only had a start and a stop, you would have a start and nothing else. Interim updates give the server checkpoints along the way, so it still knows roughly what was used up to the last update received.
They also help you see current usage on long sessions, not just after the customer has left, which supports both fair billing and enforcement of plan limits.
6.3 Session Stop Records and Closure
A RADIUS session stop message is sent when a session ends, whether the customer logged out, the session limit was reached, or the connection was cut. The session stop record contains the final totals for the session.
This is how session stop records close billing. The stop record tells the server the session is over and provides the final usage figures, so the billing record can be finished and the session no longer counts as active. A session that has a start record but no stop record can look like it is still running, which creates confusion in both billing and monitoring.
7. Authentication Methods Commonly Used for Hotspot Access
Hotspots do not all identify customers the same way. Over RADIUS, the exchange follows the same pattern regardless of method. What changes is what the user supplies and what the server checks. Here is a generic comparison of the three common approaches.
7.1 Username and Password Authentication
Username and password hotspot authentication is the most familiar method. The customer types an identity and a secret into the captive portal. The device places them in an Access Request, and the RADIUS server validates them against the user account store.
Its strength is that accounts are personal and can be reused across sessions and devices. Its weakness is that customers forget passwords or mistype them, which makes it a frequent source of Reject responses and support requests.
7.2 MAC Based Authentication
MAC based authentication identifies a device by its hardware address instead of asking the customer to type anything. The network access device sends the device address as the identity, and the RADIUS server checks whether that address is recognized and permitted.
This is convenient because returning devices can be admitted without a login screen. The tradeoff is that the address identifies a device, not a person, so it works best when you have a clear process for registering which devices belong to which plan. If a customer changes devices, the new address will not be known until it is added.
7.3 Voucher Code Authentication
Voucher code authentication lets a customer log in with a single code that represents a prepaid plan. It is popular for pay per use WiFi because it is simple for the customer and easy to sell.
Here is how voucher code authentication works over RADIUS. The customer enters the code in the captive portal. The device sends it in an Access Request, typically using the code as the identity. The RADIUS server looks the code up in the user account store, confirms it is valid and unused or still within its plan, and returns an Accept with the authorization profile tied to that voucher. From there, session limits and accounting work exactly as they do for any other method.
If a voucher fails, check whether the code exists in the account store, whether it has already been used up, and whether it is tied to the plan you expect.
8. Session Control Through Timeouts and Disconnect Messages
Once a session is running, you still need ways to control it. Plans such as time based internet packages rely on the session ending when it should, and sometimes you need to change or end a session before its natural end. RADIUS gives you two tools: timeouts that travel with the authorization profile, and messages the server can send to the device later.
8.1 Idle Timeout and Session Timeout Handling
These two timeouts control sessions in different ways, so it helps to keep them apart.
A session timeout is a limit on the total length of a session. When it is reached, the device ends the session no matter how active the customer has been. This is the control behind plan duration.
An idle timeout is a limit on inactivity. If the customer’s connection shows no traffic for the set period, the device ends the session. This protects you from sessions that stay open long after the customer has walked away, which would otherwise hold plan time or occupy resources unnecessarily.
Both values normally arrive in the authorization profile with the Accept. If sessions end at unexpected moments, check which timeout is firing. A customer who is cut off while actively browsing points to the session timeout. A customer who is cut off after stepping away points to the idle timeout.
8.2 Change of Authorization and Disconnect Requests
Timeouts are decided when the session starts. But what if you need to act on a session that is already running? That is where server initiated messages come in. These answer the question of what Change of Authorization and Disconnect messages are.
Change of Authorization is a message from the RADIUS server to the network access device asking it to change the rules of an active session. For example, a customer tops up a plan or moves to a different one, and the server asks the device to apply the new policy without forcing the customer to log in again.
Disconnect Requests ask the device to end an active session. You might use one when a plan is cancelled, an account is suspended, or a session needs to be cleared. The device ends the session, and the usual accounting stop record follows.
Both rely on the network access device being set up to accept these messages from the server. If a Disconnect Request has no effect, the first thing to check is whether the device is configured to listen for and trust messages from the server.
9. Common Failure Points in Authentication and Accounting
Most problems fall into two families: login failures, where authentication does not succeed, and billing gaps, where authentication works but the usage record is incomplete. Knowing which family you are in saves a lot of time.
9.1 Credential and Shared Secret Mismatches
Credential errors are the simplest failures. The user typed the wrong password, the voucher code was mistyped, the account does not exist in the user account store, or the plan has ended. In each case the server sends a Reject, and the customer stays blocked. Check the account record first before you suspect anything deeper.
A RADIUS shared secret mismatch is more subtle, and more disruptive. The network access device and the RADIUS server each hold the same shared secret. If the two do not match, the server cannot properly trust or read the device’s requests. The result is that every login fails, not just one customer’s, and the failures can look like ordinary rejections or like no response at all.
That “everyone fails at once” pattern is your clue. If one customer cannot log in, suspect their credentials. If all customers cannot log in, suspect the shared secret or the path between device and server. After any change to either side, confirm both hold exactly the same secret.
9.2 Network Interruptions and Missing Accounting Packets
Authentication can work perfectly while accounting quietly fails. A network interruption between the device and the server can mean that start, interim, or stop messages never arrive. These are missing accounting packets, and they leave holes in your records.
This is why lost accounting packets affect billing. The server can only bill from what it receives. If a stop record is lost, a finished session may look like it is still running, and usage may be overcounted or left open. If start or interim records are lost, usage may be undercounted. Either way, the billing record no longer matches what really happened.
To reduce the damage, watch for sessions that look unusually long or that have no recent updates, compare device-side session information against server-side records when numbers look wrong, and treat any interruption between device and server as a reason to review the affected sessions afterward.
10. FAQ
10.1 What is the difference between hotspot login and RADIUS authentication?
Hotspot login is the screen where the customer enters credentials. It only collects them. RADIUS authentication is the backend check that decides whether those credentials are valid, and RADIUS authorization decides what the customer may do afterward. The login page asks, and RADIUS decides.
10.2 What information is included in a RADIUS access request?
At a generic level, it includes the user identity (such as a username, voucher code, or device address), the credential material the customer supplied, details identifying the network access device making the request, and context about the connection attempt. The request is protected using the secret shared between the device and the server.
10.3 How does RADIUS authorization control hotspot session limits?
After a successful authentication, the server returns an Access Accept that carries an authorization profile. The profile includes values such as the session duration, idle timeout, and bandwidth and access policy. The network access device reads them and enforces them for that session.
10.4 Why is RADIUS accounting important for hotspot billing?
Accounting is the record of what each session actually used. Session start, interim update, and session stop records give the server a trail of usage, which is what usage based billing is built on. Without accounting, you can control access but you cannot reliably bill for it.
10.5 What happens when authentication succeeds but accounting packets are lost?
The customer gets online normally, but your billing record develops gaps. A lost stop record can leave a session looking open, and lost start or interim records can cause usage to be undercounted. The fix is to find and review the affected sessions and to check the network path between the device and the server.
10.6 How do disconnect messages end an active hotspot session?
The RADIUS server sends a Disconnect message to the network access device, naming the active session to end. If the device accepts it, the device terminates that session, and the accounting stop record closes out the billing. The device must be set up to accept these messages from the server for them to work.