← Operator library Business Systems

Evaluate MikroTik Billing Software with Failure Tests

Choose a billing platform by testing reconciliation, isolation and recovery—not screenshots.

What this note covers

Choose a billing platform by testing reconciliation, isolation and recovery—not screenshots.

A feature list does not expose operational risk

The useful evaluation starts after the demo succeeds. Disconnect a router, repeat a payment callback, change a package mid-cycle and restrict an operator account. The platform should preserve money, access intent and audit evidence through each failure.

Control

How packages become enforceable RouterOS or RADIUS policy.

Accounting

How sessions, invoices, payments and adjustments reconcile.

Isolation

How one group, operator or reseller is prevented from reading another.

Trace one subscriber end to end

Follow creation, activation, renewal, suspension, migration and deletion. At every step identify the authoritative record and retry behavior. Confirm historical invoices remain unchanged after later package edits.

Test money separately from validity

A payment changes ledger state; a recharge may change service validity. Verify permissions and audit trails for each. Refunds, reversals and manual adjustments need explicit workflows rather than negative magic values.

Inspect network degradation

When API access fails, the system should queue or classify work rather than claim success. Read-back verification distinguishes an accepted command from a device that actually reached intended state.

Prove tenant boundaries

Use direct URLs and autocomplete searches while signed in as each role. A hidden menu is not authorization. Customer, package, payment, ticket, OLT and ONU queries all need server-side scope.

Operational caution: Never evaluate a candidate by connecting it to production with broad router credentials. Use a representative lab and least-privilege integration account.

Put it into operation

  1. Write scenarios. List normal and failure journeys before the sales call
  2. Build lab. Use representative RouterOS versions and access methods
  3. Execute. Record expected and observed state for each scenario
  4. Reconcile. Compare device, RADIUS, ledger and subscriber records
  5. Decide. Score operational gaps and migration cost, not visual features alone

Research basis: MikroTik RouterOS API documentation; IETF RFC 2865; IETF RFC 2866. Implementation details must be verified against the deployed release and local policy.

Continue with ISPbills

Put this guide into practice