MyevdS, Author at Electronic Voucher Management System - EVD System - MoboGage

MoboGage EVD System typographic card — CreditSync credit operations

CreditSync: Distributor and Agent Credit Limit Operations

CreditSync is MoboGage’s Established credit-operations capability for distributor and agent finance. It handles credit assignment, authorized limits, issuance, collections and overdue tracking, while authorized lenders keep their lending policies and decisions.

Distribution runs on working capital. When limits live in a spreadsheet and collections live in someone’s inbox, exposure is usually discovered at month-end. CreditSync puts distributor and agent credit operations in the same system as distribution, and leaves the regulated lending decision with the lender.

MoboGage lists CreditSync as Established under both retail (wallets and CreditSync) and banking (CreditSync operations). Company-reported heritage goes back to 2007 (IWT Group); MoboGage Private Limited was incorporated in February 2017 in Jaipur. Reach across 17 countries is company-reported business and project presence through partners; the only office is the Jaipur HQ.

Distributor and agent credit operations, defined

These are the daily controls around float funding: who can carry how much exposure, when value is issued against that limit, how repayments are recorded, and how overdue positions are aged and owned. The commercial problem is visibility and accountability. Whether a loan may be granted at all is a regulatory question for the authorized lender, and CreditSync is built around that split.

How a CreditSync limit check works

Each node in the hierarchy carries an authorized limit, the outstanding balance it owes, and any holds for transactions in flight. Available credit is the limit minus outstanding minus holds. When a distributor requests stock or float, the platform places a hold for the amount in the same database transaction that checks availability, so two requests arriving together can’t both pass against the same headroom. The hold turns into issued credit when the stock transfer commits, or is released if it fails.

Every limit assignment records who authorized it, the ceiling, effective dates and any product or channel restriction. Temporary raises carry an expiry date and need a second approver. A change is a dated, logged event; the old value stays visible in history.

Issuance, collections and overdue aging

Issuance posts value or float against the limit and is attributable to a node, a product context (airtime float versus catalogue float, for example) and a reference. Issuance that bypasses the limit check would recreate the spreadsheet problem, so the platform doesn’t allow it.

Repayments reduce exposure. Collections are easiest to match when each distributor pays into a reference the platform can recognise, such as a virtual account number or a wallet transfer with the distributor ID, so finance matches inflows automatically and only handles leftovers. The allocation order (fees first, then oldest principal, or another rule) is the lender’s policy, configured rather than coded. Partial payments and disputed amounts get their own states instead of a note in a comments field.

Overdue positions are aged by days past due into buckets the lender chooses; 1-30, 31-60, 61-90 and 90+ is a common convention. The platform tracks and flags. Escalation and recovery decisions belong to the authorized institution and its agents.

Who relies on it, and for what

The lender, bank or fintech keeps policy, underwriting and decision rights; the platform reflects the limits it authorizes and records issuance and collection events for portfolio monitoring. MoboGage supplies technology and integration, and regulated-service responsibilities stay with the client institution.

The distributor network owner sees hierarchy exposure (which nodes are near their limit, which are overdue, which collections cleared) in the same channel software used for electronic voucher management. Agents and retailers see their limit, balance and amount owed without phoning anyone, which means fewer failed sales caused by float running out unnoticed. Finance and channel operations get unique references and explicit states on issuance, repayment and aging, with owners on overdue queues and audit trails on corrections. Paired with reconciliation discipline, that shortens the month-end argument considerably.

Where CreditSync stops

The company profile is explicit that authorized lenders retain lending policies and decisions. CreditSync is not automated credit scoring, a bureau replacement or a substitute for a banking licence, collateral appraisal or credit-committee minutes. When it sits next to mobile money or merchant channels the same rule holds: technology connects the workflows, and regulated parties own regulated outcomes.

Proposed banking items such as a reconciliation exception hub or financial-crime evidence operations are separate roadmap topics, not Established CreditSync features, and are handled through discovery.

How it connects to EVD, the catalogue and wallets

Much airtime and utility selling is paid for with distributor credit. Connecting CreditSync to MoboEVD inventory movement and to a shared service catalogue keeps sales activity and credit exposure in one record. The hierarchies in multi-tier reseller voucher distribution are where limits get assigned. Wallet cash-in/out and bank connectivity can fund repayments; those flows are covered in the wallet deep-dive and on the mobile money platform with merchant payment page.

For platform selection, see how to choose an electronic voucher management system and the EVMS product overview.

A day in a channel’s credit cycle

In the morning, channel managers check nodes near their limit and the overdue buckets before approving large stock transfers. Around midday, issuance funds agents who are out selling vouchers and catalogue products. In the evening, collections and bank or wallet inflows are matched and exposure comes down. At month-end, finance wants issuance, sales and repayments to tie together in one report. On a festival weekend when sales spike, limit headroom decides how much agents can sell, so it gets watched as closely as POS availability.

Decisions to make before the pilot

Are limits monetary ceilings, product caps, or both? Do sub-agents draw on their parent’s capacity or hold their own limits? Who can raise a limit temporarily, and under what dual-control rule? Does overdue status trigger a soft warning or a hard block on selling? The last choice changes agent behaviour in the field the next day, so warn the field before switching on a hard block.

If limits originate in core banking or a lender system, document and version that interface. If issuance creates spendable EVD or wallet float, document that one as well, and name the person who owns unmatched issuance events.

Reports channel leaders open

Useful CreditSync reports are plain: limit utilisation by node, issuance by day, collections by method, overdue aging, and a list of limit changes with who made each one. When an auditor asks who raised a ceiling last Thursday, that last list is the answer. Exports should match how finance already reconciles to bank or wallet inflows, without manual reshaping. During diligence we show the data model and real screens, not mocked-up figures.

What to compare across vendors

Recharge suites such as Comviva PreTUPS list features like SOS and auto reload, auto stock transfer and segment-based commission, which advance or move dealer float. Those features are useful. What buyers should check, with any vendor including us, is whether the advance sits against an authorized limit with holds, an owner and an aging trail, or whether it is just a balance top-up. Ask for a demo of two concurrent stock requests against the last of a limit, and of a partial repayment.

Rollout and readiness

Delivery runs Discover baselines and owners → Design limits, responsibilities and interfaces → Pilot one network segment → Roll out → Operate and expand, with acceptance agreed under representative conditions. Scope, references and evidence are shared through due diligence. CreditSync operations are labelled Established; In development and Proposed portfolio items are not presented here as available.

Bring the lending owner, the distributor or agent segment, and the overdue measures you care about. Enquire through the contact / voucher management system page, projects@mobogage.com, or +91-9928 366 889. Founder & CEO: Sohan Lal Soni, MoboGage Private Limited, Jaipur.

Frequently asked questions

What is CreditSync?

CreditSync is MoboGage’s Established capability for credit assignment, limits, issuance, collection and overdue tracking for agent and distributor finance. Authorized lenders retain lending policies and decisions.

Does CreditSync replace a lender’s credit decisioning?

No. Lenders keep lending decisions. CreditSync connects authorized limits and operational tracking (issuance, collections, overdue status) to distributor and agent workflows so channel finance stays visible.

Who typically uses CreditSync?

Banks, licensed lenders, fintechs and distribution groups that fund agent or distributor float. Telecom and retail channel operators also use it when working capital for the hierarchy is part of the commercial model.

What operating events does CreditSync track?

Typical events include credit limit assignment, issuance against an authorized limit, repayments and collections, overdue aging, and status changes that channel managers and finance can review.

How does CreditSync relate to MoboEVD and wallets?

EVD and wallet platforms move product and balances; CreditSync tracks the credit that often funds those balances. Keeping lending policy with the authorized institution avoids mixing regulated decisions into channel software.

How do we pilot CreditSync?

Bound one distributor network or agent segment, agree limit owners and overdue measures, then expand. Contact projects@mobogage.com or the voucher management system enquiry page.

shared-service-catalogue-airtime-data-utilities

Shared Service Catalogue for Airtime, Data, Gift Cards and Utilities

A shared service catalogue is MoboGage’s Established capability for selling airtime, data, gift cards and utility services through scoped provider integrations with clear transaction tracking. Distributors and retailers get one digital offer instead of a drawer full of separate apps.

Retail and VAS networks rarely get into trouble because one recharge API is missing. The trouble starts when each new service arrives as another portal, another float and another reconciliation file, and by the third provider nobody at the counter is sure which balance pays for what. A shared catalogue keeps the front end consistent while each provider connection stays tightly scoped behind it.

The catalogue sits in MoboGage’s Established retail portfolio next to MoboEVD and CreditSync. Company-reported figures (reach across 17 countries through partners, and more than one million retailers using POS and airtime services) describe MoboGage’s wider operating context, not product SLAs. MoboGage’s only office is the Jaipur HQ.

What goes into a shared service catalogue entry

The catalogue is the list of things a channel user can sell, and each line is a record rather than a brochure tile. In our data model an entry carries: a SKU and provider ID; the product type (PIN voucher, PINless top-up, bundle, gift card, bill payment, prepaid utility token); either a fixed face value or an open range with minimum, maximum and step; currency; the channels allowed to sell it (POS, app, USSD, API); the commission and fee rule IDs; which float or inventory pool funds it; and effective-from and effective-to dates. Only privileged roles can publish a change, so a retired denomination stops selling at the date it was retired.

Each entry also points to a state model: what success, known failure, timeout and reversal look like for that provider, and who owns each one.

Airtime, gift cards and bills behave differently

Airtime and data are still the core in most markets. Depending on the operator interface, a product may be a PIN voucher sale, PINless electronic top-up, or a plan or bundle purchase, sold over POS, apps, USSD and SMS. The electronic top-up system post explains the PINless recharge transaction itself.

Gift cards come in two kinds. Some are imported serial stock with their own expiry; others are issued at the moment of sale through a provider API that returns the code. The receipt and the refund rule differ, so the catalogue shows which is which, and a just-in-time gift code is never treated like a pre-activated airtime card.

Utilities have the most steps. Bill payment is usually two calls: an enquiry with the customer account number that returns the name and amount due, then a payment that references the enquiry. Prepaid electricity in many markets returns a 20-digit STS token (IEC 62055-41), which has to be printed or sent by SMS exactly, because a mistyped token can’t be used on the meter. When a payment times out, the transaction is held, the provider is queried, and float is released or the payment confirmed. Decide before launch who retries, who refunds and who calls the provider.

Scoped provider integrations, in practice

The company profile says “scoped provider integrations” deliberately. Discovery covers credentials, test and production environments, rate limits, idempotency keys, duplicate detection, retry windows and ownership of unresolved exceptions. Interfaces are versioned. Two providers never share a state machine by assumption; each gets its own mapping from provider response codes to catalogue states.

The trust controls in the MoboGage profile apply: unique references, explicit states, duplicate prevention, controlled reversals and reconciliation. Privileged access, encryption, retention and recovery targets are set per engagement.

Who gets what out of it

The operator or aggregator can widen the merchant offer without adding channel software; new providers plug in behind the same retail screens, which is how many VAS partners grow past a single airtime brand. Voucher-backed products still follow the lifecycle described in our electronic voucher management system positioning.

The distributor can fund several catalogue products from one float where the commercial rules allow it, with hierarchy visibility as described in multi-tier reseller voucher distribution. The retailer gets one POS or app for airtime, data, gift cards and some utilities, with one receipt pattern, so staff can explain a timeout without ringing the helpdesk.

Finance and operations get a unique reference on every sale, the provider reference where one comes back, and an explicit state. Matching those against each provider’s settlement file is the daily work of retail control, and the reason buyers read voucher reconciliation even when some catalogue lines are PINless.

How the catalogue sits beside MoboEVD and wallets

Voucher-backed lines use MoboEVD inventory and activation. Wallet-funded lines use balances, cash-in/out and bank connectivity. Merchant payments and agency onboarding extend the same retail network when QR acceptance and cash workflows are in scope. If you’re comparing platforms, start with what is electronic voucher distribution and the EVMS buyer checklist.

What to ask vendors in discovery

Several platforms advertise third-party products on the POS: Seamless ERS 360 describes the POS as a one-stop shop for third-party products, and Emida lists bill payment, international top-up and stored value cards. Breadth of the menu is easy to show. Ask instead for a product sheet per provider line (type, channels, funding pool, commission rule, timeout owner) and for the state diagram behind it. Then ask to see one utility payment forced into a timeout and resolved, and a denomination retired mid-day. We will run the same tests on our platform.

Training should follow the catalogue: one receipt pattern, one helpdesk script for “provider is down”, one escalation owner per provider.

If a GCC or multi-country programme reuses a catalogue pattern, expect providers to behave differently country to country even when the screens look the same. Country reach in MoboGage materials means business or project presence through partners, not identical interfaces everywhere.

Starting with one provider

The company profile suggests a first pilot of one service provider or one distributor network, with agreed measures for inventory availability and unmatched value. Delivery follows Discover → Design → Pilot → Roll out → Operate and expand. The shared service catalogue is labelled Established. Proposed retail items such as settlement exception hubs or retail intelligence are roadmap topics only.

Bring the provider list you want first, the channels that have to sell them, and the person who’ll own reconciliation. Contact MoboGage through the voucher management system enquiry page, projects@mobogage.com, or +91-9928 366 889. Founder & CEO: Sohan Lal Soni, Jaipur, India.

Frequently asked questions

What is a shared service catalogue in an EVD or retail platform?

A shared service catalogue is a controlled list of sellable digital services (typically airtime, data, gift cards and utility payments) offered through scoped provider integrations with clear transaction tracking from the retail or agent channel to the provider.

Which service types can sit in one catalogue?

Established catalogue patterns include prepaid airtime and data, gift cards, and utility services. Each product maps to a provider interface, denomination or bill rules, commission scheme and settlement expectation.

How do provider integrations stay scoped?

Integrations are agreed per provider: credentials, transaction states, retries, timeouts, reversal rules and exception ownership. The catalogue exposes only products that have a live, tested interface and a commercial owner.

How does the catalogue help distributors and retailers?

Agents see one coherent offer instead of separate apps per provider. Inventory or float rules, commissions and receipts stay consistent, which reduces training load and mismatched settlement narratives.

Does a shared catalogue replace voucher inventory controls?

No. Catalogue products that are voucher-backed still rely on voucher lifecycle rules. Catalogue products that are PINless or bill-pay rely on float, eligibility and provider confirmation. Both can share retail channels under one operating view.

How should a catalogue pilot be bounded?

Pick one provider or one service family, agree availability and unmatched-transaction measures, then expand. Contact projects@mobogage.com or the voucher management system enquiry page to shape the pilot.

Voucher Generation, Inventory and Activation with MoboEVD

MoboEVD is MoboGage’s electronic voucher distribution capability. It handles voucher generation or import, controls digital inventory, runs inventory activation for sale, records redemptions, applies commissions and tracks distributor balances across POS, apps, USSD, SMS and API channels.

Ask three people in a prepaid business where a particular voucher is right now. Finance checks the month-end pack, fraud checks the reveal log, and the channel manager rings the regional distributor. If the three answers differ, the voucher generation and inventory activation process has a gap somewhere, and finding that gap is what this layer is for.

MoboGage Private Limited (Jaipur, India; heritage IWT Group 2007; incorporated February 2017) positions MoboEVD as an Established retail and telecom capability. Company-reported experience includes more than one million retailers using POS and airtime services, with business and project reach across 17 countries. The Jaipur headquarters is the only office, so “reach” means projects and partner presence rather than local branches.

Voucher generation and inventory activation in one state model

Marketing decides denominations, charging credits the subscriber, and this layer sits between them. In MoboEVD a voucher is always in exactly one state: available, allocated, activated, sold, redeemed, expired or cancelled. Each change is an event. It records a reference, the user and the time, and commission and distributor balances move with it.

Disputes usually start where one step lives outside the platform, in a spreadsheet or a side system nobody owns, and a distributor’s balance can’t be rebuilt three weeks later. That is the main reason operators evaluating an electronic voucher management system want the whole lifecycle on one accountable platform.

Generating a batch: serials, PINs and the print file

A generation request sets the denomination and quantity first. It also fixes the validity window, the product type and whatever batch attributes reporting will need later. Each voucher gets two numbers that serve different purposes. The serial is public, printed on the card, sequential within the batch and often carries a check digit; it is what support staff and reconciliation use. The PIN is the secret the subscriber enters, and it must come from a cryptographically secure random generator, never from the serial or a sequence.

PIN length is a security decision. A 14-digit PIN has 10¹⁴ possible values, so even with ten million live vouchers a random guess has about a one-in-ten-million chance of hitting one, and velocity limits on the redemption side cut guessing further. PINs are encrypted as soon as they are generated. For physical cards, the print file goes to the print vendor encrypted to that vendor’s key (PGP is common), with a separate manifest of serial ranges and counts that the vendor confirms back before the batch can be activated.

Many operators already have a voucher server or charging system producing stock and want it imported instead. That works too, provided every unit keeps its own identity on the way in, with its own serial, denomination, expiry and batch ID, with the file’s counts and value totals checked against the manifest before anything becomes available.

Allocation down the hierarchy

Stock is allocated to nodes in the hierarchy, from national and regional level through distributors and sub-dealers to retail points, according to commercial policy. Every transfer between nodes is a recorded event with a sender, a receiver, a serial range or count, and a reference, so a channel manager can see today who holds what. Master dealers mostly ask about two things: their balance, and when commission lands. So the platform tracks their exposure as stock and credit move down the tree, as multi-tier reseller voucher distribution describes.

Activation: as late as practical

Activation makes stock sellable on authorised channels. Unactivated inventory can’t leak usable PINs early and can’t be sold at a denomination marketing withdrew last week. Activation can be per batch, per serial range, or by rule per channel and role. We recommend activating close to the point of sale; stock that is live but idle carries risk without adding sales. Where the charging side keeps its own voucher state, as an Ericsson-style voucher server does, the platform’s activation and the charging-side state should be changed together and checked in the day-close.

Sale, redemption and commission

Established channels include POS (Android and Linux retail terminals among them), mobile and web apps, USSD, SMS and partner APIs. A sale debits the seller’s authorised balance or float and marks the voucher sold under a unique transaction reference. PINless electronic top-up can run alongside PIN sale where dealer float and charging integration allow it; see the note on an electronic top-up system for telecom airtime.

Redemption closes the loop: the PIN is accepted, charging or the provider credits the service, and EVD records a terminal state. Where emergency credit or intelligent-network rules apply, redemption connects to UCIP/IN environments, covered in the separate charging-integration post.

Commission schemes vary by market: flat per denomination, a percentage of face value, a channel bonus, or a split across hierarchy levels. MoboEVD posts the contracted rule per transaction and records which rule version applied. Balances move with issuance, sale, transfer and collection. Where agents need float on credit and a lender holds the lending decision, CreditSync handles it.

Who is allowed to generate, activate or cancel

The company profile’s trust guidance covers unique references, explicit states, duplicate prevention, controlled reversals and reconciliation. For vouchers, generation is a privileged role. So are bulk activation and cancellation, with dual approval for batches above an agreed value. Encryption and retention for PIN material and audit logs are agreed before go-live. With charging and provider systems, the interface version, retry rule and exception owner are written down. A person approves any mass cancel, forced expiry or balance correction. The approval is logged. Pair this with voucher reconciliation and PIN security so the month-end pack matches.

The operator’s view of all this is in the EVMS product overview. Service levels and assurance scope are agreed per engagement, and certifications are stated only where they are supported.

What to compare across vendors

Comviva’s PreTUPS VMS page markets flexible status changes and expiry-date modification to reduce dead stock. Those are useful levers, and they are also the operations an auditor will ask about. Whoever you shortlist, ask to see who can change a voucher’s state or expiry, whether a second approver is required, and how the change appears in the audit log and the next day-close. Ask how PINs are generated and how the print file reaches the printer.

Where this page fits on the site

For a general introduction, read what is electronic voucher distribution and the buyer checklist on how to choose an electronic voucher management system. This page is the operating detail behind them. Migrations, GCC rollouts, wallet and catalogue add-ons each get their own scoping; a shared service catalogue sits next to EVD when one counter sells airtime, data, gift cards and bill pay, and mobile money and merchant agency modules add cash and float.

Pilot one denomination set before you roll out

Delivery runs Discover, Design, Pilot, Roll out, Operate and expand. Discover looks at who uses the system today and what can’t change. Design sets scope and ownership, then architecture and controls. The pilot is narrow (one provider, or one channel, one town and one set of denominations) so that problems surface while they are cheap to fix. Measure acceptance under realistic load, not on a quiet test environment. Project scope, references and supporting records are shared through an agreed due-diligence process.

MoboEVD distribution is labelled Established in the company profile, backed by company-reported delivery experience. In-development or Proposed items elsewhere in the portfolio, such as settlement exception hubs or fuel extensions, are not presented here as available.

Talk to MoboGage about voucher inventory and activation

Start with one bounded workflow and one named owner. Enquire through the voucher management system contact page, email projects@mobogage.com, or call +91-9928 366 889. Founder & CEO: Sohan Lal Soni. Headquarters: Jaipur, India.

Frequently asked questions

What does MoboEVD cover in voucher generation and inventory activation?

MoboEVD supports generating or importing vouchers, managing digital inventory states, activating stock for sale, recording redemptions, applying commissions and tracking distributor balances across POS, apps, USSD, SMS and API channels.

How does voucher inventory stay controlled across a reseller hierarchy?

Stock moves through defined statuses (available, allocated, activated, sold, redeemed, expired or cancelled) with unique references and role-based permissions so distributors, sub-dealers and retailers only act within their authorised balances and denominations.

Can operators use both PIN vouchers and PINless top-up from the same platform?

Yes. Many deployments run PIN-based voucher sale alongside PINless electronic top-up from dealer float. Lifecycle rules for generation, activation, expiry and reconciliation remain under one control plane.

Which sales channels does MoboEVD support?

Company-reported channel support includes POS terminals, mobile and web apps, USSD, SMS and partner APIs. Channel mix is scoped per engagement so retail, agent and digital sales stay reconciled to the same inventory.

How are commissions and distributor balances handled?

Commission rules can be tied to denomination, channel, product or hierarchy level. Distributor balances update with issuance, sale, transfer and collection events so finance and channel ops see exposure without inventing a second ledger.

How do we start a MoboEVD pilot?

MoboGage follows a five-step delivery path: Discover, Design, Pilot, Roll out, Operate and expand. A typical pilot bounds one provider, denomination set or channel, with acceptance criteria agreed before wider rollout. Contact projects@mobogage.com or use the voucher management system enquiry page.

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

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:

Announce the freeze window early. Dealers should know a week ahead when stock purchases and wallet transfers pause, and for how long.
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.
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.
Snapshot and sign. Export balances per dealer and per tier, share them with the top distributors and get written acknowledgement before go-live.
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.

Electronic Voucher Management System for GCC Telecom Operators

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

Term	Plain meaning
Electronic voucher management system (EVMS / VMS)	Software that owns voucher or prepaid-value lifecycle: create → secure → distribute → sell/redeem → report/reconcile
EVD	Electronic voucher distribution: moving prepaid value through channel nodes (often with wallets and POS)
eTopup	Typically PINless airtime credit from dealer float to subscriber MSISDN
Control plane	The 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 area	What “good” looks like in evaluation	Why it matters in GCC/MEA
Catalog & denominations	Multi-product, multi-denom, promo windows without reprint	Festival and salary-week catalog churn
Hierarchy & wallets	Multi-tier nodes, credit limits, parent→child transfer policy	Distributor contracts are rarely flat
Channels	USSD, Android/Linux POS, portal, app, API on one float/PIN truth	Omnichannel retail + aggregators
PIN custody	Encrypted secrets, reveal-at-sale, blacklist, audit trail	Partner SKUs and hybrid stock
Reconciliation	Inventory vs sales vs charging with exception owners	Finance and fraud close the same day
eTopup mode	Idempotent PINless credit, float debit, clear failure codes	High-velocity prepaid retail
Localisation	Arabic/English UI and receipts as configurable	Bilingual field and support teams
Residency & access	Documented hosting options, access logs, subprocessors	Risk and IT questionnaire items
Delivery	SI/partner-ready APIs, config, training packs	Tender 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

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:

Tier	Commercial role	Typical system objects
Operator / VAS admin	Policy, catalog, root float, fraud rules	Products, denominations, global limits, audit
Distributor / master	Funds region or brand channel; creates dealers	Parent wallet, transfer rights, reporting
Dealer / sub-distributor	Funds retailers; may run own POS fleet	Wallet, credit limit, commission share
Retailer / agent	Sells to subscribers	Sale rights, low-balance alerts, limited admin
Terminal / user	Device or clerk under a retailer	Auth, 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:

Which products may sell offline (if any).
How local risk limits cap offline sales.
How sync resolves conflicts when the server rejects a queued sale.
How float is reserved or reconciled after reconnect.
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

Dimension	Flat retailer portal	Multi-tier reseller hierarchy
Who creates sellers	Central admin only	Distributors/dealers under policy
Float path	Admin retailer	Cascaded wallets with limits
Commission	Often single discount	Configurable multi-level shares
Regional autonomy	Weak	Natural via subtree rights
Dispute surface	Admin vs all	Parentchild with audit
Fits existing contracts	Rarely	Usually
Risk if misconfigured	Broad over-permission	Deep trees without monitoring

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

Buyer checklist for hierarchy platforms

Capability	Prove in discovery
N-level tree	Create distributor dealer retailer; show inheritance of policy
Wallet transfers	Push/pull with approvals and audit
Credit limits	Enforce hard stop mid-sale; temporary lift with expiry
Commissions	Multi-level calc on one live sale; statement export
Channel parity	Same float rules on POS, USSD, app, API
Offline sync	Documented behaviour + conflict resolution demo
Reporting	By tier, region, product; day-close pack
Disablement	Kill a lost POS; revoke a dealer without nuking the tree
Onboarding	Sub-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

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.

Check	IN recharge CDRs	EVD sale ledger	Dealer wallet debits	Result
Count, SAR 10 vouchers	412	415	416	3 sales with no credit; 1 debit with no sale
Value	SAR 4,120	SAR 4,150	SAR 4,160	SAR 30 and SAR 10 to explain
Matched on serial / txn ID within T+15 min	410	410	410	Closed
Matched after carry-forward to next file	2	2	2	Closed next day (credit after cut-off)
Sale, no credit	0	3	3	Exception: charging reject after local commit, or redemption pending
Debit, no sale	0	0	1	Exception: 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).

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

State	Meaning	Typical controls
Generated / intake	Batch created or imported under policy	Batch metadata, denomination, expiry, encryption plugin
Available	Eligible for allocation	Not yet assigned to a channel node
Allocated	Assigned to distributor / dealer / wallet	Hierarchy transfer rules, credit limits
Sold / issued	Revealed or committed to a sale	Float debit, reveal log, channel id
Redeemed	Charging accepted credit	Unique redemption id, duplicate block
Expired	Past validity	Reporting and write-off policy
Cancelled / blacklisted	Removed from sale (theft, error, fraud)	Batch or serial block, audit reason
Pending / exception	Ambiguous after timeout or partial failure	Human 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: 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.

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

An electronic top up system (often called eTopup or etopup airtime distribution) lets telecom operators and their dealers credit prepaid subscribers directly—usually without handing over a printed scratch PIN. Value sits in dealer wallets or float; the sale posts to charging over USSD, POS, app, or API; the subscriber’s balance rises in near real time. Operators use it wheanding over a printed scratch PIN. Value sits in dealer wallets or float; the sale posts to charging over USSD, POS, app, or API; the subscriber’s balance rises in near real time. Operators use it when physical card logistics, denomination rigidity, or channel theft risk outweigh the comfort of cartons on the shelf.

TL;DR

eTopup is PINless (or wallet-driven) airtime credit—not the same as printing EVD PIN stock for later scratch-style redemption.
Dealer float replaces physical inventory exposure; credit limits and wallet visibility become the operating constraints.
Channels typically include USSD, Android/Linux POS, portals, apps, and partner APIs against one float truth.
Choose eTopup when you need fast denomination changes and lower card OpEx; keep a full electronic voucher management system when PIN lifecycle, hybrid stock, and deep reconcile still matter.
GSMA research has long framed electronic airtime channels as a material cost lever versus scratch-card manufacturing and distribution (GSMA Mobile for Development).

What an electronic top up system actually does

In day-to-day ops language: a retailer or dealer takes cash (or wallet payment) from a subscriber, selects a denomination or bundle, and the platform debits the dealer’s float and instructs the operator’s IN / charging system to credit the MSISDN. No carton opens. No PIN sheet is photocopied in a back office. The transaction either commits with a unique id or fails cleanly with a retry path finance can understand.

That pattern is what industry writing usually means by electronic reloading or electronic top-up. Wikipedia’s overview of electronic reloading describes the shift away from physical prepaid cards toward retailer commercial load and digital credit—useful background when you brief product and channel teams that still think in “stock of cards.”

eTopup does not automatically mean you abandoned vouchers forever. Many markets run both: PINless top-up for high-velocity retail, and PIN or hybrid EVD where partners, regulations, or gift-style products still need serialised secrets. The decision is operating-model design, not a binary “digital good / cards bad” slogan.

How eTopup differs from physical scratch and EVD PIN print

Dimension	Physical scratch cards	EVD PIN print / electronic PIN sale	Electronic top up (eTopup)
What the dealer holds	Printed cards with hidden PINs	Digital PIN inventory (revealed at sale) or print-on-demand	Wallet / float value—no PIN to the subscriber in the common PINless path
Theft / damage risk	High along logistics	Lower if secrets stay encrypted until sale	Lowest for PIN leakage; float misuse becomes the main risk
Denomination change	Reprint cycle	Catalog / batch policy update	Immediate policy and product catalog updates
Subscriber experience	Scratch + dial PIN	Receive / enter PIN	Instant credit to MSISDN
Reconciliation focus	Card batches vs sales	PIN status lifecycle vs charging	Float movements vs charging credits
Best fit	Legacy retail, remote print-heavy markets	When PIN products or hybrid stock remain required	High-velocity prepaid, micro-denoms, dense dealer networks

Physical scratch remains familiar. It also carries manufacturing, warehousing, and leakage costs that electronic channels were built to reduce. EVD PIN paths still matter when you need serialised vouchers for certain partners or gift/OTT SKUs. eTopup shines when the commercial act is “credit this number now” and the dealer is effectively selling airtime value from a controlled wallet.

For the broader distribution vocabulary—EVD, VMS, and how they relate—see What is electronic voucher distribution (EVD)?.

Dealer float: the real inventory of eTopup

Once you remove cards from the story, float becomes the inventory. Operators and VAS partners typically:

Onboard a hierarchy node (distributor, dealer, retailer).
Fund that node’s wallet via bank transfer, cash deposit, or parent-wallet transfer.
Enforce credit limits so a single compromised terminal cannot empty the sky.
Debit float on successful top-up; credit float on approved reversals only.
Expose near-real-time balances so field managers stop chasing WhatsApp screenshots.

If dealers distrust the float screen, they invent side ledgers. Side ledgers become disputes. Disputes become “the platform is wrong” tickets that bury real fraud. Float UX and day-close packs are product requirements, not nice-to-haves.

Credit limits should mirror commercial reality: a busy urban POS needs different headroom than a rural kiosk. Temporary limit lifts for festivals or salary-week peaks belong in policy—not in emergency DBA edits at midnight.

Channels that actually move airtime

A credible electronic top up system treats channels as faces of one float and fraud policy:

USSD / SMS — Still dominant where feature phones and assisted retail are the norm. Keep menus short; log every attempt with MSISDN, dealer id, amount, and result code.
Android / Linux POS — Handhelds and shop terminals for assisted sales. Offline-capable behaviour matters where coverage drops; define what can sell offline and how sync conflicts resolve.
Dealer / retailer portals — Desktop replenishment, reporting, and sub-user management.
Mobile apps — Agent apps for street sales and notifications on low float.
APIs — Aggregators, banks, super-apps, and operator digital channels posting top-ups with the same velocity and duplicate controls as POS.

Omnichannel only counts if the same float ledger and duplicate/replay rules apply. A “web portal that sells without float debit” is a revenue leak dressed as a feature.

When operators need eTopup vs a full EVMS

Use this as a buyer checklist—not a marketing quiz.

Lean toward eTopup-first when:

Most prepaid volume is PINless credit to MSISDN.
Denomination and promo changes must ship weekly without print.
Dealer complaints centre on card stockouts and logistics lag.
You already trust (or will invest in) charging adapters and unique transaction ids.

Keep or prioritise a full electronic voucher management system when:

You still run physical or hybrid PIN stock that needs lifecycle states.
Gift cards, OTT entitlements, or partner PIN products sit beside airtime.
Finance needs inventory-vs-sales reconcile across serialised secrets, not only float.
Fraud teams care about batch blacklisting, PIN custody, and redemption audit as first-class objects.

In practice, many GCC and MEA operators land on a combined stack: EVMS as the lifecycle and inventory control plane, with eTopup as a primary sales mode off dealer wallets. That is how EVD System by MoboGage is usually positioned—float-backed channels under voucher and hierarchy discipline, not a disconnected “top-up gadget.”

If you are still comparing platform shapes, How to choose an electronic voucher management system walks the evaluation axes buyers actually argue about in steering committees.

Operational controls buyers should demand

Ask vendors to demonstrate—not slide-deck—the following:

Idempotent top-up — Same client request id never double-credits the subscriber.
Clear failure taxonomy — Timeout vs decline vs charging reject, with operator-facing codes.
Reversal policy — Who can reverse, within what window, with what dual control.
Velocity limits — Per dealer, per MSISDN, per terminal, per hour.
Terminal hygiene — Disable lost devices; push config; know which POS version is live.
Day-close pack — Float opening/closing, sales by channel, exceptions with owners.
Charging alignment — Sales and IN/OCS credits share one truth or an explicit exception queue.

Without those, you have a fast way to move money and a slow way to explain where it went.

Implementation path that survives a normal Tuesday

Map the pain — Where do cards disappear? Where do denomination changes stall? Where do channel sales disagree with charging?
Pilot one hierarchy slice — One region, limited dealers, USSD or POS + portal. Prove float debit and charging credit on ordinary traffic.
Encode commercial rules — Limits, commissions, and transfer approvals that match how distributors already work.
Harden exceptions — Train L1 on reverse/decline paths before you open API partners.
Expand by tier — Add apps, more POS families, and aggregator APIs once reconcile packs are trusted.
Operate — Treat eTopup as prepaid critical infrastructure: monitoring, on-call, terminal lifecycle, fraud reviews.

Skip the demo that only shows a happy-path top-up with a pre-funded test wallet and no exception screen.

Soft next step

If your prepaid mix is still dominated by print logistics—or your “electronic” path is a patchwork of spreadsheets and partner portals—map one week of airtime sales by channel and float dispute volume. That short exercise usually clarifies whether you need eTopup discipline, full EVMS lifecycle, or both.

Operators and VAS partners evaluating EVD System can review the product overview on the electronic voucher management system page, learn more About MoboGage, or reach the 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—typically without issuing a physical scratch PIN—while posting the credit to the operator’s charging system and logging the transaction for reconciliation.

Is eTopup the same as EVD?

Not exactly. EVD (electronic voucher distribution) emphasises moving voucher value through reseller channels. eTopup often means PINless airtime credit. Many platforms combine both: hierarchy and wallets from the EVD world, with eTopup as a primary sale mode. See What is EVD?.

Do dealers still need inventory?

They need float inventory—wallet balance and credit limits—not necessarily printed cards. PIN inventory still appears when you sell serialised vouchers alongside PINless top-up.

Which channels should we launch first?

Start with the channel that already carries your prepaid volume (often USSD or POS), prove float and charging alignment, then add APIs and apps. Launching every channel on day one without day-close discipline creates dispute factories.

When is a full EVMS still required?

When you manage PIN lifecycle, hybrid physical/electronic stock, multi-product catalogs (gift/OTT), or finance needs serialised inventory reconcile beyond float movements alone.

How does GSMA frame electronic airtime channels?

GSMA Mobile for Development writing on airtime distribution savings discusses how electronic top-up paths can reduce scratch-card manufacturing and channel discount costs relative to traditional card distribution—useful context for CFO-level business cases, not a substitute for your own market model.

Related operator reading: For the connected prepaid stack, compare voucher reconciliation and PIN security with multi-tier reseller voucher distribution; see the EVMS product overview for lifecycle controls.

For PIN vs eTopup definitions, see the EVMS glossary.

Operating in the Gulf? Read electronic voucher management for GCC telecom.

Electronic voucher management system checklist for telecom operators

How to Choose an Electronic Voucher Management System (Telecom Buyer Checklist)

An electronic voucher management system is the software that keeps prepaid value under control, from generation or intake, through the dealer hierarchy and every sales channel, to redemption in charging and a day-close finance will sign off on. For MNOs, MVNOs and VAS partners, getting the shortlist wrong costs real money. It shows up later as disputed float, PINs exposed without anyone noticing, and reprints you thought you’d left behind with scratch cards.

EVD System by MoboGage is built to be that control plane for telecom and gift-card distribution. But this page isn’t a brochure. It’s the checklist we’d want a buyer to bring to our own discovery call, so your RFP tests what actually matters once you’re live.

The short version: buy for a lifecycle that runs all the way through reconciliation, not for a slick “generate PIN” demo. Settle your operating model (opco-owned, VAS-operated or hybrid) before anyone argues about screens. Insist on a concrete charging/BSS path, POS and offline behaviour that has been proven somewhere, and day-close packs an auditor would accept. Treat security as PIN custody plus velocity and replay controls, not a logo on a slide. And treat vendor rankings with caution; a reference who can walk you through an ordinary week of exceptions tells you more.

Opco, VAS partner or hybrid: decide this first

An opco, MNO or MVNO should own stock and fraud policy, with the EVMS plugging cleanly into charging and a hierarchy that mirrors national distribution. A VAS or distribution partner needs something more productised for running several opcos: white-label portals and POS, commissions, partner float and APIs, without rebuilding the lifecycle for each brand. A hybrid arrangement only works when it’s crystal clear who holds the keys, who runs L1 support, who owns blacklist and expiry, and how disputes escalate.

If your team can’t answer those ownership questions yet, pause the software comparison and settle the operating model. A common sticking point is who owns a compromised batch: who can blacklist it, who tells the dealers, and who signs off the write-off.

What an electronic voucher management system must cover, gate by gate

Take each product on your shortlist and walk it through six gates. Generation or intake comes first: controlled serialisation, denomination rules, batch metadata and expiry, with secrets never stored as plain text. Inventory next, with statuses you can believe (available, allocated, sold, redeemed, expired, cancelled). Then allocation across multi-level dealers, with float, credit limits and transfer rules your ops team will actually follow. Sale, over portal, Android/Linux POS, app, USSD/SMS and API, all under one fraud policy. Redemption, where credit reaches charging with duplicate and replay controls. And finally reconciliation: daily packs covering volumes, wallets and exceptions, with a named owner for every mismatch.

A gap at any gate becomes leakage later. Hybrid physical and electronic programmes are fine, as long as print logistics are an option rather than the default cost of selling prepaid.

Two gates deserve a concrete test. For redemption on Ericsson-style charging, ask the vendor to show the UCIP refill request and response for one sale, including the originTransactionID they send and how a non-zero responseCode appears on the retailer’s screen. For offline POS, ask how the terminal sells without a connection: typically a small encrypted pool of pre-allocated PINs or an offline value cap per terminal, a sync that uploads sales with their local timestamps, and a rule for what happens when the server has already cancelled a voucher the terminal sold offline.

A 1 to 5 scoring grid for vendor demos

Area	Questions to ask in discovery	Weak answer sounds like…
Security & trust	How are PINs encrypted at rest and in transit? Who can reveal a PIN? Velocity, duplicate, and replay controls? Audit logs for operator review?	“We use HTTPS” (and nothing else).
Hierarchy & float	Multi-level trees, credit limits, commissions, operator stock vs partner float separation?	Flat “admin / agent” only; float explained with a spreadsheet.
POS & field ops	Which Android/Linux families are in production (e.g. Sunmi-class)? Online/offline sale and sync rules? Remote disablement?	“Any Android phone” with no offline story.
APIs & charging	Documented sale/inquiry/reversal (where allowed)? Concrete charging/BSS integration path?	Slide that only says “API ready.”
Reporting & reconcile	Near real-time by region/dealer/product/channel? Day-close packs finance will use? Exception queues with owners?	Marketing dashboards; no mismatch workflow.
Catalog	Airtime, data, gift, OTT without fracturing inventory? PIN sale and PINless eTopup on the same wallet where required?	One denomination demo; gift cards “phase 2 forever.”
Commercial & hosting	Licensing, hosting (on-prem/private cloud), transaction economics, upgrade and support SLAs?	Opaque pricing until late; support undefined.

Weight the rows before the demos, not after. A vendor who scores high on UI polish but low on reconciliation and charging is offering a sales screen rather than an EVMS.

When to walk away

Some answers should end the conversation, or at least put heavy conditions on it. The demo stops at “PIN appears on screen” and there’s no day-close pack. The vendor can’t tell the EVMS lifecycle apart from EVD channels, or worse, describes them in ways that contradict each other. You’re shown vanity metrics (“best in world,” ratings you can’t verify, inflated client counts) instead of reconcile references. Offline works “verbally,” with nothing written about sync conflicts or disabling a terminal. Reversals and duplicate controls are pushed to “custom, later.” Or your dealers would end up running a shadow system for float, because they already don’t trust the screen.

Six questions to bring to the kickoff

Who owns voucher secrets and the HSM/key ceremony, the opco or the partner? What’s the pilot slice (region, dealer tier, POS count), and what are its exit criteria? Where do sales and charging disagree today, and which report will prove they agree after go-live? What’s the end-to-end procedure for blacklisting a compromised batch? How are terminals versioned, configured and disabled when they’re lost or compromised? And what’s the training and L1 model for master dealers in the first 90 days?

A vendor with live rollouts should answer most of these from memory and show the matching screen or document for the rest.

Reading competitor brochures

The established suppliers publish feature lists that overlap heavily. Comviva describes PreTUPS VMS as covering the voucher lifecycle from product management to consumption, with expiry-date modification and status changes, and cites uptime figures for the platform. Seamless positions ERS 360 around dealer management, campaigns and third-party products on the POS. Telepin and Emida describe eTopUp, eVoucher, PINless and QR top-up. These are real capabilities. What brochures rarely show is the exception path: the unmatched report, the timeout handling, the dual-control reprint. Score that part from the demo, for every vendor including us.

EVMS vs EVD vs eTopup (so RFPs stay coherent)

Term	Meaning in practice
EVMS / VMS	Lifecycle & inventory core: generate/receive, serialise, allocate, expire, cancel, reconcile.
EVD	Distribution/channel layer: how digital vouchers reach resellers and customers via POS, apps, USSD, APIs.
eTopup	Often PINless recharge: credit via dealer float or API without handing over a scratch PIN.

When buyers say “we need EVD software,” they usually mean this whole prepaid stack. Deep dive: What is electronic voucher distribution (EVD)?.

How MoboGage EVD System maps to this checklist

We position EVD System as the electronic voucher management system control plane for operators and VAS partners: hierarchy and float you can audit, Android/Linux POS (Sunmi-class included) next to portals and APIs, and a BSS-adjacent path to charging scoped per contract. The exact device fleets, offline behaviour and charging adapters belong in discovery. A one-size public matrix would mislead you.

Product overview: Electronic voucher management system for telecom. Contact: voucher-management-system-mobogage · projects@mobogage.com · +91-9928 366 889.

FAQ

What is an electronic voucher management system?

Software that controls prepaid voucher value end to end: generate or intake stock, inventory and hierarchy allocation, multi-channel sale, redemption into charging, and reconciliation, typically for telecom airtime, data, gift cards, and related digital products.

How do I choose an electronic voucher management system for telecom?

Score vendors on security and PIN custody, hierarchy and float, POS and offline realism, charging or BSS path, day-close reconciliation, catalog breadth, and commercial clarity. Prefer references that describe exception handling.

Is EVMS the same as EVD software?

Not exactly. EVMS or VMS is the lifecycle core; EVD is the channel and distribution layer. Strong platforms connect both under one inventory and fraud policy.

What should VAS partners prioritise?

Prioritise multi-opco operating efficiency: white-label portals and POS, commissions, partner float separation, APIs, and reconciliation packs for each opco without rebuilding the core.

Can an EVMS run hybrid physical and electronic stock?

Yes. Require one control framework for batches, status, expiry, and audit so print logistics are optional.

Does offline POS matter?

In many GCC, MEA, and emerging retail networks, yes. Ask how offline sales sync, how conflicts resolve, and how lost terminals are disabled.

What is the fastest way to fail an EVMS project?

Skipping operating-model ownership, launching without a charging truth, and ignoring day-close exceptions until finance escalates.

What to do this week

Run the scoring grid against your shortlist. If you’d like a discovery-style walkthrough of how EVD System handles hierarchy, POS and reconcile for your operating model, talk to MoboGage. Before you score anyone, though, agree shared definitions inside your own team.

GCC buyers can use the GCC EVMS RFP requirements table. Moving off a legacy platform? Read the EVMS migration playbook. For wider industry context, see GSMA mobile money industry research and this electronic reloading overview.

Product: https://evdsystem.com/electronic-voucher-management-system-evd-telecom/ · Guide: https://evdsystem.com/evd-software/what-is-electronic-voucher-distribution-evd/ · Contact: https://evdsystem.com/voucher-management-system-mobogage/ · Email: projects@mobogage.com · Phone: +91-9928 366 889

Entity: MoboGage · EVD System · Jaipur, India Last updated: 21 Sep 2026 (IST)

What Is Electronic Voucher Distribution (EVD)? A Practical Guide for Telecom Operators & VAS Partners

Electronic voucher distribution is the control plane for prepaid value—how operators and VAS partners generate, allocate, sell, and reconcile airtime and digital vouchers without the drag of physical stock.

Free Call

Distributor and agent credit operations, defined

How a CreditSync limit check works

Issuance, collections and overdue aging

Who relies on it, and for what

Where CreditSync stops

How it connects to EVD, the catalogue and wallets

A day in a channel’s credit cycle

Decisions to make before the pilot

Reports channel leaders open

What to compare across vendors

Rollout and readiness

Frequently asked questions

What is CreditSync?

Does CreditSync replace a lender’s credit decisioning?

Who typically uses CreditSync?

What operating events does CreditSync track?

How does CreditSync relate to MoboEVD and wallets?

How do we pilot CreditSync?

What goes into a shared service catalogue entry

Airtime, gift cards and bills behave differently

Scoped provider integrations, in practice

Who gets what out of it

How the catalogue sits beside MoboEVD and wallets

What to ask vendors in discovery

Starting with one provider

Frequently asked questions

What is a shared service catalogue in an EVD or retail platform?

Which service types can sit in one catalogue?

How do provider integrations stay scoped?

How does the catalogue help distributors and retailers?

Does a shared catalogue replace voucher inventory controls?

How should a catalogue pilot be bounded?

Voucher generation and inventory activation in one state model

Generating a batch: serials, PINs and the print file

Allocation down the hierarchy

Activation: as late as practical

Sale, redemption and commission

Who is allowed to generate, activate or cancel

What to compare across vendors

Where this page fits on the site

Pilot one denomination set before you roll out

Talk to MoboGage about voucher inventory and activation

Frequently asked questions

What does MoboEVD cover in voucher generation and inventory activation?

How does voucher inventory stay controlled across a reseller hierarchy?

Can operators use both PIN vouchers and PINless top-up from the same platform?

Which sales channels does MoboEVD support?

How are commissions and distributor balances handled?

How do we start a MoboEVD pilot?

Why voucher platform migrations fail

Step 1: Inventory what actually has to move

Step 2: Map lifecycle states before moving stock

Step 3: Move PIN data without ever seeing it

Step 4: Freeze, drain and snapshot dealer float

Step 5: Cut over channels in waves

Step 6: Parallel run and reconciliation gates

GCC and MEA notes

Questions to ask any EVMS vendor about migration

How MoboGage EVD System approaches a migration

FAQ

What is an electronic voucher management system?

How long does an EVMS migration take?

How do we move PIN data securely?

What happens to dealer wallet balances during cutover?

Should we cut over all channels at once?

When should we roll back?

Planning a voucher platform migration?

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

What GCC tenders actually ask for

Catalogs that change every salary week

Hierarchies that mirror the signed contract

PIN custody and day-close

eTopup next to PIN stock

Arabic screens and residency questions

Selling through an SI or VAS partner

A GCC EVMS RFP table you can reuse

What EVD System does and doesn’t claim

A rollout order that holds up on an ordinary Tuesday

Count your disputes before you call anyone