Operator cutover playbook for migrating to a new electronic voucher management system – MoboGage EVD System

Migrating to a New Electronic Voucher Management System: An Operator Cutover Playbook

by with No Comment EVD Software

Definition. An electronic voucher management system (EVMS) is the software that controls the whole life of prepaid vouchers, from generation or intake through dealer allocation, sale, redemption into charging and reconciliation. MoboGage EVD System is an EVMS and electronic voucher distribution platform built for telecom operators and VAS partners.

TL;DR for migration owners

  • A voucher platform migration is a ledger move, not a software install. Treat stock, PIN data and dealer balances like money, because they are.
  • Map every legacy lifecycle state to a target state before you move a single serial range.
  • Drain offline POS caches and resolve unknown-status top-ups before you snapshot dealer wallets.
  • Run both platforms in parallel until reconciliation closes with zero unexplained variance, and write the rollback trigger down before cutover weekend.

Most operators do not wake up wanting a new voucher platform. They get there because the old one has become expensive to keep alive: a vendor that no longer ships fixes, or a reporting layer finance has quietly replaced with spreadsheets. By the time the replacement is signed, the commercial team wants the new dealer app live “next month”.

That is where migrations go wrong. The new electronic voucher management system is rarely the problem. The problem is what you carry into it: millions of PINs in a dozen states, a dealer hierarchy that drifted from the contracts years ago, and wallet balances that distributors will check to the last unit the morning after cutover.

This playbook is the sequence we would follow from the operator side of the table. It is written for prepaid product owners, channel managers, IT leads and the SI partner running delivery.

Why voucher platform migrations fail

They almost never fail on the user interface. They fail on three quiet things.

State drift. The legacy system calls a batch “active” when it means “printed and sitting in a warehouse”. The new platform reads “active” as sellable. Within a day, stock nobody has received is showing on dealer screens.

Balance disputes. A top-tier distributor’s wallet shows a different number on Monday than it did on Friday. Even if the difference is a single pending transaction, the trust damage lasts longer than the fix.

Orphaned channels. An API partner nobody remembered still points at the old endpoint, or a batch of rural POS terminals never picked up the new app. They keep selling against stock the old system no longer owns.

None of these need clever technology to prevent. They need a written inventory, a state map, a freeze window and reconciliation gates someone senior signs off.

Step 1: Inventory what actually has to move

Before anyone talks about cutover dates, list every object the old platform holds and decide what happens to it. Some things migrate, some get rebuilt cleanly in the new platform, and some are archived read-only for audit.

Object Migrate, rebuild or archive What to verify Typical owner
Product catalogue and denominations Rebuild (cleaner) Every live SKU has a target product with the same face value and charging profile Prepaid product
Voucher batches and serial ranges Migrate Count by batch, by state and by serial range matches the legacy export Voucher ops
Encrypted PIN data Migrate under key ceremony Record counts and checksums match; no clear-text exposure at any step Security / IT
Dealer hierarchy and contracts Migrate, then clean Every dealer has one parent, one tier and a current contract Channel sales
Wallet and float balances Migrate at snapshot Sum of balances per tier matches the signed snapshot Finance
Credit limits and commission plans Rebuild Plans match signed commercial terms, not legacy configuration Channel finance
Open disputes and pending transactions Resolve before snapshot Zero unknown-status transactions at freeze Ops + finance
POS terminals and app versions Re-enrol in waves Each terminal is registered, on the target app and drained of offline stock Field ops
API partner credentials Reissue Every partner tested in sandbox against the new endpoint Partner management
Transaction history Archive read-only Retention period agreed with audit and regulators Finance / compliance

The rebuild column matters more than it looks. Legacy commission plans carry years of one-off exceptions. Rebuilding them from the signed agreements is slower for a week and saves a year of disputes.

Step 2: Map lifecycle states before moving stock

This is the step most teams skip, and the one that causes the worst first week. Every voucher platform has its own state vocabulary. Write them side by side and agree the rule for each.

Legacy state (example wording) What it usually means Target state Migration rule
Generated PINs created, not yet sent to print or channel Generated / inactive Move as inactive; never sellable on arrival
Printed / in transit File released to print house or courier In custody (inactive) Hold inactive until goods receipt is confirmed
Received Physical stock in warehouse Warehouse stock Activate only on allocation
Allocated Assigned to a distributor or dealer Allocated to the same node Verify the node exists in the new hierarchy first
Active / sellable Can be sold and redeemed Active Cross-check against charging before cutover
Sold Sold, not yet redeemed Sold Keep redeemable; preserve sale timestamp
Redeemed / used Consumed in charging Redeemed (archive) Migrate for audit; block any re-use
Blocked / stolen / damaged Withdrawn from sale Blocked Never reactivate during migration
Expired Past validity Expired Migrate for reporting, or archive

Ask your vendor two direct questions here. Does the target platform hold state per PIN or per serial range? And what happens to a range that is half sold? If the answer is vague, the migration plan is not ready.

Step 3: Move PIN data without ever seeing it

PIN files are the most sensitive thing in the programme. The rule is simple to say and hard to keep: no person and no intermediate system should see clear-text PINs during migration.

In practice: a key ceremony with dual control, PINs re-encrypted from legacy to target keys inside a hardware security module or equivalent protected environment, and record counts plus checksums compared on both sides. Transfer files are deleted on schedule and the deletion is logged.

If the vendor proposes exporting PINs to a spreadsheet “just for validation”, stop the call. We cover the wider custody model, including what encrypted-until-sale should mean, in our guide to voucher reconciliation and PIN security in an EVMS.

Step 4: Freeze, drain and snapshot dealer float

Dealer wallets are where migrations become personal. A distributor who sees a wrong balance on Monday will phone your commercial director, not your IT team.

A sequence that holds up:

  1. Announce the freeze window early. Dealers should know a week ahead when stock purchases and wallet transfers pause, and for how long.
  2. Drain offline POS caches. Handheld terminals that sell offline hold cached vouchers and unsynced sales. Push a sync, then block offline sales for the final 24 to 48 hours so nothing appears after the snapshot.
  3. Resolve unknown-status top-ups. Any PINless recharge sitting in a timeout or unknown state must be confirmed against charging and either completed or reversed before the snapshot. Our electronic top-up system guide explains why float, not stock, is the real inventory in eTopup.
  4. Snapshot and sign. Export balances per dealer and per tier, share them with the top distributors and get written acknowledgement before go-live.
  5. Load and re-verify. After load, the sum per tier in the new platform must equal the signed snapshot. Not roughly. Exactly.

If your hierarchy has more than two or three tiers, check that each sub-dealer lands under the right parent and inherits the right credit limit. The patterns in our piece on multi-tier reseller voucher distribution are a useful sanity check for that review.

Step 5: Cut over channels in waves

Do not switch every channel on the same night. A sensible order is usually:

  • API partners first, in sandbox and then a controlled production window, because their traffic is easiest to watch and roll back.
  • Dealer web portal next, starting with a small group of top-tier distributors who agreed to be early.
  • POS fleet in regional waves, pushed through terminal management, with field teams ready in each region on the day.
  • USSD and SMS last, because routing changes touch the network side and need their own change window.

Keep old endpoints answering with a clear “moved” response for a while. It is the cheapest way to find the partner nobody remembered.

Step 6: Parallel run and reconciliation gates

Run both platforms side by side long enough to close several full business days, including at least one weekend and one month-end if you can. Each gate has a pass condition and a rollback trigger agreed in advance.

Gate Pass condition Rollback or hold trigger
Stock count Counts by product, state and serial range match the legacy export Any unexplained difference in sellable stock
Dealer balances Sum per tier equals the signed snapshot Any distributor balance dispute not resolved within the agreed window
Sales vs charging Every sale has a matching redemption or a valid sold-not-redeemed record Redemptions in charging with no sale record
Commissions Sample of dealers recalculated by finance matches the platform Systematic commission mismatch in any tier
Channel health Every live channel transacting on the new platform Any channel still hitting the old endpoint after the deadline
Day-close Day-close pack produced and accepted by finance Day-close cannot close without manual journals

Write the rollback decision into the plan with a named owner and a deadline. A rollback decided at 4 a.m. by whoever is still awake is not a plan.

GCC and MEA notes

Timing matters as much as engineering in Gulf markets. Avoid the Ramadan and Eid peaks, when recharge volumes and dealer activity change sharply. Remember that weekends differ: the UAE moved to a Saturday–Sunday weekend in 2022, while Saudi Arabia, Qatar and Kuwait keep Friday–Saturday. A cutover planned on a European calendar can land on your busiest dealer day.

Bilingual dealer communication, data-residency language in the contract and SI partner responsibilities should all be settled before the freeze notice goes out. Our GCC operator guide to electronic voucher management covers those requirements in RFP terms.

Questions to ask any EVMS vendor about migration

  • Show us a state-mapping template from a previous migration, with customer details removed.
  • How do you re-encrypt PINs from our legacy keys, and who holds which key component?
  • Can you run a parallel reconciliation report against our legacy exports, and in what format?
  • How do you handle POS terminals that were offline during the freeze?
  • What is the rollback path for each channel, and how long does it take?
  • Which tasks sit with you, which with our SI, and which with us?

How MoboGage EVD System approaches a migration

We start with the state map and the dealer snapshot, not the screens. EVD System holds voucher inventory, the dealer hierarchy with wallets and credit limits, PIN and PINless sales across Android/Linux POS, apps, portals and APIs, and day-close reconciliation in one control plane. That makes it practical to run a parallel period against legacy exports and close each gate with evidence finance can read.

What we will not do is promise a date before seeing your data. The honest answer comes after a short discovery on a sample export.

FAQ

What is an electronic voucher management system?

An electronic voucher management system is software that controls prepaid vouchers end to end: generation or intake, inventory, allocation through the dealer hierarchy, sale, redemption into charging and reconciliation. MoboGage EVD System is one such platform for telecom operators and VAS partners.

How long does an EVMS migration take?

It depends on data quality, channel count and how many lifecycle states the legacy platform uses. Plan for discovery, a test migration on a data copy, a parallel run over several business days and phased channel cutover. Treat any date given before discovery as an estimate.

How do we move PIN data securely?

Use a key ceremony with dual control, re-encrypt PINs from legacy keys to target keys inside a protected environment such as an HSM, compare record counts and checksums, and log deletion of transfer files. Nobody should see clear-text PINs.

What happens to dealer wallet balances during cutover?

Freeze purchases and transfers, drain offline POS caches, resolve unknown-status top-ups, then snapshot balances per dealer and tier. Load that snapshot into the new platform and confirm the totals match exactly before reopening sales.

Should we cut over all channels at once?

No. Move API partners first, then the dealer portal, then the POS fleet in regional waves, and USSD or SMS last. Keep old endpoints returning a clear moved response so forgotten integrations surface quickly.

When should we roll back?

When a gate fails and cannot be fixed inside the agreed window: unexplained sellable-stock differences, unresolved distributor balance disputes, or redemptions with no sale record. Name the decision owner and the deadline before cutover.

Planning a voucher platform migration?

Replacing a legacy VMS or consolidating PIN and eTopup channels? Send us your current platform, channels and dealer tiers, and we will come back with a state-mapping outline and a realistic migration sequence.

Talk to MoboGage about your EVD System migration or email projects@mobogage.com.

Diagram of an electronic voucher management system for GCC telecom operators showing catalog, reseller tiers, PIN custody, eTopup channels, and reconciliation

Electronic Voucher Management System for GCC Telecom Operators

by with No Comment EVD Software

An electronic voucher management system is the control plane for prepaid value. It generates and inventories serialised vouchers or float, pushes them through reseller hierarchies, sells them over POS, USSD, portal or API, and reconciles stock, sales and charging at day-close. Operators and VAS partners in the GCC (Saudi Arabia, the UAE, Qatar, Kuwait, Bahrain and Oman) ask more of it than most markets do. Catalogs carry several currencies, distributor trees run four or five levels deep, field teams work in Arabic and English, and many deals are delivered through partners. A platform that can’t handle those conditions tends to show it during Ramadan and Eid, when volumes peak and finance tickets pile up.

Definition

TermPlain meaning
Electronic voucher management system (EVMS / VMS)Software that owns voucher or prepaid-value lifecycle: create → secure → distribute → sell/redeem → report/reconcile
EVDElectronic voucher distribution: moving prepaid value through channel nodes (often with wallets and POS)
eTopupTypically PINless airtime credit from dealer float to subscriber MSISDN
Control planeThe system of record for stock, hierarchy policy, PIN custody, and day-close truth

In brief: a GCC prepaid programme usually needs an electronic voucher management system that owns catalogs, reseller tiers, PIN custody and reconcile, and a single-channel top-up tool won’t cover that. PINless credit matters too, because Saudi and UAE retail leans on it while partners keep selling serialised vouchers (see electronic top-up for telecom airtime). And when the steering committee compares vendors, judge them on lifecycle and day-close evidence with the EVMS buyer checklist, not on slides. For background on electronic reloading versus physical cards, Wikipedia’s electronic reloading page is a fair summary, and GSMA Mobile for Development has written on the cost side of electronic airtime channels (GSMA article on airtime distribution savings).

Why a Gulf operator ends up treating the electronic voucher management system as infrastructure

Prepaid still pays for a big share of retail connectivity in the Gulf. Selling airtime, bundles or partner vouchers looks simple until the operating details arrive. Picture a national distributor in Riyadh funding sub-dealers in Jeddah and Dammam. Or a Dubai aggregator exposing APIs to super-apps, or a Kuwait retailer whose POS has to cope when coverage drops. Finance wants one version of inventory. Fraud wants PIN custody and velocity limits. The channel team wants commission that matches the contract tree it already signed.

Those demands meet in the EVMS. Without one, programmes tend to run on portals, partner spreadsheets and charging adapters held together by hand. With one, generation policy, credit limits, sale channels and reconcile packs all use the same words. That’s why MoboGage positions EVD System as a premium application for telecom and VAS rather than a “voucher printer.”

If the terms are blurry (EVD, VMS and the rest), start with What is electronic voucher distribution (EVD)?.

What GCC tenders actually ask for

A caveat first. What follows is the requirements language we see in RFPs. It isn’t a statement about any country’s regulation, and it isn’t a claim about EVD System’s certification status.

Catalogs that change every salary week

GCC programmes mix local-currency airtime denominations with partner gift or OTT SKUs, promo bundles and sometimes dual-face value for expatriate corridors. Around holidays and salary weeks the catalog moves fast. Product teams should be able to publish a denomination or change an expiry rule without reprinting stock or raising an emergency database ticket. Micro-denoms and bundles belong in the same place as classic face-value vouchers.

Currency precision is a detail that catches teams out. Under ISO 4217 the riyal and the dirham have two decimal places. The Kuwaiti and Bahraini dinars and the Omani rial have three. Store every amount in minor units per currency, or a regional rollup will round fils and baisa into errors.

Hierarchies that mirror the signed contract

A flat “every retailer is equal” portal breaks distributor agreements of the kind common in Saudi Arabia, the UAE and wider MEA. You need master distributors, sub-distributors and retail points, each with wallet transfer rules, credit limits and commission settlement that follow the paper contract. We recommend encoding the tree you already have. More on that in multi-tier reseller voucher distribution.

PIN custody and day-close

Serialised secrets haven’t gone away. Partner products, gift-style SKUs and hybrid print paths still use them. Encryption at rest is the minimum. The hard part is a day-close that ties inventory status, sales and charging credits together. Insist on lifecycle states, blacklisting, two-person reversals and exception reason codes. We cover this properly in voucher reconciliation and PIN security.

eTopup next to PIN stock

Busy retail in the UAE and Saudi Arabia often prefers PINless credit to an MSISDN straight from dealer float. That doesn’t make the EVMS redundant. The dealer holds float instead of PIN stock, but hierarchy, limits and reconcile stay exactly where they were. Many GCC stacks run both modes under one policy, which we think is the sensible design: one hierarchy, one set of limits, two product types.

Arabic screens and residency questions

Field teams and L1 support usually need Arabic and English labels, receipts and training packs. IT and risk will ask where production data and backups live (Saudi Arabia’s Personal Data Protection Law and its data-transfer rules make this a standard questionnaire item), which subprocessors touch PIN material, and how access is logged. Treat bilingual UX and residency as things you verify in the RFP and the architecture review. Don’t accept them as marketing claims unless your legal and delivery teams have confirmed them for that specific deal.

Selling through an SI or VAS partner

A lot of GCC and MEA wins go through systems integrators and VAS partners who already have the operator relationship and the tender experience. A vendor that can sit behind that partner as a technology layer (APIs, POS, hierarchy config, training) fits how procurement really buys. That’s how we position it: MoboGage as the product and engineering layer, the SI or partner as the face of delivery when that’s the commercial route.

A GCC EVMS RFP table you can reuse

Requirement areaWhat “good” looks like in evaluationWhy it matters in GCC/MEA
Catalog & denominationsMulti-product, multi-denom, promo windows without reprintFestival and salary-week catalog churn
Hierarchy & walletsMulti-tier nodes, credit limits, parent→child transfer policyDistributor contracts are rarely flat
ChannelsUSSD, Android/Linux POS, portal, app, API on one float/PIN truthOmnichannel retail + aggregators
PIN custodyEncrypted secrets, reveal-at-sale, blacklist, audit trailPartner SKUs and hybrid stock
ReconciliationInventory vs sales vs charging with exception ownersFinance and fraud close the same day
eTopup modeIdempotent PINless credit, float debit, clear failure codesHigh-velocity prepaid retail
LocalisationArabic/English UI and receipts as configurableBilingual field and support teams
Residency & accessDocumented hosting options, access logs, subprocessorsRisk and IT questionnaire items
DeliverySI/partner-ready APIs, config, training packsTender and outsourced ops models

Use it alongside the longer evaluation grid in How to choose an electronic voucher management system.

What EVD System does and doesn’t claim

EVD System is MoboGage’s electronic voucher distribution and management platform. It handles generation, inventory, lifecycle, reseller POS on Android and Linux, apps and APIs, for telecom airtime, gift-style vouchers and related prepaid products.

For a GCC buyer, the honest pitch is this. It controls the voucher lifecycle with real states and policies, not just a sales screen. Its wallets, limits and multi-tier distribution look like what channel teams already run. It sells PIN and eTopup-style credit under the same commercial rules. Day-close is built around inventory, sales and charging lining up. And it works when an SI or VAS partner wants an outsourced technology layer instead of building voucher plumbing in-house.

We won’t put operator counts, uptime percentages or “market leader” badges here. Large suppliers in the region publish those: Comviva cites uptime figures for PreTUPS and Seamless highlights ERS 360 deployments. Those claims are worth asking about, but they don’t tell you how your own hierarchy will close a day. Ask every vendor, us included, for a scoped demo on your hierarchy slice, catalog and exception paths. MoboGage is headquartered in Jaipur and has no GCC office; regional delivery runs through partners, and we say so in tenders.

A rollout order that holds up on an ordinary Tuesday

Start by mapping one country’s commercial tree: the master distributors, their credit terms, and which SKUs are PIN and which are PINless. Then pilot a single slice, one region or one partner with a limited set of POS and USSD, and prove that float or PIN debit and charging credit line up. Localise the screens dealers and L1 really use into Arabic and English before anything else gets translated, and check the settlement calendar: Saudi Arabia’s weekend is Friday-Saturday, while the UAE moved to Saturday-Sunday in 2022, so a regional programme can have bank cut-offs on different days.

Before peak week, encode the festival policy: temporary limits, promo denominations, and dual control on bulk loads. Do a hardening pass on reversal windows, velocity limits, lost-terminal disable and day-close owners. Only then expand to more APIs, more POS families and more product lines, once finance actually trusts the close.

Be wary of a demo that only shows a happy-path sale from a pre-funded test wallet with no exception screen; it shows the easy 90 seconds of the process.

Count your disputes before you call anyone

If your GCC prepaid stack still reconciles in spreadsheets after the partner portals close, take one week of sales by channel and write down every float or PIN dispute. That list usually shows whether you need a stronger EVMS lifecycle, cleaner eTopup discipline, or both under one control plane.

Operators and VAS partners looking at EVD System can read the electronic voucher management system overview, see About MoboGage, or reach the team through the contact / demo page · projects@mobogage.com · +91-9928 366 889.

FAQ

What is an electronic voucher management system in a GCC telecom context?

It is the platform that owns prepaid voucher or value lifecycle for an operator or VAS partner: generation, secure inventory, allocation through reseller tiers, sale or redemption across channels, and reconciliation against charging, so Saudi, UAE, and other Gulf programmes are not run from disconnected portals.

Do GCC operators still need PIN vouchers if they have eTopup?

Often yes for partner products, gift-style SKUs, hybrid print, or contract paths that still require serialised secrets. eTopup handles high-velocity PINless airtime; EVMS keeps lifecycle and reconcile when PINs remain in the mix.

Why do multi-tier reseller hierarchies matter in Saudi Arabia and the UAE?

Distributor agreements typically cascade credit and commission through several layers. A flat retailer portal cannot encode those contracts; wallet transfers, limits, and settlement must follow the real tree.

Should Arabic UI and data residency be RFP requirements?

Yes as evaluation criteria. Ask vendors to demonstrate bilingual operator-facing screens and to document hosting, backup, and access-control options. Confirm any residency or localisation commitment in writing for your deal, do not treat brochure language as compliance proof.

How should SI and VAS partners buy EVMS?

Many tenders favour a partner who already wins telecom work and outsources the voucher platform. Evaluate APIs, config tooling, training, and commercial willingness to sit behind the SI, then run a joint pilot with the operator hierarchy.

Where does GSMA fit this conversation?

GSMA Mobile for Development material on airtime distribution discusses cost dynamics of electronic channels versus traditional scratch-card logistics. Use it as industry context for business cases; build your own market model for GCC economics.

Multi-tier reseller voucher distribution hierarchy diagram from distributor to dealer to retailer for electronic vouchers

Multi-Tier Reseller Distribution for Electronic Vouchers

by EVD Software

Multi-tier reseller voucher distribution is how most prepaid airtime and digital voucher value actually reaches the street: a distributor funds dealers, dealers fund retailers, retailers sell on POS, USSD, or appeach tier holding wallet balance, credit limits, and a slice of commission. An electronic voucher distribution hierarchy encodes that commercial reality in software so float, stock, and settlements stay auditable. Operators and VAS partners across GCC and MEA markets live this model daily; the platform either matches how the channel works, or the channel invents workarounds.

TL;DR

  • Hierarchy is not a UI treeit is wallets, limits, transfer rules, and commission logic that field managers will use under pressure.
  • Typical chain: operator / VAS admin distributor dealer retailer / agent, with optional regional splits.
  • Credit limits and offline POS sync are where programmes succeed or leak; treat them as first-class design.
  • Commissions should be configurable per tier and productnot hardcoded one discount for everyone.
  • For the lifecycle layer that sits above hierarchy, see the electronic voucher management system product page.

Why hierarchy exists (and why flat portals fail)

Prepaid distribution in many markets grew from physical logistics: master distributors held cartons, sub-dealers took boxes, retailers sold cards. When programmes went electronic, the people structure stayed. What changed was the objectwallets and digital stock instead of cardboard.

A flat everyone is a retailer portal looks clean in a demo. It collapses under real channel politics:

  • Master distributors expect sub-dealer creation rights and margin.
  • Regional managers need visibility without the ability to raid another regions float.
  • Retailers need fast sale flows, not admin screens built for HQ.
  • Finance needs one ledger truth across tiers at day-close.

GSMAs work on agent and airtime distribution networks has long noted that mobile operators already rely on multi-layer retail reach to put airtime within an arms reachand that those networks are assets when building adjacent digital services (GSMA agent networks handbook context). Electronic voucher programmes inherit that same structural truth.

For vocabulary on EVD itself, see What is electronic voucher distribution (EVD)?.

Anatomy of an electronic voucher distribution hierarchy

A practical multi-tier model usually includes:

TierCommercial roleTypical system objects
Operator / VAS adminPolicy, catalog, root float, fraud rulesProducts, denominations, global limits, audit
Distributor / masterFunds region or brand channel; creates dealersParent wallet, transfer rights, reporting
Dealer / sub-distributorFunds retailers; may run own POS fleetWallet, credit limit, commission share
Retailer / agentSells to subscribersSale rights, low-balance alerts, limited admin
Terminal / userDevice or clerk under a retailerAuth, version, disablement

N-level trees are common. The point is not to maximise depth for sport. Every extra tier adds transfer latency, dispute surfaces, and training load. Design depth to match the markets existing commercial contractsthen enforce it in software so shadow hierarchies cannot form on WhatsApp.

Wallets and credit limits: the operating heart

In multi-tier reseller voucher distribution, each node typically holds:

  • Wallet balance Prepaid value available to transfer or sell.
  • Credit limit Ceiling on exposure (prepaid, postpaid-style credit, or hybrid).
  • Transfer permissions Who can push or pull float to children.
  • Product entitlements Which SKUs that node may sell (airtime, data, gift, OTT).

Credit limits are risk controls disguised as commercial terms. A distributor with uncapped children will eventually sponsor a fraud event. Temporary lifts for Eid peaks, salary weeks, or launch promotions belong in governed workflows with expirynot permanent just increase it tribal knowledge.

Low-balance notifications (SMS, app, email) keep the street selling. Without them, retailers claim stockouts while parent wallets sit idle upstairs.

Commissions without folklore

Commission design separates programmes that scale from programmes that argue monthly:

  • Per-tier rates Distributor, dealer, and retailer shares on the same sale.
  • Per-product rules Data bundles may differ from voice airtime; gift cards may differ again.
  • Timing Real-time wallet credit vs periodic settlement.
  • Clawbacks Clear policy when reversals happen.
  • Visibility Each tier sees its own earnings without leaking peer margins carelessly.

If commission math lives only in a side spreadsheet, the system of record is not the system. Encode rules, show statements, and reconcile commission totals into the same day-close culture you use for sales.

Offline POS sync in real channel conditions

Shop connectivity is uneven. GCC mall retail and dense urban MEA corridors may be fine; peri-urban and rural agents are not. Multi-tier distribution that assumes perpetual online POS will invent offline behaviour anywayusually badly.

Define explicitly:

  1. Which products may sell offline (if any).
  2. How local risk limits cap offline sales.
  3. How sync resolves conflicts when the server rejects a queued sale.
  4. How float is reserved or reconciled after reconnect.
  5. How long a terminal may remain offline before auto-disable.

Terminal managementversions, remote config, lost-device disablementbelongs in the same operating model. A hierarchy with orphaned POS still selling is not a hierarchy; it is a leak.

GCC / MEA operating context (without geo spam)

Channel reality in GCC and MEA prepaid markets often includes dense multi-brand retail, migrant-heavy prepaid bases, festival demand spikes, and partner-operated VAS distribution alongside opco-owned channels. Hierarchy software must tolerate:

  • Multi-currency or multi-denomination catalogs where programmes cross borders.
  • Partner white-label portals under opco policy.
  • Rapid onboarding of retailers without weeks of paper.
  • Reporting by region and partner that finance will actually open.

Mentioning the region once or twice is enough. Buyers know their markets; they need controls that fit, not slogan geography.

Comparison: flat vs multi-tier control

DimensionFlat retailer portalMulti-tier reseller hierarchy
Who creates sellersCentral admin onlyDistributors/dealers under policy
Float pathAdmin retailerCascaded wallets with limits
CommissionOften single discountConfigurable multi-level shares
Regional autonomyWeakNatural via subtree rights
Dispute surfaceAdmin vs allParentchild with audit
Fits existing contractsRarelyUsually
Risk if misconfiguredBroad over-permissionDeep trees without monitoring

Flat can work for a tiny pilot. Multi-tier matches how airtime already moves.

Buyer checklist for hierarchy platforms

CapabilityProve in discovery
N-level treeCreate distributor dealer retailer; show inheritance of policy
Wallet transfersPush/pull with approvals and audit
Credit limitsEnforce hard stop mid-sale; temporary lift with expiry
CommissionsMulti-level calc on one live sale; statement export
Channel paritySame float rules on POS, USSD, app, API
Offline syncDocumented behaviour + conflict resolution demo
ReportingBy tier, region, product; day-close pack
DisablementKill a lost POS; revoke a dealer without nuking the tree
OnboardingSub-user roles; KYC fields as your market requires

When comparing full platformsnot only hierarchyuse How to choose an electronic voucher management system.

How EVD System approaches hierarchy

EVD System by MoboGage treats dealer hierarchy and float as part of the prepaid control plane: allocation through master dealers and retailers, credit limits, multi-channel sale, and reconciliation. The goal is hierarchy dealers will trust on a busy afternoonnot an org-chart widget that finance cannot close.

Adjacent realitiesPINless eTopup off the same wallets, PIN lifecycle for hybrid stocksit beside hierarchy rather than replacing it. Channel design without lifecycle and security is incomplete; security without hierarchy that matches contracts will not get adopted.

Soft next step

Sketch your live commercial tree on one page: who funds whom, who sets limits, who earns what on a single airtime sale. Bring that page to vendor demos. If the platform cannot encode it without custom folklore, keep evaluating.

Learn more About MoboGage or start a scoped conversation via the contact page projects@mobogage.com +91-9928 366 889.

FAQ

What is multi-tier reseller voucher distribution?

It is the commercial and technical model where prepaid voucher or airtime value moves through nested partnerstypically distributor, dealer, and retailereach with wallets, limits, and commissions, down to a subscriber sale.

How many tiers should we configure?

Match existing contracts and management capacity. Start with the minimum depth that reflects who actually funds whom; add tiers only when a commercial role requires separate float and reporting.

What is the difference between hierarchy and EVMS?

Hierarchy is the channel and float structure. An electronic voucher management system covers lifecycle, security, channels, and reconciliationincluding hierarchy as a core module. Buyers usually need both connected.

How do commissions work across tiers?

On a successful sale, configured shares can credit parent and child wallets (or settle periodically). Rules should be product-aware and include reversal clawback policy.

Why does offline POS sync matter for hierarchy?

Retailers at the edge often have uneven connectivity. Without defined offline limits and sync conflict rules, parent wallets and child sales divergeand multi-tier trust collapses.

Can APIs sit inside the same hierarchy?

Yes. Aggregator or bank API nodes should consume the same float and fraud policy as POS retailers. Separate API float with weaker controls recreates leakage under a modern label.

Related operator reading: Pair this reseller model with electronic top-up for telecom airtime and voucher reconciliation and PIN security; see the EVMS product overview for the lifecycle control plane.

See the reseller hierarchy glossary entry.

Voucher reconciliation and PIN security diagram showing lifecycle states and day-close controls in an electronic voucher management system

Voucher Reconciliation and PIN Security in an Electronic Voucher Management System

by EVD Software

Voucher reconciliation is the day-close job of proving that the stock your platform holds, the sales your channel reports and the credits your charging system applied all describe the same vouchers. In an electronic voucher management system it sits right next to PIN security, because most of the gaps found at close come from one of two places: a counting fault somewhere in the pipeline, or a secret that left the building. This post walks through the mechanics: which records get matched, on which keys, with which time window, and what the leftovers look like.

For the wider platform scope, see the electronic voucher management system overview.

Voucher reconciliation starts with three ledgers

Every prepaid voucher programme produces three independent records of the same day. The IN or OCS writes a recharge CDR whenever a voucher or PINless top-up credits a subscriber. The EVD platform writes a sale ledger entry when a dealer sells. And the dealer wallet writes a debit for the value of that sale. Reconciliation is the join between them.

The charging side usually arrives as a file export rather than a live feed. On Ericsson-style charging the refill request goes over UCIP (an XML-RPC interface), and the fields worth keeping are the ones the request itself carries: subscriberNumber, originTransactionID, originTimeStamp, transactionAmount and transactionCurrency, plus the voucher serial when the refill was voucher-based. Other vendors name things differently, and the CDR export format can change between charging releases, so pin the field mapping in the interface document rather than in someone’s script. Diameter credit control (Gy/Ro, 3GPP TS 32.299) matters here mostly as context. It governs usage charging, not recharge, but the same OCS writes both kinds of record and the export often mixes them.

Standards writing points the same way. GovStack’s voucher and payment orchestration requirements ask for unique end-to-end identifiers, encrypted storage of sensitive voucher data, and reconciliation inside and across parties (voucher storage, audit, and reconciliation). GSMA’s analysis of airtime distribution costs explains why operators moved to electronic channels at all (GSMA on airtime distribution savings).

Day-close three-way match: IN/OCS recharge CDRs, EVD sale ledger and dealer wallet debits are normalised (E.164 MSISDN, UTC timestamps) and joined on transaction ID or serial within a 15-minute window; matched rows close, leftovers go to an exception queue with a reason code and owner.
The day-close three-way match.

Before you join anything, normalise

Most false mismatches we chase at close are formatting, not fraud. The commonest is the MSISDN. A POS in Riyadh may send 0551234567, the USSD gateway may send 966551234567 and the charging export may hold +966551234567. Convert all three to E.164 before matching: strip the plus sign or a leading 00, drop the national trunk prefix (the leading zero) and prepend the country code. E.164 numbers are at most 15 digits, which also makes a cheap sanity check for garbage input.

Time is the second trap. Charging nodes usually log in UTC, POS terminals log in local time, and a terminal whose clock has drifted can be minutes out. Convert everything to UTC first. Then match within a window instead of on exact timestamps: we use T+15 minutes after the sale timestamp as a default, widened for channels known to batch-submit (some offline POS fleets upload hours later). A sale near midnight UTC whose credit lands after the cut-off belongs in tomorrow’s charging file, so carry unmatched rows forward one day before calling them exceptions.

A worked day-close (illustrative figures)

The table below shows one dealer, one denomination, one day. All figures are illustrative; they are not from any operator.

CheckIN recharge CDRsEVD sale ledgerDealer wallet debitsResult
Count, SAR 10 vouchers4124154163 sales with no credit; 1 debit with no sale
ValueSAR 4,120SAR 4,150SAR 4,160SAR 30 and SAR 10 to explain
Matched on serial / txn ID within T+15 min410410410Closed
Matched after carry-forward to next file222Closed next day (credit after cut-off)
Sale, no credit033Exception: charging reject after local commit, or redemption pending
Debit, no sale001Exception: double-submit from terminal; refund dealer

Read it right to left. The wallet has one more debit than the ledger has sales, which almost always means the terminal retried a sale after a timeout and the wallet service did not dedupe on the original transaction ID. The three sales with no credit need a look at the UCIP responses: a non-zero responseCode on the refill means charging refused it and the voucher should go back to available (or to the exception state if the PIN was already shown to a customer). See how unknown top-ups should be held and settled.

The unmatched-transaction query

A pseudo-SQL version of the report finance gets every morning. Table and column names are placeholders.

-- sales with no matching charging credit
SELECT s.txn_id, s.serial, s.dealer_id, s.msisdn_e164, s.sold_at_utc, s.amount
FROM evd_sale s
LEFT JOIN in_refill_cdr c
  ON (c.voucher_serial = s.serial OR c.origin_txn_id = s.txn_id)
 AND c.msisdn_e164 = s.msisdn_e164
 AND c.event_time_utc BETWEEN s.sold_at_utc
                          AND s.sold_at_utc + INTERVAL '15 minutes'
WHERE s.business_date = :close_date
  AND c.cdr_id IS NULL
UNION ALL
-- wallet debits with no sale
SELECT w.ref_txn_id, NULL, w.dealer_id, NULL, w.debited_at_utc, w.amount
FROM dealer_wallet_debit w
LEFT JOIN evd_sale s ON s.txn_id = w.ref_txn_id
WHERE w.business_date = :close_date
  AND s.txn_id IS NULL;

Each row it returns gets a reason code (timeout, double-submit, charging reject after local commit, clock skew, suspected fraud) and an owner. An unexplained row older than two business days should page someone.

What does a duplicate-PIN redemption look like in the logs?

Two redemption attempts on one serial, usually from different MSISDNs, close together. The first succeeds; the voucher server marks the serial used. The second comes back from charging with a “voucher already used” style response (the exact code depends on the voucher server; on Ericsson-style VS the voucher state is no longer available). In the EVD log it looks like this:

2026-09-30T18:02:11Z REDEEM serial=7741003921 msisdn=966551234567 result=OK   origin_txn=R-88120
2026-09-30T18:02:49Z REDEEM serial=7741003921 msisdn=966559876543 result=USED origin_txn=R-88131

One such pair is usually a customer who shared a photo of the receipt. Twenty pairs on one batch within an hour is a leaked batch file. Alert on the rate per batch, not on single events.

When that alert fires, blacklist the batch’s unredeemed serials straight away and tell the channel nodes holding it. After that, freeze reprints on the affected terminals, run an ad-hoc reconcile of the remaining inventory so the exposure is a number rather than a guess, and preserve the reveal and export logs.

Key handling

Voucher PINs are not card data, so PCI DSS does not formally apply to them. Its key-management requirements (in v4.0, requirements 3.6 and 3.7: documented key custodians, split knowledge, dual control, defined cryptoperiods and key retirement) are still the most practical template we know for PIN custody. Store PINs encrypted with AES under a data-encryption key, wrap that key with a key-encryption key held in an HSM (AES key wrap per NIST SP 800-38F / RFC 3394), and keep HSM administration away from application admins. ISO/IEC 27001 gives the management-system frame; Annex A control 8.24 covers the use of cryptography. None of this implies EVD System holds any particular certification, and you should ask any vendor, us included, for evidence rather than a logo.

Reveal is the other half. Log every reveal once (user, terminal, batch, timestamp and MSISDN where relevant) and require a second approver plus a reason code for any reprint.

Lifecycle states, and one transition we would remove

StateMeaningTypical controls
Generated / intakeBatch created or imported under policyBatch metadata, denomination, expiry, encryption plugin
AvailableEligible for allocationNot yet assigned to a channel node
AllocatedAssigned to distributor / dealer / walletHierarchy transfer rules, credit limits
Sold / issuedRevealed or committed to a saleFloat debit, reveal log, channel id
RedeemedCharging accepted creditUnique redemption id, duplicate block
ExpiredPast validityReporting and write-off policy
Cancelled / blacklistedRemoved from sale (theft, error, fraud)Batch or serial block, audit reason
Pending / exceptionAmbiguous after timeout or partial failureHuman queue with owner

Every transition should leave an audit record, ideally in append-only (WORM-style) storage. Our opinion, which some vendors will dispute: there should be no path from Redeemed back to Sold or Available at all. Once charging has confirmed a credit, the fix for any error is a compensating adjustment on the subscriber balance, raised in charging, never an edit to the voucher’s state. Platforms that allow the reverse transition make every redemption deniable. Some vendors market flexible status changes as a feature (Comviva’s PreTUPS VMS page, for instance, describes changing voucher status “just in time” for stolen and damaged stock); for stock that has not been redeemed that is useful, so the question to ask is which transitions are allowed after redemption, and who approves them.

For how stock moves through resellers, see What is electronic voucher distribution (EVD)?.

Questions for a vendor demo

Ask them to run the unmatched report above on their own demo data, with a deliberately skewed terminal clock, and to push a reprint request through dual control while you watch. And ask who, by role, can export clear PINs from production; the right answer is nobody, and if the vendor needs to check, note that down.

If a vendor can only demo “generate PIN, show on phone”, that tells you most of what you need. How to choose an electronic voucher management system has the full evaluation grid.

EVD System

EVD System by MoboGage covers generation or intake, hierarchy allocation, multi-channel sale, the redemption path and the day-close pack described above. Talk to us via About MoboGage or the contact page (projects@mobogage.com, +91-9928 366 889). If you can, bring last week’s exception list.

Related reading: how the three ledgers fit together in an EVMS architecture; electronic top-up for telecom airtime covers the PINless side of the same close, and multi-tier reseller voucher distribution covers how dealer wallets are funded. Moving off a legacy platform? The EVMS migration playbook shows how lifecycle states and dealer balances carry across, and the EVMS glossary defines the terms used on this page.

FAQ

What is voucher reconciliation in telecom prepaid?

It is the daily match between voucher inventory states, channel sales with their wallet debits, and charging redemptions, so finance and fraud teams can close the day with every difference explained and owned.

How does PIN security relate to an electronic voucher management system?

An EVMS holds voucher secrets for their whole life. PIN security is the set of encryption, key custody, access, reveal and redemption controls that stop those secrets turning into unauthorised credit.

Can we reconcile if we only run PINless eTopup?

Yes, but the objects change. You match float debits and sales against charging credits by transaction ID and MSISDN rather than by voucher serial. Operators that still sell any PIN products usually keep EVMS-grade audit for those.

What should a day-close pack include?

Opening and closing inventory or float, sales by channel and dealer, redemptions, cancels and expiries, and an aged exception list with an owner and a reason code on every row.

How do we handle a compromised batch?

Blacklist the unredeemed serials in the batch, notify the channel nodes holding it, preserve reveal and export logs, and reconcile the remaining inventory immediately. Write the playbook before you need it.

Is encryption alone enough?

No. Encryption without role control, reveal policy, device hygiene and named reconcile owners still fails in ordinary operations.

Diagram of an electronic top up system for telecom airtime

Electronic Top-Up System for Telecom Operators

by EVD Software

An electronic top up system (also called eTopup or PINless airtime distribution) lets mobile operators and their reseller hierarchies credit prepaid subscribers directly without handing over a printed scratch PIN. Value sits in dealer wallets as pre-funded float or an approved credit limit, the recharge request travels to the operator’s charging platform over USSD, POS, mobile app, or partner API, and the subscriber’s balance updates in seconds. Operators adopt it when physical card printing costs and denomination rigidity alongside warehouse leakage outweigh the familiarity of scratch cartons on a retail shelf.

TL;DR: eTopup vs PIN voucher distribution

Model What the dealer holds How the subscriber gets credit Primary operational control
eTopup (PINless recharge) Pre-funded wallet float or credit limit Direct recharge call (e.g. UCIP Refill or UpdateBalanceAndDate) to the MSISDN at sale time Float reservation, idempotent retry keys, and timeout reconciliation against charging CDRs
PIN voucher (EVD / scratch) Allocated serial batches or print-on-demand PIN entitlements Subscriber dials or enters a secret PIN after purchase to redeem value HSM-backed PIN custody, batch activation gates, and serial state tracking from generated to redeemed

In practice, dealer float replaces physical inventory exposure, so wallet reservations and velocity caps alongside day-close exception queues become the core operating controls across USSD, Android or Linux POS, dealer web portals or mobile agent apps and partner APIs. Operators choose eTopup when they need rapid bundle changes and lower card operating costs, while keeping a full electronic voucher management system whenever serialised PIN lifecycles or hybrid stock with batch-level reconciliation remain part of the commercial mix. Research from GSMA Mobile for Development has long examined how shifting prepaid volume from scratch cards to electronic channels reduces manufacturing and distribution overhead.

What an electronic top up system actually does

In daily retail operations, a shopkeeper takes cash or a digital payment from a subscriber, keys the MSISDN (normalised to E.164 format) and selects a denomination or data bundle, after which the platform reserves the dealer’s float and instructs the operator’s IN or OCS to credit the account. No carton is opened in a warehouse, and no PIN sheet is photocopied in a back office. Every transaction either closes with a confirmed charging correlation ID or enters a tracked pending state that finance can reconcile at day-close.

Industry literature refers to this flow as electronic reloading or direct top-up. Wikipedia’s overview of electronic reloading traces the transition away from physical prepaid cards toward commercial retailer load and digital credit, which provides helpful context when briefing channel teams that still plan around physical card stock.

Deploying eTopup does not force an operator to retire vouchers everywhere at once. Multi-country operators run both side by side, using PINless eTopup for everyday prepaid refills while keeping serialised PIN stock for rural wholesalers or gift and OTT products.

Comparing eTopup, EVD PIN print and physical scratch cards

Dimension Physical scratch cards EVD PIN print / electronic PIN sale Electronic top up (eTopup)
What the dealer holds Printed cards with concealed PINs Digital PIN inventory released at sale or print-on-demand Wallet float value with no PIN issued to the subscriber
Theft and leakage risk High across warehousing and transport Contained when PINs stay encrypted in a vault until sale No PIN leakage; duplicate recharges and float misuse are the main risks
Denomination or bundle update Requires a print and distribution cycle Catalogue or batch policy update Immediate product catalogue and charging profile update
Subscriber experience Scratch coating and dial USSD string Receive printed or SMS PIN and redeem Direct balance or bundle credit to MSISDN
Reconciliation focus Physical batch manifests vs activated sales Serial lifecycle states vs charging redemptions Dealer wallet debits and holds vs charging CDR credits
Best commercial fit Offline or remote print-heavy retail Markets needing gift vouchers, partner PINs, or hybrid stock High-velocity prepaid refills, micro-denominations, dense agent networks

Physical scratch cards remain familiar to cash-based retailers, yet they carry printing and warehousing overhead plus stock shrinkage that digital channels eliminate. Electronic PIN printing still fits wherever a bearer secret is required for gift cards or utility tokens, whereas eTopup fits wherever the commercial act is crediting a subscriber’s phone number immediately from a controlled dealer wallet. For the broader terminology across these models, see our guide to electronic voucher distribution (EVD) for full definitions across both models.

Dealer float: the real inventory of eTopup

Removing physical cards makes dealer float the working inventory of the distribution network. Operating an eTopup hierarchy requires five linked ledger steps:

  1. Onboard each hierarchy tier (master distributor, sub-distributor, dealer, and retail POS agent) with explicit parent-child rules.
  2. Fund distributor and dealer wallets against verified bank transfers, cash deposits, or maker-checker credit allocations.
  3. Enforce per-tier credit limits and velocity caps so a compromised terminal cannot drain upstream float.
  4. Convert wallet reservations into debits only on confirmed charging success, and credit float back only through audited reversals.
  5. Expose live balance and hold views so field supervisors do not rely on chat screenshots to verify stock.

A core ledger rule is separating reservation from debit inside the dealer ledger. When a retailer submits a top-up, the platform places an atomic hold on the dealer’s available float (tracked in ISO 4217 integer minor units, including three-decimal Gulf currencies such as the Kuwaiti dinar, Bahraini dinar, and Omani rial) before the charging adapter sends the request to the IN or OCS. If charging returns a confirmed success (responseCode = 0 on UCIP), the hold converts into a final debit and posts commission. If the request receives an explicit reject, the hold releases immediately. When a recharge call times out without a reply, the reservation stays locked under a pending-unknown state until a status query or the T+1 charging CDR file proves whether the subscriber received the credit.

When dealers cannot see their reserved versus available float clearly, they maintain side ledgers on paper or spreadsheets, which turns ordinary timing differences into support disputes. Credit limits also need policy-driven temporary lifts for salary weeks or festival peaks rather than manual database edits at midnight.

eTopup channels that move prepaid airtime

A production eTopup platform routes every retail and digital channel through one channel gateway, one float ledger, and one duplicate-detection policy.

USSD and SMS remain the primary interface where feature phones and assisted street retail dominate. Menus have to stay shallow to avoid session timeouts, and every request must log the target MSISDN, the dealer ID, the transaction amount, and the upstream result code. Android and Linux POS terminals serve high-throughput counters with receipt printing and device binding, alongside dealer web portals for bulk wallet transfers and sub-agent management. Mobile agent apps cover field sales and low-balance alerts, while partner APIs connect banks, super-apps, and payment aggregators using the same composite idempotency keys and velocity limits enforced on retail terminals.

Choosing between eTopup-first and a full EVMS

Most steering-committee debates come down to whether an operator needs a standalone PINless recharge switch or a combined voucher and eTopup control plane.

When an eTopup-first rollout fits

An eTopup-first scope makes sense when almost all prepaid volume is direct PINless credit to MSISDNs, commercial teams ship weekly bundle or promotional price changes that cannot wait for print runs, and dealer complaints centre on card stockouts across rural branches. It assumes your engineering team will invest in resilient charging adapters, client-generated idempotency keys, and automated timeout resolution.

When to keep a full electronic voucher management system

A full electronic voucher management system remains necessary when you run physical or hybrid PIN stock that needs serial-level lifecycle states, distribute gift cards or OTT entitlements alongside airtime, or require batch blacklisting and HSM-backed PIN custody for revenue assurance.

In GCC and MEA deployments, operators commonly combine both models by running MoboGage’s EVD System as the inventory and hierarchy control plane with PINless eTopup operating directly off the dealer wallet ledger. If your team is comparing vendor architectures for a tender, our guide on how to choose an electronic voucher management system covers the evaluation criteria across voucher vault security, IN charging integration, and day-close reconciliation.

Operational controls buyers should demand

During technical due diligence, ask shortlisted vendors to demonstrate seven controls on a live test bed rather than on slides:

  1. Idempotent top-up: The same client request ID never double-credits the subscriber or double-debits the dealer. (How that works when charging does not answer: airtime top-up timeouts and unknown status.)
  2. Explicit failure taxonomy: Clear separation between a network timeout (pending-unknown), a gateway validation error, and an upstream charging reject, with distinct operator reason codes.
  3. Reversal and refund governance: Automated correlation-ID reversals for incomplete legs kept separate from maker-checker financial refunds after settlement.
  4. Multi-level velocity limits: Configurable caps per dealer, per terminal, and per target MSISDN over rolling hourly and daily windows.
  5. Terminal binding and revocation: Ability to revoke a stolen POS session token at the gateway immediately and track active app versions across the fleet.
  6. Three-way day-close pack: Automated comparison of channel sales, dealer wallet movements, and charging CDR/EDR files with named owners for exceptions.
  7. Charging interface discipline: Documented UCIP, Diameter, or OCS API mappings scoped and tested against forced timeouts per project.

Without those seven controls in place, a high-throughput recharge switch simply creates reconciliation breaks faster than finance can investigate them.

Implementation path for an operator rollout

  1. Baseline current leakage and disputes: Measure where physical stock disappears, where promo launches stall, and how many daily support tickets stem from unconfirmed recharges.
  2. Pilot a single hierarchy slice: Start with one region and a controlled group of distributors on USSD or POS plus the dealer portal to prove wallet reservations and charging CDR alignment on live traffic.
  3. Encode commercial hierarchy rules: Configure multi-tier commission splits, credit limits, and maker-checker transfer approvals to match existing distributor contracts.
  4. Harden timeout and exception playbooks: Train operations and support teams on pending-unknown holds and T+1 CDR settlement before onboarding external aggregator APIs.
  5. Expand channels incrementally: Roll out mobile apps, additional POS hardware families, and bank or super-app APIs once the daily reconciliation pack closes cleanly.
  6. Run continuous revenue assurance: Monitor adapter latency, duplicate-block counts, and late-success refund exceptions as routine operational metrics.

Next steps for operators and VAS partners

If your prepaid distribution still depends on physical print logistics, or if your electronic channels leave finance reconciling wallet debits against charging CDRs in spreadsheets, audit one week of recharge traffic by channel and exception code. That baseline shows immediately where reservation holds, idempotency constraints, or voucher lifecycle controls are missing.

Operators and VAS partners evaluating MoboGage (founded in 2007 as company-reported, headquartered in Jaipur, India as its sole office, with company-reported reach across more than 1 million retailers and 17 countries via channel partners) can review the product overview on the electronic voucher management system page, see how a UCIP / IN charging integration handles recharge calls, read more About MoboGage, or reach the engineering team via the contact page (projects@mobogage.com, +91-9928 366 889).

FAQ

What is an electronic top up system?

It is software that lets dealers or digital channels credit prepaid subscribers from controlled float or wallets without issuing a physical scratch PIN, while posting the credit to the operator’s charging system and logging the transaction for day-close reconciliation.

Is eTopup the same as EVD?

Not quite. EVD (electronic voucher distribution) covers moving voucher value through reseller channels, whereas eTopup refers specifically to PINless airtime credit posted straight to the subscriber’s balance. Most operator deployments combine both models by running PINless eTopup as a primary sales mode on top of an EVD hierarchy and wallet ledger.

Do dealers still need inventory?

Dealers hold float inventory in the form of wallet balances and credit limits rather than cartons of printed cards. Serialised PIN inventory is still used alongside float whenever an operator sells voucher batches or third-party entitlements on the same terminals.

Which channels should we launch first?

Start with the channel that already carries your core prepaid volume, such as USSD or Android POS, and prove that dealer float debits and charging credits reconcile cleanly before adding partner APIs and mobile apps. Opening every channel on day one without a working day-close exception queue creates avoidable balance disputes.

When is a full EVMS still required?

A full EVMS is required whenever you manage serialised PIN lifecycles or hybrid voucher stock alongside multi-product catalogues for gift and OTT entitlements, or when finance requires batch-level inventory reconciliation beyond wallet float movements.

How does GSMA frame electronic airtime channels?

GSMA Mobile for Development research on airtime distribution savings examines how electronic top-up paths reduce scratch-card printing and warehousing expenses alongside channel discount costs compared with physical card distribution, providing a useful benchmark when building an operator business case.

Related operator reading: For the connected prepaid stack, compare voucher reconciliation and PIN security with multi-tier reseller voucher distribution, review our electronic voucher distribution (EVD) explainer, or see the EVMS product overview for full lifecycle controls across the prepaid stack.

For formal PIN voucher and eTopup definitions used across the prepaid stack, consult the EVMS glossary.

If your team is operating or bidding in the Gulf, read our regional guide to electronic voucher management for GCC telecom.

pos_evd-system

Telecom voucher distribution opportunity in United Kingdom

by EVD Software
  • The United Kingdom is a big market for telecom companies. The voucher management system in the telecom of the United Kingdom is still having great scope for business entrepreneurs. Telecom companies like O2, Vodafone are still using electronic voucher distribution for Airtime voice, Airtime Data and bundle recharges.

Major Telecom Companies in United Kingdom

  1. O2
  2. EE
  3. Vodafone
  4. Three

EE has the largest number of umbrella, including ASDA Mobile, BT Mobile, Plusnet, Virgin Mobile and HMD Mobile.

O2’s umbrella include Giffgaff, Tesco Mobile and Sky Mobile.

Three’s include iD Mobile and SMARTY, while Vodafone’s include Talk Mobile and VOXI.

 

How Electronic Voucher Management System deliver value to telecom subscribers in United Kingdom?

Voucher distiribution system by MoboGage is considered among top 5 voucher management system in the world. The innovative approach of MoboGage makes this platform unique and highly robust over high value of transactions.
MoboGage EVD System is used for following services
  • Digital Wallet
  • Airtime Recharge
  • Pay-TV Recharge
  • Data Recharge
  • OTT Subscriptions