MikroTik ISP Billing

Billing should control service state

Small ISPs often run billing in one place and MikroTik access rules in another. That creates manual work: support checks payment status, finance confirms the balance, then someone logs into RouterOS to suspend, restore, or change speed.

ISPAgents should connect the billing workflow to MikroTik through controlled operator rules so paid, overdue, upgraded, or downgraded subscribers can be handled with clear approval and audit evidence.

MikroTik billing workflows

Direct RouterOS control and RADIUS

ISPAgents should support the common MikroTik patterns that real ISPs use as each connector path is validated:

• RouterOS API for queues, address lists, firewall policy, DHCP, and status.
• Existing FreeRADIUS for PPPoE, Hotspot, policy, and accounting workflows.
• ISPAgents Managed RADIUS early access after tenant launch signoff.
• Custom connectors for private networks, NATed sites, unusual queue layouts, or vendor-specific steps.

Why this matters for small ISPs

Every manual access change creates delay, errors, and missing proof. A serious MikroTik billing system should reduce the work without hiding the risk. The operator needs command preview, approvals, connector health, retry state, failure explanations, and a complete customer timeline.

FAQ

Can ISPAgents cut off MikroTik internet automatically?

Only after the tenant has proven subscriber identity, policy mapping, command preview, approval rules, execution evidence, and rollback. The enforcement path can be RouterOS, RADIUS, or a custom connector depending on how the ISP designed the network.

Does MikroTik billing require managed RADIUS?

No. Some operators start with direct MikroTik control. Others use existing FreeRADIUS or managed RADIUS early access. ISPAgents should treat all three as separately validated deployment paths, not one default path for every tenant.