Automated MikroTik PPPoE and HotSpot User Provisioning: Connect Billing Platforms, RADIUS, and Customer Access
Internet providers and WiFi operators often begin by creating MikroTik users manually. An administrator adds a PPPoE secret, creates a HotSpot account, assigns a speed profile, and then sends login details to the customer.
That process may work for a small test network. As the provider adds subscribers, locations, plans, agents, and payment methods, manual provisioning becomes slow and inconsistent. Staff may create duplicate usernames, apply the wrong package, forget to update a suspended account, or activate service before payment is confirmed.
Automated user provisioning connects the customer and billing platform to MikroTik access services. When a customer registers, pays, upgrades, renews, or expires, the system can create or update the correct PPPoE or HotSpot access record and apply the intended network policy.
Providers evaluating this workflow can
Important: Router models, RouterOS versions, RADIUS configuration, API permissions, payment methods, account plans, and platform features differ. Confirm compatibility and available controls before applying automated changes to production routers.
What is automated MikroTik user provisioning?
Automated provisioning is the process of creating, changing, suspending, or removing subscriber access records through software rather than manual router entry.
For a PPPoE subscriber, provisioning may create:
•Username and password
•PPP profile
•IP address or address pool
•Speed policy
•Session timeout
•Device or caller-ID rule
•Account expiry
•RADIUS authorization
For a HotSpot customer, provisioning may create:
•Voucher or username
•Captive-portal access
•Package assignment
•Time or data allowance
•Device limit
•Speed profile
•Router or location assignment
•Expiry status
A billing platform can trigger the provisioning event after a confirmed payment, approved installation, plan change, or renewal. The network then enforces the policy through MikroTik, RADIUS, or a supported API workflow.
To evaluate automated subscriber provisioning,
PPPoE and HotSpot provisioning compared
PPPoE provisioning
PPPoE is commonly used for residential broadband, fixed wireless, fiber, apartment networks, and business internet. Each subscriber receives an individual login and a service policy.
Provisioning normally involves creating or authorizing the customer account, assigning a profile or RADIUS attribute, allocating an IP address, and defining expiry or renewal behavior.
HotSpot provisioning
MikroTik HotSpot uses a captive portal. Customers may enter a username, password, voucher, or purchase credentials before receiving full internet access.
Provisioning may generate a voucher, attach it to a package, restrict session time, apply a data quota, limit devices, and connect the customer to a location or router.
Shared requirements
Both services need:
•Accurate customer records
•Clear packages
•Secure authentication
•Network policy mapping
•Payment confirmation
•Expiry and renewal rules
•Usage or session accounting
•Support and recovery procedures
Why automate MikroTik provisioning?
Faster customer activation
A confirmed payment or approved installation can create access without waiting for an administrator to log in to the router manually.
Fewer configuration errors
The system can apply a tested plan-to-profile mapping instead of relying on staff to choose the correct profile each time.
Consistent multi-router operations
Centralized provisioning helps the provider manage subscribers across several routers, towers, branches, hotels, cafés, or buildings.
Better billing and access alignment
When account status changes, the network policy can change according to a documented process. This reduces active service on unpaid accounts and incorrect restrictions on paid customers.
Easier support
A customer record can show the plan, router, package, payment state, username, device, IP, session, and expiry information together.
For providers seeking a connected billing and provisioning workflow,
The core provisioning architecture
A typical automated deployment has several layers.
Customer and billing platform
This layer stores customer details, service plans, invoices, payments, expiry, support records, and account status. It decides when a customer is eligible for access.
Provisioning service or integration
This layer translates the commercial plan into network instructions. It may use RADIUS, MikroTik API, a managed provisioning service, or another supported integration.
RADIUS server
RADIUS can authenticate PPPoE and HotSpot users, return service attributes, and receive accounting records. It is useful when the provider has many routers or needs centralized policy management.
MikroTik RouterOS
MikroTik acts as the access device. It accepts PPPoE or HotSpot connections, requests authorization, applies profiles, assigns addresses, and enforces network rules.
Payment and notification services
Payment gateways confirm purchases or renewals. SMS, WhatsApp, email, or portal notifications tell the customer what happened.
The exact components depend on the billing platform and network. Some platforms provision routers through API or managed configuration. Others rely on RADIUS or a combination of methods.
Step 1: Document the MikroTik network
Before enabling automation, document the current network. List:
•Router identity and location
•Router model
•RouterOS version
•WAN interface
•Subscriber interface or VLAN
•PPPoE server
•HotSpot server
•IP pools
•DNS settings
•Firewall and NAT rules
•RADIUS server
•Management addresses
•Access points
•Expected subscriber count
Separate customer traffic from router management. Use a dedicated management path, VLAN, or trusted address range where appropriate.
Back up existing configuration before connecting a billing or provisioning platform. Identify which settings are managed automatically and which custom settings must remain protected.
Step 2: Define packages before creating users
Provisioning should apply a known service package, not a collection of ad hoc settings.
A package may define:
•Package name
•Price
•Billing period
•Download speed
•Upload speed
•IP pool
•Data allowance
•Validity period
•Session timeout
•Idle timeout
•Device limit
•Grace-period policy
•Renewal behavior
For PPPoE, the package may map to a PPP profile or RADIUS attributes. For HotSpot, it may map to a user profile, voucher policy, time limit, data cap, or device rule.
Use consistent names across the billing platform, RADIUS database, MikroTik profiles, support documentation, and customer portal.
A plan called “Home 25” should have one clearly documented meaning. Avoid multiple profiles with similar names but different speed or expiry settings.
Step 3: Choose the provisioning method
RADIUS provisioning
RADIUS is often the best fit for centralized authentication and authorization. The billing platform or customer database stores the account, while the RADIUS server returns the access policy to MikroTik.
Advantages include centralization, accounting, multi-router support, and easier plan management. The provider must secure the RADIUS server, shared secrets, firewall rules, attributes, and failure behavior.
MikroTik API provisioning
An API-based workflow can add or modify router users, profiles, HotSpot settings, or other supported objects. It may be useful when the platform manages router configuration directly.
API provisioning must use restricted credentials, secure transport, strong permissions, audit logs, and careful handling of router reachability. Test whether an API update affects active sessions or only future logins.
Managed router provisioning
Some billing platforms offer a managed setup that configures hotspot, RADIUS, firewall, captive portal, or related files through an automated process. Confirm what the system changes, how rollback works, and how custom configuration is protected.
Providers can compare options by
Step 4: Configure PPPoE provisioning
A basic PPPoE provisioning process includes the following steps.
Create the subscriber access segment
Configure the bridge, Ethernet interface, VLAN, or access network that carries customer PPPoE traffic. Check VLAN tagging, MTU, and isolation.
Create IP pools
Define pools for residential, business, premium, restricted, or location-specific customers. Avoid overlapping ranges and document which router uses each pool.
Create PPP profiles
Create profiles that map to commercial packages. Define speed, DNS, session, and address behavior. Verify upload and download direction.
Enable authentication
Use local PPP secrets for a small test or RADIUS for centralized operations. If using RADIUS, configure trusted addresses, shared secrets, authentication, authorization, and accounting.
Create the PPPoE server
Configure the server on the correct subscriber-facing interface or VLAN. Set service name, authentication methods, one-session behavior, and other relevant options according to the network design.
Trigger provisioning
When a customer’s installation and payment are approved, the billing platform creates or enables the account. The customer receives credentials or the account becomes available through the assigned authentication system.
Test the client connection
Verify authentication, IP assignment, routing, DNS, speed, accounting, expiry, plan change, suspension, and restoration.
Step 5: Configure HotSpot provisioning
A HotSpot provisioning process normally includes:
Prepare the HotSpot gateway
Configure the correct interface, bridge, VLAN, address, DNS, DHCP behavior, NAT, firewall, and captive portal settings.
Create HotSpot profiles
Define the speed, session, idle, and device behavior for each package. Test how the profile behaves on phones, laptops, and multiple devices.
Configure local or RADIUS authentication
Small deployments may use local HotSpot users. Larger operations can use RADIUS to manage voucher and customer accounts centrally.
Generate vouchers or customer credentials
The billing platform creates a code or account linked to a package, location, payment, device, and validity rule.
Deliver access after confirmed payment
The customer receives the code or login details only after the payment status is confirmed. Pending or unmatched transactions should remain in review.
Track the session
Accounting should record login, logout, duration, IP address, router, data usage, and termination reason where supported.
Handle expiry and renewal
When the time, quota, or validity period ends, the account should become expired or restricted. A successful renewal should extend access according to the package rules.
Payment-driven provisioning
Automated provisioning should not start merely because a customer clicked a payment button. It should start after a verified payment event or approved manual action.
A safe sequence is:
1.The customer selects a package.
2.The billing system creates an order or invoice.
3.M-Pesa, Stripe, or another gateway processes the payment.
4.A server-side callback or webhook is validated.
5.The system checks customer reference, amount, currency, and order state.
6.The payment is marked successful.
7.Provisioning is queued.
8.The integration creates or updates the network account.
9.The system verifies the provisioning result.
10.The customer receives access and confirmation.
If provisioning fails after payment, do not create duplicate value. Place the transaction in a retry or support queue and give staff enough information to resolve it.
For an ISP evaluating payment-connected provisioning,
Provisioning status and idempotency
Every provisioning job should have a status. Useful states include:
•Queued
•Processing
•Provisioned
•Failed
•Retrying
•Suspended
•Deprovisioned
•Awaiting review
Idempotency prevents duplicate accounts or repeated renewals. If the same payment event or provisioning request arrives twice, the system should recognize the existing reference and avoid creating a second voucher or username.
Store a unique provisioning reference linked to the customer, invoice, package, router, and payment. Keep an audit history of what changed, when it changed, and which system performed the action.
Account changes and deprovisioning
Automation should cover more than new users. It should handle the full account lifecycle.
Plan upgrade
Update the commercial plan, apply the new profile or RADIUS attributes, and decide whether active sessions must be disconnected or reauthorized.
Plan downgrade
Confirm that the new policy is applied and that the customer does not continue using the previous higher-speed profile.
Renewal
Extend the validity period or subscription and retain the correct account credentials.
Suspension
Apply a restricted profile, reject new sessions, redirect the user to payment, or terminate an active session according to the provider’s policy.
Cancellation
Disable access, preserve required records, release or recover equipment, and apply the refund or final-invoice policy.
Reconnection
After a confirmed payment or authorized restoration, re-enable access and verify that the customer can connect.
Security best practices
Automated provisioning can change network access, so security must be designed into the integration.
Use strong and separate credentials for billing, RADIUS, MikroTik API, staff accounts, and payment systems. Give integrations only the permissions they need.
Restrict API and RADIUS requests by source address. Use secure transport and protect secrets outside public code or front-end pages.
Separate customer traffic from router management. Do not expose WinBox, API, SSH, RADIUS administration, or billing administration to public hotspot users.
Monitor unexpected profile changes, unusual provisioning volume, repeated authentication failures, duplicate requests, and sudden mass suspensions.
Back up RouterOS configuration, RADIUS data, customer records, voucher batches, billing data, and integration settings. Test recovery before relying on automation in production.
Troubleshooting automated provisioning
Customer paid but access was not created
Check payment confirmation, invoice reference, provisioning queue, integration credentials, router reachability, RADIUS response, and job logs. Do not issue a second voucher before ruling out a delayed job.
Customer received the wrong speed
Check plan-to-profile mapping, upload and download direction, RADIUS attributes, active session state, queues, and device testing. The customer may need to reconnect before the new profile applies.
PPPoE login is rejected
Check username, password, account status, RADIUS shared secret, server reachability, VLAN, profile, IP pool, and logs on both MikroTik and RADIUS.
HotSpot voucher is invalid
Check the voucher status, package, expiry, router location, device binding, payment record, and active sessions. Confirm that the device is reaching the correct captive portal.
Account remains active after suspension
Check whether the suspension changed the authorization record and whether the existing session was terminated. Some policies apply only to new authentication unless the active session is disconnected.
Payment is pending or unmatched
Check gateway reference, amount, currency, customer details, webhook status, provider dashboard, and reconciliation queue. Do not grant duplicate service based only on a customer message.
Choosing between SopraEnt and Xenfi workflows
When comparing billing platforms for automated provisioning, evaluate the entire process rather than the presence of a MikroTik logo.
Check:
•Supported router models and RouterOS versions
•HotSpot provisioning
•PPPoE provisioning
•RADIUS authentication and accounting
•API or managed configuration
•Package and profile mapping
•Payment confirmation
•Voucher delivery
•Customer portal
•Renewal and expiry
•Staff permissions
•Reports and audit logs
•Backup and recovery
•Support response
Providers can
Implementation roadmap
Week 1: Document the network
List routers, locations, interfaces, VLANs, IP pools, HotSpot servers, PPPoE servers, RADIUS services, and management paths.
Week 2: Standardize packages
Create a small catalog and map each package to a tested MikroTik profile, RADIUS policy, device rule, speed, quota, and expiry behavior.
Week 3: Build a pilot
Use one router, one location, one payment method, and a small set of customers. Test new provisioning, payment confirmation, upgrades, expiry, suspension, and restoration.
Week 4: Test failures
Simulate router offline, RADIUS unavailable, payment pending, duplicate webhook, wrong package, IP pool exhaustion, active-session conflict, and failed provisioning.
After launch: Expand gradually
Add more locations, routers, payment methods, packages, and agents only after the pilot is stable and support staff understand the recovery process.
Common mistakes to avoid
Do not connect automation before backing up the router and documenting which settings will be managed.
Do not map commercial packages to unclear or inconsistent network profiles.
Do not provision access from an unverified payment screenshot or browser redirect.
Do not assume a successful user creation means the customer has working internet. Test authentication, IP, routing, DNS, speed, and accounting.
Do not forget active sessions when applying upgrades, downgrades, expiry, or suspension.
Do not give an integration full router administration access when a narrower permission set is possible.
Do not generate duplicate access when a payment or provisioning job is delayed. Use references, status tracking, and idempotency.
Conclusion
Automated MikroTik PPPoE and HotSpot provisioning can help internet providers activate customers faster, apply consistent service policies, reduce manual router work, and connect payment status with network access.
The strongest implementation combines accurate subscriber records, clear packages, secure RADIUS or API integration, verified payment events, idempotent provisioning, session accounting, support tools, monitoring, and tested recovery procedures.
Start with one router and a small customer group. Test the complete path from registration and payment to provisioning, login, speed enforcement, expiry, suspension, renewal, and restoration.
To evaluate billing platforms for automated MikroTik provisioning,
Frequently asked questions
What is automated MikroTik user provisioning?
It is the process of creating and updating PPPoE or HotSpot customer access automatically through a billing platform, RADIUS server, MikroTik API, or managed router integration.
Can provisioning be triggered by payment?
Yes, when the payment event is securely verified. A confirmed payment can activate a voucher, renew a PPPoE subscription, update a RADIUS record, or apply a network profile.
Should I use RADIUS or the MikroTik API?
RADIUS is commonly used for centralized authentication, authorization, and accounting. API provisioning may be useful for supported router configuration. The best choice depends on the platform, network size, router design, and operational requirements.
Can the same billing platform manage PPPoE and HotSpot users?
Some platforms support both workflows. Confirm whether the account, router, RADIUS, package, payment, and reporting features are available for your specific setup.
How do I prevent duplicate vouchers or subscriber accounts?
Use unique customer, invoice, payment, and provisioning references. Make jobs idempotent and check existing account status before creating a new access credential.
Does a plan change affect an active MikroTik session immediately?
Not always. Some changes apply on the next login unless the active session is reauthorized or disconnected. Test this behavior before promising immediate upgrades or suspensions.
What should I do if a customer paid but provisioning failed?
Check the verified payment, provisioning queue, router reachability, RADIUS or API logs, and account status. Retry safely or use a controlled manual action without creating duplicate value.
Where can I evaluate ISP billing platforms?
You can
