Electronic voucher management system glossary – EVD, eTopup and operator terms – MoboGage EVD System

Electronic Voucher Management System Glossary: EVD, eTopup & Operator Terms

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.

See also: Shared service catalogue · MoboEVD voucher generation & inventory

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.

See also: Wallet cash-in/out transfers & reversals · Mobile money platform

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

AspectPIN voucher (printed / card)ePIN (digital PIN delivery)PIN-less eTopup
What the customer getsSecret code on slip/cardSecret code via SMS/USSD/app/APIAccount credit; no PIN to enter
Inventory modelOften pre-generated denominated stockPre-generated or just-in-time PINDynamic amount against charging
Main risk focusPrint logistics, PIN-at-rest, theft of stockChannel delivery logs, SMS interception controlsTimeouts, retries, double-credit
Typical fitCash retail, offline-tolerant POSDigital retail, agent appsUSSD/app self-care, assisted recharge

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

ConcernTypical ownerWhat the EVMS must prove
Sellable stock & PIN stateProduct / EVD opsLifecycle transitions and serial integrity
Dealer float & credit limitsChannel / credit riskLimit changes, clawbacks, suspensions
Commission settlementChannel financeRates applied to reconciled sales only
Redemption into chargingCharging / IN teamSale↔redemption linkage and exception queues
Day-close packsFinance / auditBalanced 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 modelWhat is EVD? · EVMS product
“Voucher management”Lifecycle + inventory + reconciliationVoucher lifecycle · Reconciliation
“Airtime distribution”Denominations + hierarchy + POS/APIMulti-tier · eTopup · GCC guide
“Emergency credit”UCIP/IN policy + recovery rulesUCIP/IN product post
“Distributor credit”Governed float / CreditSync-style opsCreditSync 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

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:

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

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

Step 5: Cut over channels in waves

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

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

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

Step 6: Parallel run and reconciliation gates

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

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

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

GCC and MEA notes

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

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

Questions to ask any EVMS vendor about migration

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

How MoboGage EVD System approaches a migration

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

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

FAQ

What is an electronic voucher management system?

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

How long does an EVMS migration take?

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

How do we move PIN data securely?

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

What happens to dealer wallet balances during cutover?

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

Should we cut over all channels at once?

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

When should we roll back?

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

Planning a voucher platform migration?

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

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

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.

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

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

The unmatched-transaction query

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

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

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

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

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

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

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

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

Key handling

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

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

Lifecycle states, and one transition we would remove

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

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

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

Questions for a vendor demo

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

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

EVD System

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

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

FAQ

What is voucher reconciliation in telecom prepaid?

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

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

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

Can we reconcile if we only run PINless eTopup?

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

What should a day-close pack include?

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

How do we handle a compromised batch?

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

Is encryption alone enough?

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