Prepaid Recharge-Card Redemption: A Verifiable ISP Workflow

Prepaid recharge cards look simple until a subscriber redeems a card and nothing happens: the balance does not move, the hotspot session does not extend, or the same card appears to work twice. When redemption is not verifiable end to end, support teams cannot tell whether a card was invalid, already used, printed in error, or blocked by a session that never re-authenticated. This article gives you an ordered, testable workflow for prepaid recharge-card redemption so a card either applies cleanly or fails with a reason you can explain.

When the recharge-card workflow applies

This pattern is for ISPs that sell prepaid access through printed or digital cards, whether the card tops up a wallet balance, changes a hotspot package, or renews a PPPoE plan. The workflow triggers in three common moments. First, when you generate a new batch of cards for distributors. Second, when a subscriber or distributor redeems a card against an account. Third, when a redemption is disputed and you must reconstruct what happened.

Each moment has its own validation. Batch creation must produce cards with correct denominations and no duplicates. Redemption must be atomic, so a card is consumed exactly once. Dispute handling must trace a card from creation through redemption to the resulting session or package change. Treat these as one connected chain rather than three isolated tasks.

Design the card batch before you print

The most expensive prepaid mistakes happen at batch design, not at redemption. Decide the denomination structure, quantity, and expiry rules before a single card is generated, because reprinting or recalling distributed cards is costly and confusing for buyers.

Denominations and mapping

Confirm exactly what each denomination does. A card can add a fixed balance, or it can map directly to a named package or hotspot duration. Mixing these models in one batch without clear labeling leads to redemption confusion. Write down, per denomination, the amount or package, the intended customer segment, and the distributor margin.

Quantity, expiry, and controls

Set batch size to match real distributor demand rather than printing large surpluses that sit unaccounted. If your card model supports expiry, decide it now so aged inventory does not become a support burden. Record who authorized the batch and why, so finance can reconcile printed value against sold value later.

The redemption sequence, in order

Redemption must behave predictably every time. The steps below define the happy path and the points where you check for failure. Redemption should be atomic: either the card is consumed and the benefit applied together, or neither happens.

1. Identify the account. Confirm the subscriber or hotspot account the card will apply to. A card redeemed against the wrong account is a support ticket waiting to happen.
2. Validate the card code. Check that the code exists, belongs to a recognized batch, is not expired, and is not already marked used.
3. Apply the benefit. Add the balance, change the package, or extend the hotspot duration according to the denomination mapping.
4. Consume the card. Mark the card used with a timestamp and the account it was applied to, so it cannot be redeemed again.
5. Trigger the access effect. For an active session, push the change so the subscriber gets the new package or extended time without waiting for a natural reconnect.
6. Confirm to the redeemer. Return a clear success message with the new balance, package, or expiry so the distributor or subscriber sees the result immediately.

Failure and validation checks that matter

A redemption workflow is only trustworthy if its failures are specific. Vague errors force support to guess. Map each failure to a distinct, logged reason.

For the last case, remember that PPPoE and hotspot sessions are stateful. If a subscriber recharges mid-session, the router may keep enforcing the old policy until the session re-authenticates. Pushing a policy change to the live session is what makes redemption feel instant instead of requiring a reconnect. Validate that this step succeeded, not just that the balance moved.

How ISPbills supports recharge-card redemption

ISPbills connects the prepaid and access layers so this workflow runs in one operational system rather than across disconnected tools. On the prepaid side, ISPbills supports configurable recharge-card batches and denominations, printable or CSV card downloads, and a distributor portal, which covers batch design, distribution, and controlled redemption. Hotspot recharge and package changes through cards let a redeemed card change a subscriber’s package or extend access directly.

On the access side, ISPbills provides FreeRADIUS NAS and policy management, PPPoE and Hotspot authentication, and Change of Authorization support. Change of Authorization is what lets a mid-session recharge take effect without waiting for reconnect, closing the gap between “balance updated” and “subscriber sees the new plan.” When you need to reconstruct a disputed redemption, radacct session records and post-authentication logs let you tie a card redemption to the session behavior that followed.

What your team should verify: that a redeemed card in ISPbills produces both the expected package or balance change and the expected session outcome, and that the distributor portal and bill-payment history reflect the same event. The operational handoff that becomes simpler is the dispute path, because support can trace a card from its batch through redemption to the resulting session instead of guessing. Confirm which of these capabilities are enabled on your plan and configuration, and check the current feature page rather than assuming availability.

Reconciliation and dispute reconstruction

Prepaid revenue only balances if printed value, sold value, and redeemed value line up. Build a routine reconciliation instead of investigating only when something breaks.

Reconcile printed against redeemed

For each batch, compare cards generated, cards distributed through the portal, and cards redeemed. Unredeemed cards represent outstanding liability or unsold inventory; a large gap deserves a look before the next batch is printed. Use the CSV download to reconcile against distributor records.

Reconstruct a single dispute

When a subscriber claims a card did not work, walk the chain: does the card show as redeemed, against which account, at what time, and did a matching package or balance change follow? Then check whether the session reflected it. If the card is used but the session never changed, the fault is in the access step, and the accounting records point you there directly.

A decision standard for going live

Before you rely on prepaid recharge cards at scale, hold the workflow to a concrete standard. Do not treat the feature as done because one card worked once.

1. A test card applies the correct benefit and is rejected on a second redemption attempt.
2. Each failure type returns a distinct, logged reason a support agent can read and explain.
3. A mid-session recharge changes the live session without requiring the subscriber to reconnect manually.
4. A batch reconciles cleanly: generated, distributed, and redeemed counts match your records.
5. Any disputed redemption can be reconstructed from records without guesswork.

When all five hold for your configuration, prepaid redemption is verifiable rather than hopeful. Re-run these checks whenever you change denominations, upgrade RADIUS or router versions, or adjust distributor terms, and confirm your approach against the contracts and local regulations that apply to you.

Related operator guides

RADIUS CoA and Disconnect Messages: An ISP RunbookRead guide →PPPoE vs IPoE for ISPs: Choose the Access ModelRead guide →

Research basis: ISPbills product documentation; FreeRADIUS documentation. Validate implementation details against the software releases, contracts, configurations, and local regulations governing your network.