EVMS Archives - Electronic Voucher Management System - EVD System

Electronic voucher management system architecture diagram: channels, gateway, voucher vault, inventory, wallet ledger, reconciliation and charging adapter to operator IN

Electronic Voucher Management System Architecture: Components, Data Flows and Integration Points

October 19, 2026

by MyevdS with No Comment EVD Software

Definition. An electronic voucher management system architecture is the set of services that carry prepaid value from creation to cash: a protected voucher vault, an inventory and lifecycle engine, a dealer wallet and credit ledger, a channel gateway for POS, USSD, apps and partner APIs, a charging adapter into the operator’s IN or OCS, a reconciliation engine that closes the day against charging records, and an audit store underneath them.

Every sale writes to three records (voucher inventory, the dealer wallet and the charging platform), and day-close checks that they agree. The design work concentrates on the interfaces between components, especially the charging call that times out. MoboGage EVD System is built as the control plane for this stack, with charging connectivity scoped per project.

Vendor brochures usually draw an EVMS as a row of boxes joined by arrows. The version a charging team sketches in the first week of a project carries more annotations: a question mark beside the IN, an arrow marked “retry?”, and a note from finance asking which system wins when the totals disagree at midnight.

This page describes the architecture at that level of detail. It is written for the people who integrate with an operator’s prepaid stack: charging engineers and IT architects first, then procurement teams and VAS partners. For plain definitions first, the EVMS and EVD glossary covers the vocabulary used here.

Electronic voucher management system architecture: the seven components

An electronic voucher management system is several services rather than one application. Each has its own owner, its own availability target and its own security rules. Splitting it this way makes RFP answers comparable between vendors and makes an outage easier to place.

Component	What it owns	Talks to	Failure that hurts most
Voucher vault and generation	PIN creation or intake of operator batches, encryption keys, serial ranges	HSM or key store, inventory engine, print vendors for physical stock	Clear-text PIN files on a shared drive; a leaked batch that cannot be blocked quickly
Inventory and lifecycle engine	Status of every serial: generated, available, allocated, sold, redeemed, expired, blocked	Vault, dealer ledger, charging adapter	Two systems that each think they own status
Dealer wallet and credit ledger	Float, credit limits, transfers down the hierarchy, commission postings	Channel gateway, finance/ERP, credit operations	Balances that move without a matching transaction ID
Channel gateway	Authentication and routing for Android/Linux POS, USSD, SMS, apps, web portal and partner APIs	Ledger, inventory, terminal management	Retries that create a second sale
Charging adapter	Recharge, balance query and voucher redemption calls into IN/OCS	Operator charging platform, reconciliation	Timeouts treated as failures, or as successes
Reconciliation engine	Matching sales, wallet debits and charging records; exception queues	All three ledgers, charging CDR files, finance	Breaks found at month-end instead of the next morning
Audit and reporting store	Immutable event log, CDR/EDR history, maker-checker approvals	Every component, auditors, revenue assurance	Reports built from a database that ops can edit

Terminal management (app versions, device binding, remote disable) and the admin console cut across all seven, and belong inside the security boundary. A stolen POS that still holds a valid session token is a channel incident and a fraud incident at once, so remote disable should revoke the token at the gateway, not just lock the app.

Why the vault stays separate

The vault is the one component where a single exported file can be worth the face value of a whole batch. PINs should be generated with a cryptographically secure random generator inside a protected boundary, stored encrypted under a data-encryption key, and released one at a time at the moment of sale. That data key is itself wrapped by a key-encryption key held in an HSM (AES key wrap as specified in NIST SP 800-38F and RFC 3394), and key generation, rotation and retirement follow a documented lifecycle such as the one in NIST SP 800-57. Admins see serials and statuses, never PINs in bulk.

Operator-supplied batches go through the same boundary. The file is decrypted inside it, its record count and value total are checked against the batch manifest, and the serials become “available” only after a second person approves the load. Our voucher reconciliation and PIN security article covers custody in more depth.

Following one sale through the stack

Walking a single transaction through the components shows where each design choice matters. The scenario is illustrative: a retailer on a Sunmi-class Android POS sells a low-denomination airtime PIN in the early evening. The retailer sits under a sub-dealer, who sits under a regional distributor.

The POS sends a signed sale request to the channel gateway with its terminal ID, the retailer’s user ID, the product code and a client reference generated on the device.
The gateway checks the session, the device binding and the retailer’s velocity limits, then forwards the request with the same client reference.
The ledger reserves the sale amount, net of the retailer’s commission, in the retailer wallet. Nothing is debited yet.
The inventory engine picks the next available serial in that denomination, marks it “sold-pending” and asks the vault to release the PIN.
The ledger commits the debit, the inventory engine marks the serial “sold”, and the PIN goes back to the POS for printing.
Later the subscriber dials the recharge code. The charging platform either validates the PIN against voucher data it holds or calls the EVMS redemption API, depending on how the operator split responsibilities.
The redemption event lands in the charging CDR file, and at day-close the reconciliation engine matches it to the sale.

PINless eTopup skips the vault. Step 4 becomes a recharge call through the charging adapter. On Ericsson-style IN that is normally a UCIP Refill request to the AIR node carrying subscriberNumber, transactionAmount, transactionCurrency, a refillProfileID and the adapter’s own originTransactionID; some operators use UpdateBalanceAndDate for direct balance credits instead. Other OCS platforms expose their own recharge APIs. Removing the PIN changes where the risk sits. A PIN sale depends on custody of the secret, while an eTopup depends on knowing the outcome of a network call that may never have answered; see airtime top-up timeout handling for how that gap is settled. The electronic top-up system post covers the eTopup flow in more detail.

What each transaction record should carry

Reconciliation can only match on fields captured at sale time. If a legacy platform leaves a field in this list empty, expect the corresponding breaks to stay unresolved.

Field	Why finance or fraud needs it
Internal transaction ID and client reference	Lets retries be recognised as the same sale
Dealer ID at each tier, retailer ID, terminal ID	Commission, liability and stolen-device tracing
Channel (POS, USSD, app, API partner code)	Channel-level margin and fraud patterns
Product code, denomination, serial number (PIN sales)	Inventory status and batch blocking
MSISDN (eTopup)	Matching against charging CDRs
Request and response timestamps in UTC plus local time	Day-close cut-off disputes across time zones
Charging result code and charging transaction ID	Proof that value reached the subscriber
Wallet balance before and after	Fast answers to dealer balance complaints

Store MSISDNs in E.164 form (country code, no leading zero or plus sign) and timestamps in ISO 8601 with an explicit offset. Mismatched number formats and clock zones cause many of the false breaks at close.

Where timeouts hide money

A familiar operations ticket reads: the dealer says the subscriber got no credit, the POS showed an error, and the wallet was debited anyway. The reverse also happens. A frequent cause is a timeout between the EVMS and charging, where the request left and no definite answer came back, so the platform has to decide what happened without knowing.

The handling we design for starts by treating “unknown” as a status of its own. The transaction stays pending, the dealer’s funds stay reserved, and the POS tells the retailer to wait instead of selling again.

Retries reuse the original client reference. The gateway enforces it with a unique constraint on terminal ID plus client reference, so a repeated request returns the first result rather than creating a second sale. The charging adapter keeps its own mapping from that reference to every originTransactionID it sent, so a second recharge for the same sale can be refused and any retry is traceable.

The outcome is then settled from evidence: a balance or account query to charging (UCIP GetBalanceAndDate or GetAccountDetails, or refill history where the AIR release exposes it), or the charging CDR at day-close. Only then does the ledger commit or release the reservation. A credit that charging has confirmed is never reversed silently; any correction is a linked adjustment signed off by an approver.

Most pending items resolve within minutes. The rest go to an exception queue with a named owner, rather than to a dealer chat group.

Day-close: three ledgers that must agree

At the end of the business day the reconciliation engine compares three independent records:

Inventory: serials that moved to “sold” and PINless sales recorded by the channel gateway.
Dealer ledger: wallet debits, reversals and commission postings for the same period.
Charging: redemptions and recharges from the operator’s CDR or EDR files.

The output separates three groups. Matched transactions close. Timing differences, such as eTopups whose timeout or late-evening credit falls into the next charging file, carry forward and settle from that file. True breaks go to the exception queue with the dealer, terminal and charging transaction ID already attached, so whoever picks them up does not have to rebuild the context.

PIN redemptions run on a longer clock, because a subscriber may redeem days after purchase. The engine tracks sold-but-unredeemed value by batch and age, which also gives finance its breakage view as batches near expiry.

If the current platform cannot produce that three-way split by the start of the next business day, a component is missing, usually the reconciliation engine, and the work is happening in spreadsheets.

Deployment questions in GCC and MEA projects

Architecture reviews in the Gulf and the wider MEA region return to a short set of topics. Each has more than one workable answer, and each should be settled in writing before build starts.

Hosting and data residency. Many operators want the EVMS in their own data centre or an in-country cloud region. Confirm what the regulator and the operator’s security policy require for subscriber data and, separately, for PIN data, because the answers can differ.

Charging integration ownership. Decide whether the IN validates PINs itself or calls the EVMS. Either works; mixing the two across denominations makes reconciliation harder.

High availability. Active/standby across two sites is a common pattern. The vault and the ledger need synchronous or otherwise consistent replication so a failover cannot lose a committed debit, while reporting can tolerate lag.

Language, currency and migration. Dealer-facing screens and receipts usually need Arabic and English, and VAS partners serving several markets need multi-currency catalogues stored in each currency’s minor units (ISO 4217 gives the Kuwaiti dinar, Bahraini dinar and Omani rial three decimal places). Our GCC telecom EVMS guide lists these requirements in an RFP table. Few operators start from nothing, so plan how serial status and dealer balances move from the old platform; the EVMS migration playbook walks through the cutover gates.

Architecture checklist for vendor reviews

Use this during technical due diligence alongside the commercial EVMS buyer checklist. Public material on this topic is mostly product documentation for single components: voucher servers, switching platforms, government payment requirements. Few of them describe the joins between components, so that is where the questions below focus.

Question to ask	A good answer sounds like	Red flag
Where are PINs generated and decrypted?	Inside an HSM or equivalent boundary, released per sale, with key ceremony records	“In the database, encrypted with a config key”
How does a retry avoid a double recharge?	Client reference carried from POS to charging, enforced at gateway and adapter	“The POS doesn’t retry”
What happens on a charging timeout?	Pending state, status query, CDR-based resolution, linked adjustments	Automatic refund to the dealer after N seconds
Can a batch be blocked in minutes?	Batch and serial-range block pushed to charging, audited	Requires a vendor ticket
How are dealer balances proven?	Every wallet movement tied to a transaction ID, balance before and after	Nightly balance recalculation
What does day-close produce?	Matched, timing and true-break counts per channel and dealer by next morning	A sales report
Who approves sensitive actions?	Maker-checker on batch loads, credit limits, manual adjustments	Single admin role
How is the charging link specified?	Interface document per operator, scoped per project, with test cases	“We connect to all operators”

Ask each shortlisted vendor, MoboGage included, to demonstrate two rows live: a forced charging timeout resolved through the pending path, and a batch block that reaches charging.

How MoboGage EVD System maps to this architecture

MoboGage designs EVD System as a control plane for prepaid value rather than a recharge screen, so each component above corresponds to a named module with an owner. MoboEVD handles voucher generation or import, inventory, activation and redemption tracking; see voucher generation, inventory and activation. Dealer hierarchy and wallets follow the market’s actual structure from master distributor to retailer, as described in multi-tier reseller distribution.

CreditSync manages distributor and agent credit limits, issuance and collections (CreditSync credit operations). The shared service catalogue puts airtime, data, gift cards and utilities behind one product model. The charging adapter covers UCIP/IN recharge, eligibility and emergency credit workflows, described in UCIP / IN emergency credit integration; connectivity to any specific operator is scoped per project.

MoboGage’s heritage dates to 2007 (company-reported), and its only office is the headquarters in Jaipur, India. As company-reported figures, its platforms serve more than 1 million retailers using POS and airtime services, with project reach across 17 countries delivered through channel partners. Anonymised examples from telecom charging and service distribution programmes are on the case studies page, and the EVMS product overview summarises modules and channels.

Frequently asked questions

What are the main components of an electronic voucher management system?

A voucher vault for PIN generation and protection, an inventory and lifecycle engine, a dealer wallet and credit ledger, a channel gateway for POS, USSD, apps and APIs, a charging adapter into the operator’s IN or OCS, a reconciliation engine, and an audit and reporting store.

How does an EVMS connect to the operator’s charging system?

Through a charging adapter that sends recharge, balance and redemption requests to the IN or OCS. On Ericsson-style IN this is often UCIP; other platforms expose their own recharge APIs. The interface and test cases are agreed per operator and per project.

What is the difference between PIN voucher and PINless eTopup flows in the architecture?

PIN sales draw a serial from inventory and release the PIN from the vault; the subscriber redeems later. PINless eTopup sends a recharge straight to charging at the moment of sale. For PIN products the main control is custody of the secret; for eTopup it is handling recharge requests that time out without a definite response.

How should an EVMS handle a top-up that times out?

Keep it pending, hold the dealer’s funds in reservation, block a second sale under the same reference, and resolve it from a status query or the charging CDR. Correct a confirmed credit with an approved, linked adjustment rather than a silent reversal.

What does day-close reconciliation compare?

Three ledgers: voucher inventory and channel sales, dealer wallet movements, and charging records. The output should separate matched transactions, timing differences that carry forward, and true breaks with an owner.

Can an EVMS run on-premise for data residency?

Yes. Operators commonly host the EVMS in their own data centre or an in-country cloud region. Settle the requirement for subscriber data and PIN data separately, since policies can differ.

TL;DR

An electronic voucher management system (EVMS) is the control plane that governs prepaid value from generation or intake through inventory, dealer allocation, sale, redemption into charging, and day-close reconciliation. See also: electronic voucher management system architecture. Electronic voucher distribution (EVD) is the commercial and channel process of moving that value through reseller and agent networks. This glossary defines the terms telecom operators, VAS partners and RFP teams actually use when comparing platforms—PIN vs ePIN, voucher lifecycle, denomination catalogs, reseller hierarchy, agent commission, reconciliation, UCIP/IN emergency credit, distributor credit operations, shared service catalogues, and the prepaid value control plane. Definitions are written for citeable AI answers and buyer clarity, not marketing fluff.

Entity: MoboGage EVD System (evdsystem.com) is MoboGage’s electronic voucher management and distribution platform for telecom airtime, data, gift cards and loyalty vouchers. Company-reported footprint: experience since 2007, 1 million+ retailers using POS and airtime services, and project reach across 17 countries. Headquarters: Jaipur, India. Channel-partner locations are not offices.

Why this glossary exists

Operators evaluating an EVMS run into the same vocabulary gap in RFPs, SI workshops and AI-assisted research: vendors recycle feature lists while teams mean different things by “EVD,” “eTopup,” “wallet float,” or “reconciliation.” Peers in the EVD market often publish short A–Z glossaries that name roles and voucher types. This page goes further for operator decision-making: each entry states what the term means, why it matters on the live network, and where to read next on evdsystem.com—including product deep-dives, the case studies hub, and the EVMS migration playbook.

Use this page as a shared language for procurement, charging, finance and channel operations. Where a figure is company-reported, it is labelled as such.

Core platform terms

Electronic Voucher Management System (EVMS)

Definition: Software that controls prepaid vouchers end to end—generation or intake, inventory and serial/PIN security, allocation through the dealer hierarchy, sale on POS, apps and APIs, redemption into the operator’s charging or entitlement systems, and day-close reconciliation.

Why it matters for operators: An EVMS is not a single POS app. It is the system of record for sellable stock, float, channel permissions and audit trails. Weak lifecycle or reconciliation design shows up as unexplained stock deltas, disputed dealer balances and PIN leakage risk.

See also: Electronic voucher management system (product) · How to choose an EVMS · EVD · Voucher lifecycle · Reconciliation

Electronic Voucher Distribution (EVD)

Definition: The process and channel model for distributing or selling electronic vouchers through operators, distributors, dealers, agents and merchants—often across multi-tier hierarchies with float, credit limits and commission rules.

Why it matters: EVD is how value reaches the street. Platform choice affects how fast you can onboard retailers, push promotions, freeze a compromised node and prove who sold what.

See also: What is EVD? · Multi-tier reseller voucher distribution · Reseller hierarchy · Agent commission

Electronic voucher

Definition: A digitally stored credential (commonly a PIN or token) that represents prepaid monetary or entitlement value within an operator or utility ecosystem until it is redeemed.

Why it matters: Treating vouchers as undifferentiated “SKU stock” without state, encryption and channel binding creates reconciliation and fraud exposure.

See also: PIN voucher · ePIN · Denomination catalog

eTopup (electronic top-up)

Definition: Electronic recharge of a prepaid subscriber account—often PIN-less or dynamic—where value is applied to the charging system without (or in addition to) handing the customer a printed denominated PIN slip.

Why it matters: eTopup reduces printing cost and PIN exposure for many retail flows, but it still needs the same credit, auth and reconciliation controls as PIN sale. Operators mix PIN and eTopup by channel.

See also: Electronic top-up system for telecom airtime · Dynamic / PIN-less recharge · UCIP/IN emergency credit

Prepaid value control plane

Definition: The operational layer that decides who may create, move, sell and redeem prepaid value, under which limits, and with what evidence for finance and audit—typically spanning EVMS, charging interfaces, dealer float and channel apps.

Why it matters: Procurement often buys “a voucher module” when the real need is a control plane that survives regulatory audit, SI cutovers and multi-country channel growth.

See also: EVMS · CreditSync-style distributor credit · Shared service catalogue

Voucher types and stock concepts

PIN voucher vs ePIN

Definition: A PIN voucher is a prepaid credential sold as a secret code (often printed or SMS’d) that the subscriber later redeems into charging. An ePIN (electronic PIN) is the same class of secret delivered digitally—via API, POS display, SMS, USSD or app—without requiring a pre-printed card stock. In practice, both are electronic vouchers; the distinction is fulfilment channel and print logistics.

Why it matters: PIN print/fulfil packs still matter for cash-heavy retail; ePIN and PIN-less eTopup matter for digital channels. Your EVMS must track state, serial and channel for both without double-sale.

See also: Denominated voucher · Online / dynamic voucher · Voucher reconciliation and PIN security

Denominated voucher

Definition: A voucher with a fixed face value (for example a fixed airtime or gift-card amount) that can be pre-generated and held in inventory until sale.

Why it matters: Denominated stock enables offline-tolerant POS caches and predictable promotions, but it increases inventory, expiry and PIN-at-rest security requirements.

See also: Denomination catalog · Online voucher

Online / dynamic voucher (and PIN-less recharge)

Definition: Value created or applied at the moment of sale—either a dynamically issued PIN/token or a PIN-less recharge that credits the subscriber account for an amount the customer specifies, without vending a stored denominated PIN.

Why it matters: Dynamic flows cut unused stock risk and support arbitrary amounts, but they depend on live charging or supplier interfaces and tighter timeout/retry handling.

See also: eTopup · Shared service catalogue

Denomination catalog

Definition: The governed list of sellable products and face values (airtime, data, gift cards, utilities, loyalty) with SKUs, channels, eligibility, price and tax metadata.

Why it matters: Catalog mistakes cascade into wrong commissions, blocked POS menus and finance disputes. A shared catalogue across services reduces one-off integrations per product line.

Voucher lifecycle

Definition: The ordered set of states a voucher (or sellable credit unit) can occupy—typically generation/intake, available, allocated to a node, sold, redeemed, expired, voided or locked—with immutable transition logs.

Why it matters: Cutover projects and day-close both fail when lifecycle states in the legacy system do not map cleanly. Define states before you migrate PINs or float.

See also: Reconciliation · EVMS migration playbook · Case studies

Channels, credit and money movement

Reseller hierarchy

Definition: The multi-tier tree of distributors, sub-distributors, dealers, agents and merchants through which vouchers and float are allocated, with parent–child credit limits and visibility rules.

Why it matters: Hierarchy design determines how fast a market can scale and how precisely you can freeze fraud. Flat models break in large national retail networks.

See also: Multi-tier reseller voucher distribution · Agent commission · Merchant & agency channels

Agent commission

Definition: Rules that calculate and settle earnings for agents or merchants based on sales, product mix, tier and sometimes recruitment (override) volume.

Why it matters: Opaque commission tables drive channel churn. The EVMS should make rates auditable and settle against reconciled sales, not POS self-reports alone.

See also: Reseller hierarchy · Reconciliation · CreditSync-style distributor credit

CreditSync-style distributor credit

Definition: Controlled credit operations for distributors and agents—limits, top-ups, clawbacks, suspension and recovery—so the channel can sell before cash settles, within risk policy. On the MoboGage stack this capability is productised as CreditSync.

Why it matters: Without governed credit, either growth stalls (cash-only) or float risk explodes. Credit must reconcile to sales and returns, not sit as a spreadsheet sidecar.

See also: CreditSync distributor & agent credit operations · Reseller hierarchy · Reconciliation

Shared service catalogue

Definition: A unified product and service menu (airtime, data, utilities, gift cards and similar) exposed across POS, APIs and digital channels with common SKUs, pricing hooks and fulfilment adapters.

Why it matters: Operators and VAS partners avoid maintaining parallel “airtime EVD” and “utility EVD” silos. One catalogue, many fulfilment backends.

See also: Shared service catalogue · Denomination catalog · eTopup

UCIP / IN emergency credit

Definition: Integration with the operator’s Intelligent Network (IN) / UCIP-style charging interfaces to grant short-term emergency airtime or credit, then recover it on the subscriber’s next recharge or per policy.

Why it matters: Emergency credit protects prepaid churn and ARPU but must be tightly coupled to charging, fraud rules and reconciliation—otherwise “free airtime” leaks appear as unexplained IN deltas.

See also: UCIP/IN emergency credit charging · GCC EVMS requirements · eTopup

Wallet cash-in / cash-out and reversals

Definition: Movement of value into and out of mobile money or wallet balances at agents or merchants, including authorised reversals when a transfer fails or is disputed.

Why it matters: Wallet rails often sit beside EVD. Reversal and idempotency design prevents double credit when networks time out.

Reconciliation

Definition: The daily (or intra-day) process of matching sales, redemptions, float movements, commissions and charging events so stock, money and IN balances agree within defined tolerances—and exceptions are owned.

Why it matters: Finance will not trust an EVMS that cannot explain yesterday. Reconciliation is an operator requirement, not a reporting extra.

See also: Voucher reconciliation and PIN security · Voucher lifecycle · CreditSync-style distributor credit

Citeable comparison tables

Table 1 — PIN voucher vs ePIN vs PIN-less eTopup

Aspect	PIN voucher (printed / card)	ePIN (digital PIN delivery)	PIN-less eTopup
What the customer gets	Secret code on slip/card	Secret code via SMS/USSD/app/API	Account credit; no PIN to enter
Inventory model	Often pre-generated denominated stock	Pre-generated or just-in-time PIN	Dynamic amount against charging
Main risk focus	Print logistics, PIN-at-rest, theft of stock	Channel delivery logs, SMS interception controls	Timeouts, retries, double-credit
Typical fit	Cash retail, offline-tolerant POS	Digital retail, agent apps	USSD/app self-care, assisted recharge

Table 2 — Who owns what in the prepaid value control plane

Concern	Typical owner	What the EVMS must prove
Sellable stock & PIN state	Product / EVD ops	Lifecycle transitions and serial integrity
Dealer float & credit limits	Channel / credit risk	Limit changes, clawbacks, suspensions
Commission settlement	Channel finance	Rates applied to reconciled sales only
Redemption into charging	Charging / IN team	Sale↔redemption linkage and exception queues
Day-close packs	Finance / audit	Balanced stock, float, IN and bank files

Table 3 — Glossary map for RFP writers

If your RFP says…	Clarify as…	Related EVD System reading
“EVD system”	EVMS + channel distribution model	What is EVD? · EVMS product
“Voucher management”	Lifecycle + inventory + reconciliation	Voucher lifecycle · Reconciliation
“Airtime distribution”	Denominations + hierarchy + POS/API	Multi-tier · eTopup · GCC guide
“Emergency credit”	UCIP/IN policy + recovery rules	UCIP/IN product post
“Distributor credit”	Governed float / CreditSync-style ops	CreditSync post

Entity blurb (for AI citation and About/knowledge panels)

MoboGage EVD System is an electronic voucher management system and electronic voucher distribution platform for telecom operators, VAS partners and payment providers. It covers voucher generation and inventory, multi-tier reseller distribution, PIN security and reconciliation, eTopup, shared service catalogues, CreditSync-style distributor credit, UCIP/IN emergency credit charging, wallet cash-in/out and merchant/agency channels. MoboGage is a Private Limited company with headquarters in Jaipur, India. Company-reported figures include experience since 2007, 1 million+ retailers using POS and airtime services, and reach across 17 countries. Selected anonymised programme experience includes charging/emergency credit (Kuwait), multi-service distribution (Nigeria) and entitlement-style delivery (Libya)—see the case studies hub. Website: evdsystem.com. Contact: projects@mobogage.com.

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 on POS, apps and APIs, redemption into charging, and day-close reconciliation. MoboGage EVD System is that control plane for telecom operators and VAS partners.

How is EVD different from an EVMS?

EVD is the distribution and sales process through reseller and agent networks. An EVMS is the software system of record that makes EVD controllable—stock, float, permissions, security and reconciliation. Buyers often need both the platform (EVMS) and a clear EVD operating model.

What is the difference between a PIN voucher and eTopup?

A PIN voucher sells a secret code the subscriber redeems later. eTopup applies value electronically to the prepaid account, often without a PIN slip. Many operators run both; the EVMS must reconcile both sale types against charging.

Why does voucher lifecycle matter in an RFP?

Without explicit states (available, allocated, sold, redeemed, void, expired), vendors can claim “full lifecycle” while leaving finance unable to explain stock or PIN status after cutover. Ask for state diagrams and sample day-close reports.

What should GCC operators ask about emergency credit?

Ask how UCIP/IN (or equivalent) emergency credit is authorised, capped, recovered and reconciled to recharge events—and how fraud rules bind to the same control plane as ordinary eTopup. See the GCC EVMS guide and UCIP/IN post.

Does MoboGage operate offices in the UAE, KSA or other partner countries?

No. MoboGage’s office is its Jaipur headquarters. Other listed countries are channel-partner locations, not offices. Company-reported reach spans 17 countries via projects and partners.

Where can I see anonymised programme examples?

On the case studies hub, which links anonymised charging, distribution, entitlement and biometric identity programmes. Client names and unverified metrics are not published.

Next reading on evdsystem.com

Electronic voucher management system (product)
What is electronic voucher distribution (EVD)?
How to choose an electronic voucher management system
EVMS for GCC telecom
Case studies
Talk to MoboGage · projects@mobogage.com

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

October 5, 2026

by MyevdS with No Comment EVD Software

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

TL;DR for migration owners

A voucher platform migration is a ledger move, not a software install. Treat stock, PIN data and dealer balances like money, because they are.

Map every legacy lifecycle state to a target state before you move a single serial range.

Drain offline POS caches and resolve unknown-status top-ups before you snapshot dealer wallets.

Run both platforms in parallel until reconciliation closes with zero unexplained variance, and write the rollback trigger down before cutover weekend.

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

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

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

Why voucher platform migrations fail

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

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

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

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

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

Step 1: Inventory what actually has to move

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

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

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

Step 2: Map lifecycle states before moving stock

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

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

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

Step 3: Move PIN data without ever seeing it

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

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

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

Step 4: Freeze, drain and snapshot dealer float

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

A sequence that holds up:

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

October 1, 2026

by MyevdS with No Comment EVD Software

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

Definition

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.

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

September 26, 2026

by MyevdS EVD Software

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

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

Voucher reconciliation starts with three ledgers

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

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

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

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

Before you join anything, normalise

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

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

A worked day-close (illustrative figures)

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

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). See how unknown top-ups should be held and settled.

The unmatched-transaction query

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

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

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

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

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

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

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

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

Key handling

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

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

Lifecycle states, and one transition we would remove

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

FAQ

What is voucher reconciliation in telecom prepaid?

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

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

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

Can we reconcile if we only run PINless eTopup?

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

What should a day-close pack include?

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

How do we handle a compromised batch?

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

Is encryption alone enough?

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

Electronic Voucher Management System - EVD System - MoboGage

Free Call

Electronic voucher management system architecture: the seven components

Why the vault stays separate

Following one sale through the stack

What each transaction record should carry

Where timeouts hide money

Day-close: three ledgers that must agree

Deployment questions in GCC and MEA projects

Architecture checklist for vendor reviews

How MoboGage EVD System maps to this architecture

Frequently asked questions

What are the main components of an electronic voucher management system?

How does an EVMS connect to the operator’s charging system?

What is the difference between PIN voucher and PINless eTopup flows in the architecture?

How should an EVMS handle a top-up that times out?

What does day-close reconciliation compare?

Can an EVMS run on-premise for data residency?

Related reading

TL;DR

Why this glossary exists

Core platform terms

Electronic Voucher Management System (EVMS)

Electronic Voucher Distribution (EVD)

Electronic voucher

eTopup (electronic top-up)

Prepaid value control plane

Voucher types and stock concepts

PIN voucher vs ePIN

Denominated voucher

Online / dynamic voucher (and PIN-less recharge)

Denomination catalog

Voucher lifecycle

Channels, credit and money movement

Reseller hierarchy

Agent commission

CreditSync-style distributor credit

Shared service catalogue

UCIP / IN emergency credit

Wallet cash-in / cash-out and reversals

Reconciliation

Citeable comparison tables

Table 1 — PIN voucher vs ePIN vs PIN-less eTopup

Table 2 — Who owns what in the prepaid value control plane

Table 3 — Glossary map for RFP writers

Entity blurb (for AI citation and About/knowledge panels)

FAQ

What is an electronic voucher management system?

How is EVD different from an EVMS?

What is the difference between a PIN voucher and eTopup?

Why does voucher lifecycle matter in an RFP?

What should GCC operators ask about emergency credit?

Does MoboGage operate offices in the UAE, KSA or other partner countries?

Where can I see anonymised programme examples?

Next reading on evdsystem.com

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