How to Set Up MikroTik Billing Software for Bangladesh ISPs

If you run an ISP in Bangladesh, chances are your network already runs on MikroTik RouterOS — it's affordable, flexible, and handles PPPoE and hotspot traffic well even on modest hardware. The part most small and mid-sized ISPs get wrong isn't the network itself, it's the billing side: manually disconnecting overdue customers, tracking payments in a spreadsheet, or re-typing PPPoE secrets by hand every time someone signs up. This guide walks through how to connect MikroTik to a proper billing system so subscriber management, payment collection, and disconnection all happen automatically.

Why connect MikroTik to a billing system at all

A MikroTik router on its own is just a network device — it doesn't know who has paid, who is overdue, or which package a customer should be on. Without integration, ISP staff end up doing three things by hand every single day: checking a payment list, logging into Winbox to find the right PPPoE secret, and manually enabling or disabling it. At 50 customers this is annoying. At 500 customers it's a full-time job, and mistakes creep in — a paying customer stays disconnected, or a non-paying one keeps browsing for weeks because nobody remembered to cut them off.

Billing software that talks directly to RouterOS removes that manual step entirely. The moment a payment is recorded — whether through bKash, Nagad, or a manual entry at the counter — the system can re-enable the connection itself. The moment a due date passes, it can move the customer into a blocked profile without anyone touching Winbox.

PPPoE vs Hotspot: which one to automate first

Most Bangladeshi ISPs run a mix of both, so it helps to know how billing automation treats each differently:

• PPPoE is the standard for home and business broadband connections with a fixed customer identity. Billing automation manages this through PPPoE secrets and profiles — each customer's package maps to a RouterOS profile, and switching them between "active" and "blocked" is just a profile change.
• Hotspot is more common for shared or walk-in connections, like small shops or dormitories, where customers log in with a username and password through a captive portal. Billing here usually ties into user-manager or a RADIUS server rather than static secrets.

If you're just getting started, automate PPPoE first — it covers the bulk of recurring monthly revenue for most ISPs, and the setup is more predictable than hotspot's session-based billing.

Setting up the RouterOS API connection

MikroTik billing software talks to your router through the RouterOS API, not SSH or Winbox. The setup generally follows this order:

1. Create a dedicated API user. Don't use your main admin account. Create a separate user in /user with a strong password and only the permissions the billing system actually needs — usually read, write, and API access, not full system access.
2. Enable the API service. In /ip service, make sure the api service is enabled, and restrict it to the specific IP address of your billing server rather than leaving it open to any address.
3. Add the server details in your billing software. This is typically the router's IP, the API port (8728 by default, or 8729 for the encrypted API-SSL), and the credentials from step one.
4. Test the connection before going further. A good billing platform will let you pull the live list of PPPoE secrets or active sessions as a first test — if that list appears correctly, the connection is working.

Auto-provisioning: creating packages once, not per customer

The real time-saver isn't just the on/off automation — it's package provisioning. Instead of manually creating a PPP profile in Winbox every time you launch a new package, a properly integrated billing system lets you define the package once (say, a 10 Mbps package at ৳800/month) and it automatically creates the matching PPPoE profile, including the speed limit via simple queues or PCQ, and the pool for IP assignment.

When a new customer signs up for that package, the billing software creates their PPPoE secret directly on the router, assigns them to the correct profile, and they're online — no manual router work needed at all.

Handling disconnection and reconnection correctly

This is where a lot of DIY integrations go wrong. The naive approach is to simply disable the PPPoE secret when a customer is overdue, and re-enable it when they pay. The problem: this loses any custom settings that were live on that connection, and it doesn't give you a way to show the customer a "please renew" message instead of just cutting them off completely.

The more reliable pattern — the one billing platforms serving Bangladesh ISPs generally use — is to move the customer into a separate blocked profile rather than disabling the secret outright. This blocked profile can redirect all traffic to a small local page saying "Your package has expired — please recharge," which reduces support calls compared to a connection that just silently stops working. When the customer pays, they're moved back to their original package's live profile — not a recalculated one, but the exact profile they were on before, so nothing about their service changes except that it's active again.

RADIUS server: when you need it

If you're running hotspot billing, or if you have multiple MikroTik routers across different sites that all need to share the same subscriber database, a RADIUS server becomes necessary. RADIUS centralizes authentication so a customer's credentials work the same way whether they connect through router A or router B, and it hands off accounting data (how much they've used, how long they've been connected) back to the billing system in real time. For a single-site ISP running only PPPoE, RADIUS is usually unnecessary — the direct API approach above is simpler and does the job.

Common mistakes to avoid

• Leaving the API open to all IPs. Always restrict the API service to your billing server's IP address specifically.
• Using the main admin account for the API user. Create a scoped-down user just for billing integration.
• Recalculating the restore profile from the package instead of replaying the live one. If a customer had a manually adjusted speed or a special queue, restoring from the database package alone will silently undo that.
• Not testing the auto-bind / MAC-binding flow on a spare ONU or test line first. OLT and MikroTik interactions (especially on VSOL and BDCOM hardware) can behave differently across firmware versions — test before rolling out to live customers.