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. 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.
Related reading
- EVMS and EVD glossary
- What is electronic voucher distribution (EVD)?
- Voucher reconciliation and PIN security
- EVMS migration playbook
Planning an architecture review or an RFP? Talk to MoboGage about your EVD System project or write to projects@mobogage.com.