How ISP billing and RADIUS should work together.

Overview

Billing and RADIUS describe two views of the same service. Billing knows what the subscriber purchased and whether the commercial relationship is current. RADIUS knows whether an access request is accepted, what service is authorized and what session activity is reported.

Problems appear when these views drift. A paid customer may remain blocked, an expired plan may continue indefinitely or support may be unable to explain why a session was rejected. A connected design gives every lifecycle event an explicit owner and outcome.

Model subscriber state before automating it.

Define the states the operation actually uses—such as pending activation, active, grace period, suspended and closed—and the events allowed to move an account between them. Avoid using a single enabled flag to represent every commercial and operational condition.

For each state, document whether authentication is accepted, which policy is returned, whether an existing session may continue and what the subscriber and support team are told.

• Activation after verified payment or approved credit
• Renewal, expiry, grace-period and suspension transitions
• Closure, refund and manual exception handling

Keep packages and network policy related—but distinct.

A commercial package may include price, term and tax information, while the network policy defines rate, addressing or session behavior. Relate them through a controlled mapping instead of copying values into several systems.

This separation lets the business update pricing without unintentionally changing technical policy, and lets network teams tune enforcement without rewriting invoice history.

• Commercial package and renewal term
• RADIUS authorization profile and bandwidth policy
• Effective dates and a record of who approved each change

Treat payment callbacks as events, not proof by themselves.

Online payment workflows can be delayed, repeated or returned out of order. Verify the transaction through the supported gateway flow, make processing idempotent and retain the gateway reference before changing service state.

Where payments are recorded manually, require a clear role and audit trail. Both automated and manual paths should produce the same final subscriber and invoice state.

• Gateway reference, amount, currency and invoice relationship
• Duplicate-event protection and reconciliation status
• Named exception path when payment and service state disagree

Make access changes observable and recoverable.

Changing a subscriber record does not guarantee that every network component has applied the new state. Record the requested action, result and retry status. If an active session must change immediately, confirm the dynamic-control behavior supported by the deployed RADIUS and NAS environment.

Support teams need a readable explanation: which billing event occurred, which access change was requested and what the network reported afterward.

• Action queue or retry handling for temporary infrastructure failures
• Before-and-after subscriber and policy state
• Visible reason codes for rejection or incomplete changes

Measure the complete renewal workflow.

A renewal is complete only when the financial record, subscriber term and intended network service agree. Reconcile these views routinely and track exceptions instead of relying on complaints to reveal drift.

PHP Radius brings billing, payments, subscriber records and RADIUS operations into one platform context so teams can follow those handoffs. The final enforcement behavior depends on the configured authentication and network integration.

• Successful payment to updated renewal date
• Updated renewal state to intended access policy
• Exception reporting for unmatched payments or access changes