How to choose ISP software

Why ISP software choice matters

ISP billing and network management software is the system that sits between every subscriber and your network — and choosing the wrong one costs more to fix than almost any other business decision. DataRadius is ISP billing and management software built for this role; this guide covers how to evaluate any platform, including ours.

The software handles subscriber signup, plan assignment, payment collection, router authentication via RADIUS, speed enforcement, usage tracking, invoicing, support workflows, and reporting. When it works well, subscribers sign up, pay, and get connected without anyone at the ISP touching a router. When it fails — wrong bills, missed payments, subscribers stuck offline after paying, no way to see who is connected — the ISP operator spends their day firefighting instead of growing the business.

Switching ISP software is painful. It means migrating subscriber records, reconfiguring routers, retraining staff, reconnecting payment gateways, and running parallel systems during the transition. Most ISPs that regret their software choice endure the pain for years before switching because the migration cost feels too high. Choosing carefully the first time avoids that trap.

This guide covers what to evaluate, what questions to ask, and how to compare platforms — without recommending a specific vendor. The right choice depends on your network size, hardware, billing model, payment methods, and budget.

The evaluation checklist

Before looking at any vendor's feature page, write down what your ISP actually needs. Not what sounds nice in a feature list — what you use daily, what you cannot operate without, and what your subscribers expect.

Start with these ten questions:

1. What billing models do I use? Prepaid, postpaid, hybrid (prepaid converts to postpaid), hotspot vouchers, time-based plans, data-based plans, speed-based unlimited plans, or a combination?
2. What routers and network equipment do I operate? Specific brands and models — MikroTik RB series, Ubiquiti EdgeRouter, Cisco ISR, Huawei OLTs, or others?
3. What payment methods do my subscribers use? Mobile money (which providers specifically), bank transfers, credit/debit cards, cash collection, agent networks?
4. Do I need PPPoE authentication, hotspot authentication, or both?
5. Do I need the software to manage fiber ONUs and OLTs, or only routing and billing?
6. How many subscribers do I have now, and how many do I expect in 2 years?
7. Do my subscribers need a self-service portal to check balances, buy plans, and view usage?
8. Do I need automated invoicing with tax compliance for my jurisdiction?
9. Do I need API access to integrate with other systems (accounting software, CRM, custom portals)?
10. What is my budget — per month or per subscriber per month?

These ten answers eliminate most platforms immediately. A vendor that does not support your billing model or your router brand is a non-starter regardless of other features.

Billing features to check

Billing is the core function. If the billing engine does not match how your ISP operates, everything else is compromised.

Prepaid support. Can subscribers buy a plan (time-based or data-based), use it until it expires, and buy another? Does the system automatically disconnect or throttle when the plan expires? Does it support stacking (subscriber buys a new plan before the old one expires and the remaining value carries over)?

Postpaid support. Can you generate monthly invoices, track due dates, apply late fees, and automatically suspend service for non-payment after a configurable grace period? Does it support proration when subscribers change plans mid-cycle?

Hotspot voucher management. Can you generate voucher codes (batched or on-demand), assign them to plans, distribute them via SMS or print, and track redemption? Does the voucher system integrate directly with the router's hotspot server?

Fair use policy (FUP) enforcement. When a subscriber on an "unlimited" plan crosses a data threshold, can the system automatically reduce their speed rather than disconnecting them? Can you configure different FUP thresholds per plan?

Multi-currency. If you operate in multiple countries or your subscribers pay in different currencies, does the system handle currency conversion, display, and reporting correctly?

Invoicing and receipts. Does the system generate tax-compliant invoices with your business details, tax ID, and line-item breakdown? Can subscribers download PDF invoices from a self-service portal?

Collections workflow. What happens when a subscriber does not pay? Does the system send automated reminders (SMS, email) at configurable intervals? Does it suspend service after a grace period and reactivate automatically when payment arrives?

Test each of these with your actual billing scenarios, not hypothetical ones. Create test subscribers in the platform's trial environment and walk through the full lifecycle: signup, plan purchase, usage, expiry, renewal, plan change, and cancellation.

Network and router integration

The billing system needs to talk to your routers. The depth of that integration determines how much manual router management you still have to do.

RADIUS authentication. The minimum: the platform runs a RADIUS server that your routers query for authentication. The response should include speed limits, IP assignment, session timeout, and accounting interval.

RADIUS dynamic authorization. CoA (Change of Authorization) lets the platform change speeds mid-session. DM (Disconnect Message) terminates sessions immediately. Not all platforms support both — some can only disconnect.

Router API integration. Beyond RADIUS, does the platform configure queues, firewall rules, or hotspot servers via the router's API? This varies by brand and determines how much manual router work remains.

Device monitoring. Does the platform track router status (online/offline, CPU, traffic) and subscriber connections? Built-in monitoring saves running a separate system.

OLT and ONU management. For fiber networks: does the platform handle OLT ports, ONU registration, VLAN assignment, and optical power monitoring?

The test: add one of your actual routers to the platform's trial environment. Verify that a test subscriber can authenticate, receive the correct speed limit, get disconnected on plan expiry, and reconnect after renewal. If this flow does not work during evaluation, it will not work in production.

Payment method support

Payment integration determines whether subscribers can pay you without friction. Every payment method you do not support is a barrier that costs you subscribers.

The specific methods that matter depend entirely on your market:

Mobile money. Check whether the platform integrates with the specific providers in your market. Does it handle both platform-initiated prompts and subscriber-initiated payments? APIs, callback handling, and reconciliation differ between providers.

Card payments. Does the platform handle recurring charges for postpaid subscribers? Does it tokenize card details through the processor for PCI compliance?

Bank transfers. Does the platform generate unique payment references per subscriber for automatic matching? Manual bank statement reconciliation is a scaling bottleneck.

Cash collection. Can agents record payments on behalf of subscribers with an audit trail and receipt generation?

Automated reconciliation. The critical question for every method: does the payment credit the subscriber's account automatically, or does someone match it manually? Automated reconciliation is the baseline — anything less creates a bottleneck that worsens as you grow.

Subscriber self-service

A subscriber portal reduces support volume and improves subscriber satisfaction. Every question a subscriber can answer through a portal is a question that does not become a support ticket.

The minimum viable self-service portal:

• Account balance and plan status. The subscriber can see their current plan, expiry date, data usage, and account balance.
• Plan purchase and renewal. The subscriber can buy a new plan or renew their current one directly through the portal, using the payment methods available in your market.
• Payment history. A list of past payments with dates, amounts, and receipt numbers.
• Usage history. Data consumed, session duration, and connection logs.
• Speed test. A built-in speed test or link to a reliable external one.
• Support ticket submission. The subscriber can report an issue without calling.

Advanced features that matter for retention: plan comparison and self-service upgrade, family/household management (access schedules, data limits), and notification preferences (SMS, email, push).

Evaluate the portal as a subscriber would. Is it mobile-friendly? Does it load on a slow connection? Can a non-technical person use it without instructions?

Reporting and analytics

At minimum, you need: revenue reports (by period, plan, payment method), subscriber reports (activations, disconnections, churn), network reports (bandwidth utilization by router and time), payment reports (successful vs failed, outstanding balances), and aging reports (overdue balances by days).

Beyond built-in reports, check for API access (pull data into your own tools), scheduled report delivery, and export in standard formats (CSV, Excel, PDF).

Data ownership and portability

This is the question most ISPs skip during evaluation and regret later: can you get your data out?

Data portability means you can export — at any time, without vendor cooperation — a complete copy of:

• Subscriber records. Names, contact details, addresses, plan history, account status.
• Transaction history. Every payment, invoice, credit, and adjustment, with dates and amounts.
• RADIUS accounting data. Session logs, data usage, connection history.
• Configuration data. Plan definitions, router configurations, payment gateway settings.

The test is simple: during your trial, export everything. If the platform has an export function, use it and verify the output is complete and machine-readable. If there is no export function, ask the vendor in writing how you would get your data if you canceled. If the answer is vague, that is a red flag.

Platforms that make it hard to leave are counting on lock-in as a retention mechanism. The ISPs that build their business on a platform they cannot leave from have taken a risk that compounds every month as the data grows.

API access is the strongest form of data portability. If the platform has a documented API that lets you read all subscriber and transaction data, you can always build an export. If the API is read-only for a subset of data, portability is limited.

Migration considerations

If you are switching from an existing platform (or from spreadsheets and manual router management), migration planning determines whether the switch is smooth or catastrophic.

Data import. Can the new platform import subscribers from a CSV or through an API? What fields are required versus optional? Test the import with a subset of your real subscriber data before committing.

Router reconfiguration. Switching billing platforms means pointing your routers' RADIUS configuration to the new server. For PPPoE subscribers, this means existing sessions will terminate and subscribers will re-authenticate against the new system. Plan this for a low-traffic maintenance window.

Payment gateway migration. If the old platform handled payment callbacks (mobile money, card processors), those callbacks need to be redirected to the new platform. There is usually a gap during switchover — have a plan for payments that arrive during the transition.

Parallel run period. The safest migration strategy is to run both platforms simultaneously for 1–2 weeks. New subscribers go on the new platform. Existing subscribers stay on the old platform until you verify the new one works. Then migrate existing subscribers in batches, verifying each batch before starting the next.

Staff training. Your support team, billing team, and technicians need to learn the new interface. Budget 1–2 days of training and expect the first two weeks to be slower than normal as everyone adjusts.

Rollback plan. If the new platform has a critical issue during migration, can you revert to the old one? Keep the old platform running (read-only, with no active subscribers) for at least 30 days after the last subscriber is migrated.

Pricing models for ISP software

ISP software pricing falls into four models, each with different incentive structures:

Per-subscriber fee. You pay a fixed amount (typically $0.30–$2.00) per active subscriber per month. Cost scales linearly with your subscriber base. This aligns the software vendor's revenue with your growth — they earn more when you do. The risk is that the per-subscriber fee compresses your margin as you add lower-ARPU subscribers.

Flat monthly fee. A fixed price ($50–$500/month) regardless of subscriber count. Favorable for large ISPs (low per-subscriber cost) and expensive for small ones (high per-subscriber cost). The vendor has no direct incentive tied to your growth, which can be positive (no cost surprise as you scale) or negative (less motivation to help you grow).

Revenue share. The vendor takes a percentage (typically 1–5%) of revenue collected through the platform. This aligns incentives strongly — the vendor earns when you collect — but at scale, the percentage can exceed what a per-subscriber fee would cost. Do the math at your current size and at 2× your current size before choosing this model.

One-time license + maintenance. You buy the software outright and pay an annual maintenance fee (typically 15–20% of the license cost) for updates and support. This is the self-hosted model. High upfront cost, lower ongoing cost, but you take on hosting, backups, and infrastructure management.

Compare total cost over 24 months at your current subscriber count and at your projected 2-year count. A platform that is cheaper today may be more expensive at scale, and vice versa.

How to run an evaluation

A structured evaluation process takes 2–4 weeks and prevents a decision you regret for years.

Week 1: Shortlist. Based on your requirements (billing model, router brand, payment methods, budget), identify 3–4 platforms that claim to meet your needs. Sign up for trial accounts on all of them.

Week 2: Hands-on testing. For each platform, add a test router, create test subscribers, run through the full billing lifecycle (signup → plan purchase → payment → authentication → usage → expiry → renewal), test the subscriber portal, and attempt a data export. Score each platform against your ten evaluation questions.

Week 3: Deep evaluation. For the top 2 platforms, test edge cases: what happens when a payment fails, when a subscriber changes plans mid-cycle, when a router goes offline and comes back, when two subscribers try to use the same username. Contact support with a technical question and measure response time and quality. Ask for references from ISPs similar to your size and market.

Week 4: Decision. Compare scores, total cost over 24 months, data portability, and your team's subjective preference for the interface. The platform that scores highest across requirements, cost, and usability is the right choice — not the one with the flashiest demo or the longest feature list.

During this process, try several platforms during their trial periods — DataRadius and others — with your actual hardware and billing scenarios. A feature that works in a demo but fails with your specific router model or payment provider is not a feature you can count on.

The software you choose will run your business for years. Spend the four weeks evaluating properly. The cost of a deliberate evaluation is a few weeks of your time. The cost of choosing wrong is months of migration pain and subscriber disruption later.