Implementation guide
MikroTik ISP Billing Troubleshooting Checklist
Start with the failing boundary instead of changing several systems at once. Confirm billing state, credential ownership, network reachability and device response in a fixed order.
Use the interface and documentation together.
The capture below shows the related ISPbills product area. Follow the linked documentation for current fields and prerequisites, then validate the exact device, provider, software version, failure path and rollback before production use.
Plan the complete path, not one isolated setting.
Troubleshoot MikroTik ISP billing, PPPoE, RADIUS, RouterOS API and package-policy failures with a repeatable evidence-first checklist. Confirm the exact device, software version, provider contract and failure behavior in a representative environment before production rollout.
Reproduce precisely
Capture subscriber, time, router, service, expected result and actual result.
Follow the transaction
Trace billing eligibility, API or RADIUS request, device response and active-session state.
Change one variable
Use a representative test account, preserve logs and verify rollback before applying a broad correction.
Prove the boundaries before automating them.
Record expected results, failure signals, the person who can approve a change, and the rollback path. Product support depends on the deployed architecture and integration version.
- Clock and timezoneTest this requirement with representative data and retain the result in the implementation plan.
- Routes, ports and firewallTest this requirement with representative data and retain the result in the implementation plan.
- Credentials and permissionsTest this requirement with representative data and retain the result in the implementation plan.
- Package, profile and active sessionTest this requirement with representative data and retain the result in the implementation plan.
Implementation answers
Why can a paid subscriber still be offline?
The payment may be correct while access restoration, session state, routing or device connectivity failed. Trace each handoff.
Why does API testing pass but provisioning fail?
The credential may have read access but lack a required write policy, or the target object and RouterOS version may differ.
What evidence should support collect?
Record timestamps, subscriber ID, device, RouterOS version, request result and relevant sanitized logs.
Bring the actual routers, access design, billing rules and failure cases.
Explore the online workspace or ask ISPbills to review compatibility and migration scope.