MyevdS, Author at 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

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.

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. 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

MoboGage EVD System case study card — subscriber identity engagement

Case Study: Biometric Subscriber Enrolment and Verification

Subscriber identity engagement (South Asia market context): a company-reported MoboGage engagement on biometric enrolment and one-to-one / one-to-many verification, written up for telecom operators tightening subscriber-service identity operations.

This is a company-reported, anonymised summary. We don’t name the client or operator, and we don’t publish performance metrics. Project scope, references and supporting records can be shared through an agreed due-diligence process.

Why biometric enrolment breaks in the field

Biometric enrolment is straightforward in a demo room and much harder at a busy enrolment point. Capture quality has to be controlled, every exception needs someone to review it, and access to biometric material has to follow policy, not convenience. When failures go unowned, the operator ends up with compliance exposure and a queue of customers waiting. The brief was to support enrolment and both verification modes under access rules specific to that deployment.

Subscriber identity in Afghanistan: the context

The market was Afghanistan (company-reported selected experience), and the workflow class was subscriber identity. It maps onto the Established telecom capability described in our product post on biometric subscriber identity enrolment. It’s on this site because it’s relevant to telecom operators.

Company backdrop: experience since 2007 (company-reported); MoboGage Private Limited incorporated February 2017; the only office is the Jaipur HQ; company-reported project or business presence across 17 countries through partners.

What we built

The scope covered enrolment workflows with controls on field capture, one-to-one verification, one-to-many verification under authorized policy, and exception review so that a failed capture went to a person instead of failing silently. We aren’t disclosing hardware vendors, algorithms, thresholds or volumes.

Who may enrol, verify or export

Access policies decide who may enrol, verify or export. Encryption, retention and privileged access follow what was agreed in the engagement, and quality failures go to supervisors. Those controls match MoboGage’s trust guidance. They sit alongside the prepaid distribution controls on the EVMS product page and in the MoboEVD inventory post, rather than replacing them.

Planning a similar pilot

Pick one enrolment centre or one field team. Agree how you’ll measure capture quality and exception age. Check legal basis and purpose limitation with your own counsel first. Keep an identity pilot separate from any voucher pilot: the delivery rhythm is the same (Discover → Design → Pilot → Roll out → Operate and expand), but the risk owners are different people. If you are writing the RFP, the product post lists the standards questions worth asking (template formats such as ISO/IEC 19794, capture quality scoring, liveness testing to ISO/IEC 30107-3).

Further reading: how to choose an EVMS, about MoboGage, EVD System homepage.

Talk to MoboGage

Enquiry page · projects@mobogage.com · +91-9928 366 889 · Case Studies.

Frequently asked questions

What was the focus of this subscriber identity engagement?

Company-reported experience covered biometric enrolment and one-to-one / one-to-many verification for subscriber identity workflows.

Does this publish accuracy or throughput figures?

No. This summary intentionally omits performance metrics. Measurement basis belongs in confidential due-diligence materials.

How does this map to Established products?

It maps to Established telecom subscriber identity workflows: biometric enrolment and verification with controlled field capture, reviewed exceptions and deployment-specific access policies.

Is civic GIS or unrelated ID programmes included?

No. Jaipur civic GIS proof-of-concept experience is out of scope for this EVD System case-study set.

What should operators prepare for a similar pilot?

Policy owners, field device constraints, exception-review staffing, access and retention rules, and a bounded enrolment site or team.

How do we enquire?

projects@mobogage.com, +91-9928 366 889, or the enquiry page; product deep-dive: biometric subscriber identity enrolment.

Case Study: Assistance Delivery — Entitlement Validation and Redemption Tracking

Assistance delivery engagement (North Africa market context) — a company-reported MoboGage experience focused on entitlement validation, redemption tracking and programme reporting, summarised for organisations that need accountable value delivery.

This summary is a company-reported, anonymised engagement narrative. It does not name the client or operator, and it does not include performance metrics. Project scope, references and supporting records can be shared through an agreed due-diligence process.

Challenge

Assistance and benefit programmes fail operationally when eligibility is unclear, redemption is untracked, or reporting cannot explain what was delivered to whom under which rule. The challenge was to apply distribution-grade controls—validation, redemption evidence and reporting—to programme value rather than to commercial airtime alone.

Context

Market pointer: Libya (company-reported selected experience). Workflow class: assistance delivery. In the portfolio, entitlements and benefit delivery is noted as a proposed public-sector extension that applies distribution experience to programme rules, beneficiary validation, restricted-purpose value, redemption and reconciliation. This engagement summary informs that direction; it does not claim a globally launched public-benefits product suite.

EVD buyers will recognise familiar mechanics: controlled value, channel redemption and reconciliation thinking as on the electronic voucher management system homepage and in voucher inventory activation.

What we built

Engagement themes included:

Entitlement validation against programme rules
Redemption tracking through agreed channels
Programme reporting for accountable administration

Rule detail, channel mix and organisation names remain confidential.

Workflow and controls

Validation before redemption prevents leakage. Redemption events need unique references and terminal states. Reporting must preserve the link between rule version, entitlement and redemption evidence. Trust principles—explicit states, controlled reversals where applicable, privileged access—still apply. Where wallet or voucher instruments carry restricted-purpose value, pair this narrative with wallet controls and reconciliation practices.

What this means for similar buyers

Programme authorities and partners should start with one benefit or assistance flow, agree completion and reconciliation measures, and validate policy access to authoritative systems. Public-sector extensions require discovery and approved access—stated clearly in the company profile. Delivery model: Discover → Design → Pilot → Roll out → Operate and expand.

Related product reading: EVMS for telecom, shared service catalogue, about MoboGage.

Talk to MoboGage

Enquiry page · projects@mobogage.com · +91-9928 366 889 · Case Studies.

Frequently asked questions

What was the focus of this assistance delivery engagement?

Company-reported experience covered entitlement validation, redemption tracking and programme reporting for assistance delivery.

Is entitlements and benefit delivery an Established product on the EVD site?

In the company profile, entitlements and benefit delivery is described as a proposed public-sector extension that applies distribution experience to programme rules. This case study reflects selected experience informing that direction; buyers should treat full programme platforms as discovery-led unless scoped as Established modules already in use.

Why include it on evdsystem.com?

Because redemption tracking and validation patterns reuse distribution control ideas familiar to EVD buyers—value movement, eligibility and reconciliation—while remaining honest about readiness.

Are beneficiary volumes published?

No. This summary avoids invented or disclosed programme metrics.

What should programme authorities prepare?

Clear entitlement rules, redemption channels, reporting owners and identity/eligibility sources—plus a bounded pilot population.

How do we enquire?

projects@mobogage.com, +91-9928 366 889, or the voucher management system enquiry page.

Case Study: Service Distribution — Voucher, Wallet and Utility Integration

Service distribution engagement (West Africa market context): a company-reported MoboGage engagement covering voucher, wallet, utility and external-provider integration, written up for aggregators and operators who are adding more services to their retail network.

The problem with adding one more utility or service

Many distribution networks follow a similar path. Airtime comes first. Then someone adds utilities, then wallet moves, then a third-party digital product, and each one arrives with its own portal, its own float and its own way of failing. After a while the counter staff are juggling apps and finance is matching four settlement files that don’t agree.

The brief here was to bring voucher, wallet, utility and external-provider workflows together so the channel could sell and support one offer, with every transaction traceable.

Service distribution in Nigeria: the context

The market was Nigeria (company-reported selected experience), and the workflow class was service distribution. The Established capabilities in play were MoboEVD distribution, shared service catalogues, wallets and CreditSync-related channel finance. For context, MoboGage reports (company-reported) business or project presence across 17 countries through partners; its only office is the Jaipur HQ.

If you want the product detail behind this, read the shared service catalogue post, voucher generation and inventory activation, the mobile money platform page, and the wallet cash-in/out deep-dive.

What we built

The work covered voucher distribution controls for prepaid sale, wallet transaction paths where they were in scope, utility integration patterns, and connections to external providers with explicit tracking on each one. We aren’t publishing implementation detail, provider names or volumes.

The controls that made it hold together

When several providers sit behind one counter, the routine controls decide whether it works: credentials scoped per provider, idempotent requests so a retry doesn’t charge twice, final states that stay final, and an owner for every exception. Utility lines add their own steps, usually a bill enquiry that returns the amount due before the payment call, and for prepaid electricity a token that must reach the customer exactly as issued. Commission and hierarchy rules also need to stay visible across product families, the same thinking as in multi-tier reseller design. And the voucher reconciliation habits apply just as much when some lines are PINless or bill-pay. A utility payment that timed out needs the same day-close treatment as a voucher that didn’t redeem.

If you’re planning something similar

A first phase works best with one provider or one distributor network. Before you add anything to the catalogue, agree how you’ll measure availability and unmatched transactions, because that argument is much harder to have after go-live. Be honest about readiness labels as well: the Established distribution and catalogue capabilities are available to scope, while Proposed items like settlement hubs are roadmap only.

Our delivery path runs Discover → Design → Pilot → Roll out → Operate and expand. For the wider platform, see the homepage on our electronic voucher management system.

Talk to MoboGage

Contact / voucher management enquiry · projects@mobogage.com · +91-9928 366 889 · Hub: Case Studies.

Frequently asked questions

What was the focus of this service distribution engagement?

Company-reported experience covered voucher, wallet, utility and external-provider integration workflows for service distribution.

Why anonymise the client?

Because commercial confidentiality is the default. Market context (Nigeria) situates the workflow class without naming institutions.

Which product areas does this map to?

Electronic voucher distribution, shared service catalogue patterns, wallet connectivity and scoped provider integrations.

What buyer lesson stands out?

Multi-provider retail needs one channel experience and explicit transaction states per provider, not a separate informal process for each new service.

Are performance results published here?

No. Numbers and outcomes are not invented or disclosed in this summary. Evidence is available through due diligence.

How do we start a similar pilot?

Bound one provider or service family on one distributor network; agree unmatched-value and availability measures. Contact projects@mobogage.com.

MoboGage EVD System case study card — telecom charging engagement

Case Study: Telecom Charging — Emergency Credit and Voucher Redemption

Telecom charging engagement (GCC market context): a company-reported MoboGage engagement on emergency credit and voucher redemption through UCIP / IN environments, written up for operators weighing charging-integrated prepaid control.

When the shop and the network disagree

Prepaid retail and network charging have to tell the same story. If emergency credit grants or voucher redemptions run without a disciplined interface into the operator’s UCIP or intelligent-network environment, care inherits the disputes and finance inherits the unmatched events. The job here was to wire eligibility, redemption and credit rules into live charging behaviour, and to resist the temptation to build a parallel balance.

Emergency credit and UCIP redemption in Kuwait: the context

The market was Kuwait (company-reported selected experience); the workflow class, telecom charging. MoboGage’s Established telecom portfolio covers electronic voucher distribution and charging/emergency credit integration. Country pointers in the company profile mean business and project presence through partners; the only office is the Jaipur HQ. Experience since 2007 (IWT Group heritage, company-reported); MoboGage Private Limited incorporated February 2017.

If you’re comparing platforms, the EVMS GCC page and the product deep-dive on UCIP emergency credit charging integration are worth a read.

What we built

The work connected emergency credit eligibility and grant behaviour to the charging interfaces, and built voucher redemption paths that consume UCIP / IN responses. Every transaction got an explicit state, so retail or care staff could explain an outcome to a customer. Duplicates, retries and exception ownership all had controls. Exact architecture, vendors and cutover plans stay in the confidential scope we share under due diligence.

Success, failure, and “we don’t know yet”

On Ericsson-style charging, a UCIP request carries an originTransactionID and originTimeStamp supplied by the calling system, and the response carries a responseCode. Controls for this kind of work build on those fields: unique references link each commercial event to its charging request, and success, failure and indeterminate outcomes each have a defined handling path, and the indeterminate one gets the most attention. Changing a credit rule is a privileged action. That lines up with MoboGage’s trust principles: transaction integrity, documented interfaces, and a person reviewing any correction that matters. Upstream lifecycle discipline (generation, activation, PIN protection) still counts; see voucher reconciliation and PIN security and voucher generation and inventory activation.

If you run UCIP or IN charging

Emergency credit and redemption make a good bounded pilot: one interface, one product path, acceptance you can measure under realistic traffic. Handsets, networks and charging releases differ between markets, so confirm interface versions early, and line the charging cutover up with channel readiness across POS, apps, USSD/SMS and API, as described on the EVMS product page and the site homepage.

Delivery model: Discover → Design → Pilot → Roll out → Operate and expand.

Talk to MoboGage

Enquire through the voucher management system contact page, projects@mobogage.com, or +91-9928 366 889. More engagements: Case Studies hub.

Frequently asked questions

What was the focus of this telecom charging engagement?

Company-reported experience centred on emergency credit and voucher redemption through UCIP / IN environments, connecting eligibility, redemption and credit behaviour to operator charging.

Was a client or operator named?

No. Case studies on this site are anonymised. Market context (Kuwait) indicates the operating environment type, not a named institution.

What systems were involved at a high level?

Operator charging environments accessed through UCIP / intelligent-network integration patterns, with voucher redemption and emergency credit rules in scope.

What should similar buyers prepare?

Interface ownership, eligibility and credit rule owners, exception handling for timeouts and duplicates, and acceptance criteria for a bounded pilot path.

How does this relate to MoboGage products?

It maps to Established charging and emergency credit integration and to electronic voucher distribution / redemption controls.

How can we review evidence?

Through agreed due diligence. Contact projects@mobogage.com or the voucher management system enquiry page.

Biometric Subscriber Identity Enrolment and Verification

Biometric subscriber identity workflows support biometric enrolment and verification with controlled field capture, reviewed exceptions and deployment-specific access policies, so telecom operators can run subscriber-service identity checks as accountable operations instead of ad-hoc device use.

MoboGage lists subscriber identity workflows as an Established telecom capability, tied in the company profile to controlled distribution, charging integrity and traceable subscriber-service operations. The post sits on evdsystem.com because it belongs in operator and MVNO programmes, not civic ID schemes.

Company-reported selected experience includes biometric enrolment and one-to-one / one-to-many verification. Scope, references and supporting records are shared through due diligence; this page gives no throughput or accuracy figures. Heritage since 2007 (company-reported); MoboGage Private Limited incorporated February 2017; the only office is the Jaipur HQ.

Why biometric subscriber identity workflows land on the telecom ops desk

SIM registration rules differ by market. Some regulators require a fingerprint match against a national identity registry before a SIM is activated; Saudi Arabia and Pakistan are well-known examples. Others accept document checks with a photo. The operating problem is similar everywhere: capture people correctly in the field, verify them when policy requires, route every failure to a named person, and keep access to biometric material narrow.

What gets captured, and to which standard

Fingerprint data is usually stored and exchanged in ISO/IEC 19794-2 minutiae templates or ISO/IEC 19794-4 images, and many national registries specify one of these (or the newer ISO/IEC 39794 formats) in their interface. Face images follow ISO/IEC 19794-5 or 39794-5 for pose, lighting and resolution. Fixing the format in the interface document early avoids the late discovery that the registry rejects what the field devices produce.

Each capture gets a quality score before it is accepted. For fingerprints the common measure is NIST’s NFIQ 2, which scores an image from 0 to 100; the acceptance threshold is set per deployment. A capture below threshold goes back for retry, and after a set number of retries it goes to a supervisor queue with the reason recorded. Where spoofing is a concern, presentation attack detection (liveness) is assessed against ISO/IEC 30107-3. Which sensors and SDKs are used is decided per engagement.

One-to-one and one-to-many are different permissions

One-to-one verification asks whether the person at the counter matches one enrolled record or the registry entry for the ID number presented. One-to-many searches an authorized gallery for duplicates and is far more sensitive, so deployment policy restricts who may run it and for what purpose. In our design they are separate roles with separate audit events. The thresholds behind either are deployment-specific, and anyone quoting match rates should say how they were measured; ISO/IEC 19795 describes the test methods for that.

Field capture is an operations problem

Capture quality falls apart in a busy shop late in the afternoon, with a queue, a smudged sensor and a staff member in their first week. Lighting, sensor cleaning, coaching and queue layout change the results. The software’s part is to refuse a poor capture, send it back for retry or up to a supervisor, and design offline or patchy-connectivity cases deliberately where the deployment needs them. Quality overrides should be rare, need a reason code, and appear in a report the compliance team reviews.

Turnover in retail staff is constant, so training has to be repeatable with new hires every month. Where dealers enrol subscribers, hierarchy and permissions mirror the channel controls in multi-tier distribution: who may enrol, under which parent, on which registered device.

Exceptions and who reviews them

Demographic mismatches, low-quality templates, device faults, registry timeouts and contested identity claims all need a human review step with the decision and reviewer recorded. Incomplete enrolments go to the exception queue rather than disappearing. Supervisors need both the screen and the authority to settle a case on the spot. Consent and purpose limitation are set by local regulation and operator policy; MoboGage provides the software and does not replace legal counsel.

Access, retention and data minimisation

Agree in Design what gets stored, where it is hosted, how long it is kept, who may export it, and what happens when a device is lost. Store templates encrypted with keys held outside the application, and consider protected-template techniques described in ISO/IEC 24745 where the registry allows. Produce audit evidence of enrolment without handing over more biometric material than the auditor needs. Hosting regions, retention and recovery targets are agreed per engagement.

Compliance and subscriber management want enrolment evidence and verification events they can audit. Fraud and security teams need every verification attributable to a user and device. The company’s trust guidance puts weight on encryption, retention, privileged access and remediation planning. Identity supports subscriber-service operations next to the recharge integrity covered in the EVMS for telecom overview.

Relation to EVD System content

None of this replaces voucher inventory, PIN security or charging integration. Identity sits beside them when subscriber-service integrity is in scope, ideally with separate programme owners. If you are evaluating prepaid platforms, start with the electronic voucher management system homepage, what is EVD, and how to choose an EVMS. GCC programmes may combine recharge control with local identity rules; see EVMS GCC. Company background: about MoboGage.

Sequence identity and voucher cutovers on different dates unless policy requires them together. The EVMS migration guidance applies to prepaid cutovers; identity needs its own acceptance tests. In the GCC and other regulated markets, confirm registration rules and registry interfaces early, since handset and interface assumptions vary by country.

Procurement questions worth putting in the RFP

Which template and image formats does the solution produce, and which does the registry accept? What quality measure gates a capture, and who can override it? How are one-to-one and one-to-many permissioned and logged? Where does biometric material live, and how is retention enforced? Which parts are Established, and which would be Proposed customisation for your policy stack? Turn down any accuracy chart that doesn’t state its test method and dataset; figures in MoboGage materials are company-reported where they appear at all.

If your current prepaid launch doesn’t need identity, skip this module and get EVD, charging and channel controls right first.

Delivery and readiness

The first question on any identity job is what the policy permits and what the field handsets can actually do. After that we pilot at a single enrolment site. Label: Established. Proposed telecom items (authorized network fraud APIs, revenue-assurance AI) and In-development CNAP are not part of this identity product claim.

Bring the policy owner, someone who knows how your field teams actually work, and the verification scenarios you’re obliged to support. Enquire through the voucher management system contact page, projects@mobogage.com, or +91-9928 366 889. Founder & CEO: Sohan Lal Soni, Jaipur, India.

Frequently asked questions

What are biometric subscriber identity workflows?

They support biometric enrolment and verification for telecom subscriber identity use cases, with controlled field capture, reviewed exceptions and deployment-specific access policies, an Established telecom capability in the MoboGage profile.

Is this a general e-KYC product for every industry?

No. On this EVD System site the focus is telecom subscriber-service operations: enrolment and verification under operator or programme policies. Broader public-sector identity programmes would require separate discovery.

What does controlled field capture mean?

Field devices and apps collect biometric and demographic data under access policies, quality checks and exception routes, so supervisors can review failures and incomplete enrolments rather than leaving them invisible.

What verification modes are discussed in company experience?

Selected company-reported experience references biometric enrolment and one-to-one / one-to-many verification. Exact modalities and thresholds are deployment-specific.

How does identity relate to EVD and charging?

Identity workflows protect subscriber-service integrity. They sit beside recharge and charging controls rather than replacing voucher inventory. Access policies determine which staff or systems may verify whom.

How should operators pilot biometric identity?

Bound one enrolment centre or field team, agree quality and exception-review measures, validate device and policy fit, then expand. Contact projects@mobogage.com.

merchant-agency-onboarding-commissions-qr

Merchant and Agency Channel Onboarding, Commissions and QR

Merchant and agency channels connect merchant onboarding, agent hierarchies, commissions, QR acceptance and cash workflows through agreed financial integrations, so banks, wallet providers and distribution groups can grow acceptance without losing track of who may sell, collect or settle.

MoboGage labels this an Established foundation with extensions in its banking portfolio. It is the channel layer that usually sits next to mobile money, CreditSync and EVD retail sale, and the company profile frames the buyer value as service access, controlled credit operations, and clearer visibility of transactions and balances.

Company context, as reported by MoboGage: experience since 2007 (IWT Group heritage), more than one million retailers using its POS and airtime services, and business or project reach across 17 countries. MoboGage Private Limited was incorporated in February 2017; its only office is the Jaipur HQ, and other countries are served through partners.

Merchant and agency channel management is more than a sign-up form

A registration form gets you a list of names. Running the channel means onboarding merchants and agents under the institution’s own compliance rules, placing each one in the hierarchy (master agent, sub-agent or merchant outlet), granting permissions per product, channel and cash activity, attaching a commission scheme, enabling QR where the payment integration allows it, and reconciling cash back to wallet or bank positions. New payment schemes or device types beyond that foundation are scoped by agreement.

Onboarding states and who sees them

Onboarding captures the identity and commercial fields the institution requires, routes the application to an approver, places the party in the hierarchy and activates only the products it has authorised. The record keeps the approver’s ID and timestamp. Field supervisors see each application as submitted, in review, approved, rejected or suspended, so a sales rep can’t tell a shop it is live while compliance is still checking documents. Product activation waits until those checks are done; the KYC rules themselves belong to the regulated client.

Device and channel binding matter as much as the approval. An agent approved to sell through the app should not acquire cash-out rights that nobody granted, and QR acceptance should switch on only after the acquiring or wallet scheme confirms the merchant. Edges like these prevent the “the system let me” argument later.

Hierarchy changes are money events

The tree defines reporting lines, float relationships and how commission cascades. Moving an agent to a new parent looks like an admin edit, but it rewires money and support paths. We treat it as a dated event: open commissions stay with the old parent up to the effective date, new transactions accrue to the new one, and the move itself is approved and logged. Suspension stops new activity immediately while keeping history intact for settlement, and exit terms (data rights, documentation, training) belong in the commercial schedule.

Airtime networks already think in trees, which gives distribution and VAS groups a head start when they extend into wallet cash-in/out and merchant acceptance. That only works if the discipline from multi-tier reseller voucher distribution carries over, including who may sell to whom and at what limit.

Commission you can trace to a rule version

Commission can differ by product (airtime, bill pay, QR), by channel and by level in the tree. Each commission line we post stores the transaction reference, the rule ID and the rule version that produced it, so “what rate was live on Tuesday?” has a database answer. Master and sub-agent splits are calculated once from the same transaction event. Promotions get explicit start and end dates. Recalculating history is rare, needs authorisation and is audited, because each retroactive change opens a fresh dispute.

Agents on the same street compare rates. Where policy allows, print the applied rate on the receipt or statement line, and write the commission logic in words a field team can explain at the counter.

QR acceptance: what the code actually contains

Most national QR schemes follow the EMVCo merchant-presented QR specification. The payload is a string of tag-length-value fields: tag 00 for the payload format, tag 01 for static (11) or dynamic (12) codes, tags 26 to 51 for the merchant account information the scheme assigns, 52 for the merchant category code, 53 for the ISO 4217 currency, 54 for an amount on dynamic codes, 58 and 59 and 60 for country, merchant name and city, and tag 63 for a CRC checksum. A printed sticker at a till is usually static, so the customer types the amount; a code shown on a POS screen is usually dynamic and carries the amount and a reference.

That reference is what lets a QR payment reconcile against the outlet’s ledger. QR acceptance depends on the agreed financial integration and on acquiring or wallet scheme rules, so we present it as a scoped capability per market, not a universal claim.

Cash and the till

In many markets cash and QR will run side by side for years. Cash ties back to wallet balances through cash-in, cash-out and till reconciliation at the end of each shift, and QR failures need scheme-specific messages the shopkeeper can read. A 200 response from an API is no help to a shopkeeper whose drawer is short, so receipts and training are part of the design.

Who needs what from the channel

A bank or licensed wallet provider needs accountable merchants: onboarding evidence, clear hierarchy ownership and commission transparency, which help growth and help during regulatory review. Regulated responsibilities stay with the licensed institution. Merchants and agents need to see their activation status, product rights and commission statements. Finance and operations need commission accruals, cash variances and dormant outlets reported with unique transaction references and explicit states, in line with voucher reconciliation and the reversal design in the wallet cash-in/out deep-dive.

Fit with EVD System and mobile money

Retailers already selling from an electronic voucher management system are natural candidates for agency roles once wallet products expand. Keep one merchant master record across EVD and wallets so catalogue airtime, utilities and cash-in share the same outlet identity, and no orphan accounts appear. CreditSync may fund agent float, while the channel modules decide what that agent is allowed to do.

For the bigger picture, read the mobile money platform with merchant payment overview, the telecom product page EVMS for telecom, and about MoboGage. The buyer checklist is at how to choose an EVMS.

Questions to put to any channel vendor

Large recharge and distribution suites such as Comviva PreTUPS and Seamless ERS 360 market multi-level hierarchies, segment-based commission and dealer management. Those are reasonable baselines. In a demo, ask each vendor to move an agent between parents mid-month and show where the open commission lands, to show the rule version on a commission line, and to reconcile one dynamic-QR payment against the outlet ledger. Ask us the same.

A pilot sized to the field

Delivery follows the same five stages as our other work (Discover → Design → Pilot → Roll out → Operate and expand). For channels we pilot on one city or one hierarchy branch, with one product set (cash-in plus airtime, or QR plus bill pay) and a training cohort that stays the same throughout. Measure the quality of completed onboarding rather than the application count, how clear agents find their commission statements (ask them in feedback sessions), and how old cash variances get. Label: Established foundation with extensions. Proposed banking exception hubs and settlement-exception products are not included as available features and stay out of the pilot charter unless discovery adds them.

Useful links for evaluators: telecom EVD systems for context, electronic top-up for PINless sale at the same outlets, and the CreditSync post for the float funding behind the hierarchy.

For a first call, bring your compliance owner, your hierarchy model and the product set you want live first. Contact us through the voucher management system enquiry page, projects@mobogage.com, or +91-9928 366 889. Founder & CEO: Sohan Lal Soni, Jaipur, India.

Frequently asked questions

What are merchant and agency channels in this context?

They are the operating structures that onboard merchants and agents, organise hierarchies, calculate commissions, accept QR payments and run cash workflows through agreed financial integrations, an Established foundation with extensions in MoboGage’s banking portfolio.

How does onboarding usually work?

Onboarding collects identity and commercial data required by the institution, applies approval workflows, assigns hierarchy placement and activates channel permissions (POS, app, QR, cash). Exact KYC rules belong to the regulated client.

Why do agent hierarchies matter?

Commissions, float, limits and support ownership usually follow the tree. Without a clear hierarchy, settlement and dispute routing become informal and slow.

What is QR acceptance used for?

QR acceptance lets merchants take wallet or payment-scheme payments at the point of sale under agreed financial integrations. It sits beside cash workflows rather than replacing them overnight.

How do commissions stay trustworthy?

Commission rules should be versioned, attributable to transaction types, and visible to finance. Silent rule changes create channel conflict.

How do we pilot merchant and agency channels?

Bound one city or hierarchy branch, agree onboarding completion and commission clarity measures, then expand. Contact projects@mobogage.com or the enquiry page.

wallet-cash-in-out-transfers-and-reversals

Wallet Cash-In, Cash-Out, Transfers and Reversals

Wallet cash-in, cash-out, transfers and reversals are the operating spine of MoboGage’s Established mobile money and wallet capability: moving value into and out of wallets, between parties and banks, paying bills and salaries, and correcting exceptions under controlled reversal rules, through both digital and agent channels.

This is a supporting deep-dive. The broader platform story, merchant payments included, lives on the mobile money platform with merchant payment page. Here we look at how cash-in, cash-out, transfers, bank links and reversals behave at the ledger level, once operations and finance are the ones holding the exceptions.

MoboGage Private Limited (Jaipur; heritage IWT Group since 2007; incorporated February 2017) lists mobile money and wallets as Established for banks, licensed wallet providers, fintechs and lenders. Company-reported figures (more than one million retailers using POS and airtime services; reach across 17 countries) describe the wider business, not wallet service levels. The only office is the Jaipur HQ; other countries are served through partners.

Where wallet projects actually get stuck

Merchant QR gets the attention in demos. The tickets that pile up in the first month are about other things: an agent cash-in that posted twice because the app retried after a network drop, a salary file where a handful of rows don’t match any account, a bill payment stuck between “sent to biller” and “confirmed”, a transfer to the wrong number that the customer wants back today. Each one is a ledger question first.

The ledger underneath every cash-in and cash-out

We build wallet movements as double-entry postings: every transaction debits one account and credits another for the same amount, and the sum across the system stays zero. A cash-in at an agent debits the agent’s e-float account and credits the customer wallet; the physical cash goes into the agent’s till. A cash-out does the reverse. Fees post as separate lines. Commission does too, so a commission dispute never means editing the principal movement.

Two fields do most of the protective work. A client-supplied idempotency key on every posting request means a retried cash-in returns the original result instead of posting again. And a unique, immutable transaction reference ties the posting to the receipt, the SMS and the bank file. Without both, duplicate prevention turns into a nightly manual job.

Transfers, bills and salaries

Peer, merchant and institutional transfers need payer authentication suited to the channel (PIN on USSD, device binding plus PIN or biometrics in an app), beneficiary name lookup before confirmation, fee display, and a terminal state. A transfer is either posted or not; “processing” is a temporary state with a timer and an owner, never a resting place.

Bill pay depends on an accurate biller catalogue and on the biller’s confirmation. When the biller times out, hold the customer’s funds in a suspense account rather than reversing at once, query the biller, and then either complete or release. Salary distribution depends on validating the whole file before posting anything, reporting partial success line by line, and keeping employee references stable so HR and finance compare the same columns every month.

Reversals are compensating entries, not deletions

A controlled reversal is a new transaction that mirrors the original postings, carries its own reference, points back to the original, and is approved by someone other than the requester above a configured amount (maker-checker). The original row stays exactly as it was. That gives internal audit a trail they can follow from complaint to correction, and it means reports run yesterday still reconcile today.

Customer-requested reversals of a completed transfer usually need the recipient’s funds to be available and, depending on local rules, the recipient’s consent or a regulator-defined dispute process. Agree those rules with the licensed institution before go-live; the first dispute is a poor time to invent them.

Bank connectivity and settlement files

Every bank link brings its own settlement calendar, cut-off times, account structure and return codes. Where the bank supports ISO 20022, outbound credit transfers (pacs.008), returns (pacs.004) and end-of-day statements (camt.053) give a clean basis for matching; older links use proprietary CSV or fixed-width files and need a pinned field mapping. Agree which legal entity holds which accounts, who initiates and who confirms payouts, and how a returned payment re-enters the wallet ledger. MoboGage integrates; the licensed institution owns the regulated outcome.

What each party needs to see

The bank or licensed wallet provider needs a ledger internal audit can follow, cash movements that respect its settlement calendar, and a clear statement that regulated responsibility stays with it. Agents are both float holders and cash points, so limits, commissions and till discipline matter; they connect to CreditSync and to the merchant and agency channel modules, and the hierarchy patterns from multi-tier reseller distribution carry over almost unchanged. A shop selling airtime from a voucher management stack may also cash-in customer wallets, as long as permissions and receipts stay separate per product.

Finance measures the wallet on reversals, unmatched bank lines and overdue agent positions. Unique references, duplicate prevention and owned exception queues are the same principles behind voucher reconciliation.

Agent liquidity deserves its own line in the design. An agent who can’t pay out cash soon stops taking it in, so float rebalancing rules and CreditSync limits belong in the wallet design, not in a later operations tweak.

Channels, and the modules alongside

Apps and APIs serve onboarded customers, agents extend cash access, and USSD/SMS still matters in markets with many feature phones. Channel mix is scoped per engagement, the same way we scope EVD POS, app and USSD mixes on the EVMS product page. CreditSync tracks the distributor and agent credit that often funds wallet float; merchant and agency channels handle onboarding, commissions and QR acceptance; the shared service catalogue hangs billers and airtime off the same retail surface. For the EVD side, see what is electronic voucher distribution and about MoboGage.

Exception classes to write into the RFP

Duplicate cash-in; cash-out above the till limit; transfer to the wrong beneficiary; bill payment timed out at the biller; salary file partly posted; missed bank cut-off; returned bank payment; reversal requested after a dispute. Each needs an owner, a target age and the evidence fields to investigate it. If your RFP lists only happy-path APIs, add an exceptions appendix and ask vendors to demonstrate three of these live.

Before go-live, also confirm role-based cash limits, dual control on high-value reversals, encryption and retention for personal and transaction data, tested backup and recovery responsibilities, and third-party fees in writing. Service levels depend on the engagement and are agreed in the contract.

A pilot corridor, not a big bang

Discover → Design → Pilot → Roll out → Operate and expand. A bounded corridor makes a good pilot: one cash-in/out agent segment, or one transfer-plus-reversal product. Label: Established. Proposed banking hubs for broader reconciliation or financial-crime evidence are roadmap only.

The mobile money platform with merchant payment page carries the umbrella story; this post is the transfer, cash and reversal detail for an evaluation committee. Link both from RFP responses so the two stay consistent.

Read the platform overview at mobile money platform with merchant payment, then ask us about cash and transfer controls through the voucher management system contact page, projects@mobogage.com, or +91-9928 366 889. Founder & CEO: Sohan Lal Soni, Jaipur.

Frequently asked questions

What wallet cash-in, cash-out, transfers and reversals cover?

They are the core operating moves of a mobile money or wallet platform: funding a wallet (cash-in), withdrawing value (cash-out), moving value between parties (transfers), and undoing failed or unauthorized posts under controlled reversal rules, often with bank connectivity, bills and salary distribution in the same stack.

How does this post differ from the mobile money platform page?

The existing mobile money platform with merchant payment page introduces the broader platform. This deep-dive focuses on transfer, cash-in/out, bank connectivity, bills, salary distribution and reversal controls as operating detail for finance and ops teams.

Who retains regulated responsibilities?

Banks, licensed wallet providers and authorized partners retain regulated-service responsibilities. MoboGage provides technology and integration.

Why are reversals a first-class design topic?

Because timeouts and partial confirmations happen. Controlled reversals with unique references and dual authorization prevent silent double-posts and unowned corrections.

Can agent channels and digital channels share one wallet ledger?

That is a common design goal: one balance truth across app, USSD/SMS where used, agent cash points and API partners, with role-based limits on who may cash-in or cash-out.

How do we start?

Bound one corridor, cash-in/out for one agent segment, or transfers plus reversals for one product, then expand. Contact projects@mobogage.com or the enquiry page; also read the mobile money platform overview.

UCIP / IN Emergency Credit and Charging Integration

UCIP / IN charging and emergency credit integration connects eligibility, redemption and credit rules to an operator’s charging environment through UCIP and intelligent-network interfaces, so emergency credit grants and voucher redemptions behave the way the network expects rather than the way a retail screen promised.

The usual dispute goes like this. A shop’s terminal printed “recharge successful”, the subscriber’s balance didn’t move, and care has two systems telling two different stories. Most of these come down to what the distribution platform did when the charging node answered slowly or not at all. That is why we treat charging integration as part of distribution control, scoped before POS go-live and not patched in afterwards.

MoboGage lists charging and emergency credit as an Established telecom capability. Selected company-reported experience includes telecom charging work involving emergency credit and voucher redemption through UCIP/IN environments; scope and references are shared through due diligence. Heritage since 2007 (IWT Group, company-reported); MoboGage Private Limited was incorporated in February 2017 and its only office is the Jaipur HQ.

What a UCIP request actually carries

UCIP (User Communication Integration Protocol) is the Ericsson charging interface that external systems use to reach the AIR node. Requests are XML-RPC over HTTP POST. A refill or balance call carries an envelope of fields that matter later at reconciliation: originNodeType and originHostName (who is asking), originTransactionID (your reference, unique per request), originTimeStamp (ISO 8601 with offset) and subscriberNumber. A refill adds transactionAmount, transactionCurrency and a refillProfileID, or a voucher activation code when the refill is voucher-based. The answer comes back with a responseCode; 0 means success, and every other value needs a mapped meaning in your interface document.

Methods you will meet on most projects are GetAccountDetails and GetBalanceAndDate for eligibility and status, Refill for value, and UpdateBalanceAndDate for adjustments on the main or a dedicated account. Other IN platforms expose the same ideas under different names, and some operators sit a mediation layer in front of AIR. The integration pattern is the same either way. Our job is to carry the operator’s policy into retail and self-care channels without creating a second copy of the balance.

Emergency credit: eligibility, grant, recovery

Emergency credit is a temporary grant under operator rules, offered when a subscriber can’t top up right now. On Ericsson-style charging, one common pattern is a check against account state and history (age on network, recent recharges, any outstanding advance), a grant through a dedicated refill profile or an adjustment on a dedicated account, and recovery of the advance plus any fee on the next refill. All of those rules belong to the operator’s charging team. That includes stacking with bonuses or loans. The integration layer passes the parameters it was given and refuses to improvise when charging rejects something.

Voucher redemption is the sibling flow: a PIN or entitlement that was sold turns into network credit through the charging path. The two can share interface families and still differ in eligibility, amount, validity and repayment, so keep separate rule owners on the project plan. A change to one product’s refill profile should never silently break the other. Upstream PIN security and lifecycle controls still apply; see voucher reconciliation and PIN security.

Timeouts: the outcome nobody designs for

A request that times out may have credited, may not have, or may still be queued. The sequence we design for: hold the retail transaction in a pending state, do not tell the shop it failed, query the account (balance and date, or refill history where your AIR release exposes it) after a short delay, and only then decide. If a retry is needed, send it with a new originTransactionID that links back to the first in your own ledger, so finance can see both attempts. A second blind refill is how a subscriber ends up credited twice and the dealer debited once.

The shop and the care agent need words for each of those states. A message tied to a real response code (“charging declined: account barred”) lets them explain what happened; “pending, do not resell, check in five minutes” is a defined next step for a timeout.

Who owns which part of a disputed credit

The charging and prepaid team owns policy. That’s central to the EVMS for telecom product story and to the GCC programmes on the EVMS GCC page. A distribution or VAS partner cares about money: for products that need it, sale confirmation waits for charging confirmation, which cuts down refund arguments with agents. Finance, fraud and revenue assurance need every retail transaction matched to a charging event by reference, with explicit states and a record of each retry. Revenue-assurance AI tools that appear as Proposed in the wider portfolio are not claimed here as available.

Name the charging owner, prepaid product owner, EVD or channel owner, care owner and finance reconciliation owner before coding starts. The escalation path for “customer says credited, charging says not” fits on one page; write it and rehearse it in the pilot.

Where this meets EVD channels and PINless top-up

POS, apps, USSD, SMS and API channels that sell vouchers or trigger PINless top-up all depend on charging for the balance the customer sees. The electronic top-up system post covers PINless recharge; this one covers the charging side that makes emergency credit and redemption believable. For platform selection, see how to choose an EVMS and the homepage electronic voucher management system overview.

If a migration moves redemption onto new charging interfaces, run the charging cutover as its own workstream with its own test SIMs and rollback plan. See also EVMS migration.

What to ask any vendor

Large recharge platforms (Comviva PreTUPS, Seamless ERS 360, Telepin eTopUp among them) all say they integrate with the major charging systems, and they do. Their public pages say much less about what happens on a timeout or a mapped error. So ask every shortlisted vendor, us included, to show you three things on a lab AIR or simulator: the retail screen for each non-zero response code, the pending-then-query sequence after a forced timeout, and the reconciliation row that ties a retried request back to the original reference.

Security review should cover privileged access to credit-rule configuration, how UCIP/IN credentials are stored and rotated, and how long charging request logs are retained. Continuity planning should state what retail channels display when charging is unreachable.

Start with one interface and one use case

The company profile suggests first pilots built around one operator interface and one use case. For charging integration that means one bounded emergency-credit or redemption path, judged on observed behaviour: correct eligibility rejects, correct grants, correct failure messages, clean matching of retail references to charging references, and a rehearsed path for indeterminate cases. Put those criteria in the pilot charter rather than throughput claims. Delivery follows Discover → Design → Pilot → Roll out → Operate and expand.

Label: Established. In-development items such as CNAP, and Proposed fraud-API or revenue-assurance packages, are not presented as available charging features.

Bring the charging interface owners, the use case, and whatever exception process you run today, even if it’s a spreadsheet. Contact us through the voucher management system enquiry page, projects@mobogage.com, or +91-9928 366 889. Founder & CEO: Sohan Lal Soni, Jaipur, India.

Frequently asked questions

What is UCIP / IN emergency credit charging integration?

It is the connection of eligibility, redemption and credit rules to an operator’s charging environment through UCIP and intelligent-network (IN) interfaces, so emergency credit and voucher redemption follow operator-defined charging behaviour.

Why do operators integrate EVD with UCIP or IN?

Because retail sale and network charging must agree. Integration lets eligibility checks, credit grants and voucher redemptions execute against the live charging stack rather than as disconnected offline promises.

What rules are typically configured?

Eligibility conditions, credit amounts or denominations, validity, redemption paths, failure handling and which channel or product may trigger a charging request. Exact rule sets are operator-specific.

Does this replace the operator’s charging system?

No. The charging and IN environments remain operator-owned. MoboGage integrates eligibility, redemption and credit workflows to those environments under agreed interfaces and controls.

How does this relate to voucher distribution?

Voucher sale and inventory can live in EVD; redemption and emergency credit grant consume charging interfaces. Keeping both sides reconciled is core to prepaid integrity.

How should an operator pilot charging integration?

Bound one interface and use case, often emergency credit or a single redemption path, agree success and exception measures, then expand. Contact projects@mobogage.com or the enquiry page.

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 biometric enrolment breaks in the field

Subscriber identity in Afghanistan: the context

What we built

Who may enrol, verify or export

Planning a similar pilot

Talk to MoboGage

Frequently asked questions

What was the focus of this subscriber identity engagement?

Does this publish accuracy or throughput figures?

How does this map to Established products?

Is civic GIS or unrelated ID programmes included?

What should operators prepare for a similar pilot?

How do we enquire?

Challenge

Context

What we built

Workflow and controls

What this means for similar buyers

Talk to MoboGage

Frequently asked questions

What was the focus of this assistance delivery engagement?

Is entitlements and benefit delivery an Established product on the EVD site?

Why include it on evdsystem.com?

Are beneficiary volumes published?

What should programme authorities prepare?

How do we enquire?