ISPs have a tight link between payment and service. That makes billing-state accuracy especially important.
Home connections and hotspots may need different billing models
A home fibre or fixed-wireless account often has one recurring monthly service. A hotspot product may be prepaid, session-based or package-based and should not be forced into the same renewal model.
Define the disconnect rule explicitly
A prepaid ISP may disconnect when the paid period ends. Another may allow a grace window. The billing system should publish a clear event when the policy condition is met.
Do not disconnect on an unresolved payment
If a mobile-money result is Unknown, verify it before treating the customer as unpaid. A missing callback should not become a network suspension.
Reconnect from verified payment state
Once payment is confirmed, the billing system should trigger the provisioning or network-management workflow according to the ISP's policy.
Make reactivation idempotent so a repeated provider event cannot create inconsistent service state.
What support needs to see
- invoice period and amount;
- latest payment attempt and status;
- current service state;
- grace deadline, if any;
- last provisioning action and result.
Prepaid and postpaid ISPs need different rules
A prepaid home connection can be modeled around a paid-through date: once the purchased period ends, the account becomes eligible for suspension. A postpaid ISP may first issue an invoice, allow a grace period and suspend only after the configured delinquency threshold.
Do not mix those models in one generic “unpaid” state. The network action should be derived from the plan's commercial policy.
Hotspot packages are often consumption products
A one-hour hotspot voucher, a 5 GB bundle and a monthly home connection can all be sold by the same ISP, but only the monthly account necessarily belongs in recurring billing. Keeping package purchases separate prevents the renewal engine from chasing customers for services they intentionally bought once.
Provisioning needs its own delivery state
After payment succeeds, the billing system can emit a service-restoration event, but the network platform still has to apply it. Record whether the provisioning command was accepted, succeeded or needs retry. A paid customer whose router policy failed to update is a service exception, not a payment failure.
Support should be able to answer in one screen
- What period has the customer paid through?
- Is the latest invoice due, paid or in grace?
- Is any mobile-money attempt unresolved?
- What is the current network/service state?
- Was the last disconnect or reconnect action successful?
That separation shortens the common support loop where billing says the customer paid but network operations still show the account offline.
Keep failed provisioning out of collections
If the customer is paid but reconnection fails, route the issue to network operations. Sending another payment reminder in that situation compounds the error and teaches the customer not to trust payment confirmation.
