Global Money Exchange put Global Pay into Oman's app stores in January 2026, per its launch announcements, and the app is built on Comviva's mobiquity Pay platform. That matters for an integration: behind a single login it keeps a running wallet balance, an exportable transaction statement, cross-border transfers priced at a live rate, QR payments, and downloadable e-receipts — exactly the per-user records a remittance partner, an accounting tool, or a merchant platform wants to read on a schedule.
The package is com.globalpay.consumer on Google Play. Global Money Exchange describes itself as the first money exchange company in Oman to hold a Payment Service Provider licence, and the platform is described as PCI-DSS certified in the launch materials. Reading those per-user records into your own systems is what this work covers: an authorized, consent-based connector built against the surfaces the app actually shows.
The authorized ways in
Three routes genuinely apply to Global Pay. They differ in what they reach and how much upkeep they ask for, and we set up the access for whichever we run with the account holder during onboarding.
Consent-based interface integration
The account holder authorizes us; we analyse the app's own mobiquity traffic and rebuild its calls as a documented connector. This reaches everything the app renders — the live wallet balance, the home-screen statement, transfer records with their corridor and booked rate, QR entries. It carries the most upkeep, because a phased feature rollout or a front-end change can move fields, so we plan a maintenance check around it. Durability is good once that check is in place.
Native statement export
Global Pay lets a user filter, download, and export their statement from the app. For plain periodic batches — feeding bookkeeping or an audit trail — that export is a low-touch path with almost no upkeep. It is bounded to what the export file carries, which is why it pairs with, rather than replaces, the consented session.
Open-banking consented channel
The Central Bank of Oman approved an Open Banking Regulatory Framework at the end of December 2024. The bank-to-provider interfaces it describes are still being stood up, so this is the forward path: durable and standards-based once live, not yet a channel you can call today.
For a build starting now, the consented session is what we would run — it is the only route that reaches the live-rate transfer records the export leaves out, and the connector is shaped so it slides onto the open-banking channel once the Central Bank's interfaces are in production. Where a client only needs clean statement batches, we wire the native export in alongside it and skip the heavier path.
What sits behind a Global Pay login
Each row is a surface the app names for its users, mapped to where it originates, how fine-grained it is, and what an integrator does with it.
| Data domain | Where it lives in the app | Granularity | Integrator use |
|---|---|---|---|
| Wallet balance & lock state | Home screen; wallet lock control (incoming/outgoing) | Current available funds, lock flag | Funds check before a payout; suspend-on-lock logic |
| Transaction statement | Full history on the home screen; filter / download / export | Per-transaction, date-filterable, exportable | Reconciliation, accounting sync, ledger backfill |
| International transfers | Send-money flow: bank, wallet, or cash pick-up; live-rate calculator | Per-transfer: corridor, beneficiary type, quoted and booked rate, status | Remittance tracking, payout-status updates |
| QR payments | Scan-to-pay; static and dynamic QR generation | Per-transaction merchant and P2P QR entries | Merchant settlement matching, P2P receipts |
| E-receipts | Per-transaction receipt, download and share | Reference, amount, fee, FX detail | Proof-of-payment archival, dispute evidence |
| Favourites & Frequents | Saved contacts and businesses; auto-built frequent list | Recipient list with identifiers | Beneficiary sync, repeat-payment screening |
| Bill payments & recharge | Telecom, electricity, water, education fees, traffic fines | Biller, amount, status per payment | Expense categorization, utility-spend reporting |
Sketch of a statement pull
Illustrative only — exact paths, headers, and field names are confirmed against captured traffic during the build. The shape mirrors a token-backed mobiquity session: authenticate, then page the statement with a date filter, refreshing the session on a 401.
POST /auth/v1/session # device + MSISDN, OTP / biometric step-up
{ "msisdn": "+968…", "deviceId": "…", "factor": "biometric" }
→ 200 { "accessToken": "…", "refreshToken": "…", "expiresIn": 900 }
GET /wallet/v1/statement?from=2026-05-01&to=2026-05-31&page=1
Authorization: Bearer <accessToken>
→ 200 {
"balance": { "available": 142.500, "currency": "OMR", "locked": false },
"entries": [
{ "txnId": "GP-8842301",
"type": "INTL_TRANSFER",
"amount": -50.000, "currency": "OMR",
"fee": 1.500,
"corridor": "OM-IN", "beneficiaryType": "BANK",
"quotedRate": 228.41, "bookedRate": 228.06,
"status": "COMPLETED", "ts": "2026-05-18T09:14:22Z" }
],
"nextPage": 2 }
# 401 → refresh once, replay; persist (quotedRate, bookedRate) as a pair
Note the rate pair. We keep the quoted and booked figures side by side so a stored remittance record squares with what the sender saw at send time.
What ships at the end
Deliverables map to the surfaces above, not to a generic checklist:
- An OpenAPI description of the calls we actually use — session, statement paging, transfer lookup, QR entries.
- A protocol and auth-flow report covering the mobiquity session model, the token lifetime, and the OTP-plus-biometric step-up.
- Runnable source for the key endpoints in Python and Node.js, with the statement pager and the rate-pair handling already wired.
- Automated tests against recorded fixtures so a field move shows up before it reaches production.
- Interface documentation an in-house team can hand to a new engineer.
- Data-retention and consent-record guidance scoped to Oman's payment rules.
Consent and who is watching
Oman's regulator is the Central Bank of Oman, which runs the country's payment rails directly — the OmanNet card switch and the Mobile Payment Clearing and Settlement System that carries instant transfers and QR payments between providers. As a Payment Service Provider, Global Money Exchange operates under the National Payment Systems Law, and the app is described as PCI-DSS certified.
The Central Bank's Open Banking Regulatory Framework was approved at the end of December 2024 and names consent management, data standards, and data security as core themes; the consented interfaces it describes are still being built out. Because that channel is not yet callable, the dependable basis for an integration today is the account holder's own authorization to access their own records. We hold consent records, log every access, retrieve only the fields a project needs, and work under an NDA where the client requires one. As the open-banking channel reaches production, the connector moves onto it and the consent model tightens to match — without changing what your side consumes.
What we plan around on this one
A few details specific to Global Pay shape how we build, and each is something we handle rather than something you supply up front:
- The mobiquity session model. Tokens are short-lived and gated behind an OTP and biometric step-up. We mirror that handshake and design the sync around session expiry, so a lapsed token triggers a clean refresh instead of a dropped run.
- Quoted versus booked FX. Cross-border rates move between the quote shown and the transfer that settles. We persist both, so reconciliation against the in-app figure does not drift by a few baisa per leg.
- One schema for two QR shapes. Static and dynamic QR payments arrive with different payloads; we normalize both into a single transaction record so merchant matching stays simple.
- A new app on a phased rollout. Global Money Exchange has said features arrive in stages. We keep a check in maintenance for when surfaces like standing instructions or bill-split land, so the connector grows with the app rather than breaking against it.
Access itself is arranged with you during onboarding — the build runs against a consenting account, and credentials never leave the logged, data-minimized path.
Where teams plug this in
- A remittance aggregator matching its own payout confirmations against Global Pay transfer records, corridor by corridor, with the booked rate attached.
- An SME accounting tool importing filtered statements for VAT bookkeeping and month-end close, with e-receipts kept as evidence.
- A merchant platform reconciling dynamic-QR settlements to orders in near real time.
- A treasury dashboard reading wallet balance and lock state before it schedules outbound runs.
Screens we worked from
Store screenshots, tapped to enlarge. These are what the surface mapping above is read against.
What was checked, and when
Notes from OpenBanking Studio's integration desk, reviewed 11 June 2026. We read the app's Play Store listing and feature description, the launch announcements naming the Comviva mobiquity platform and the PSP licence, and the Central Bank of Oman's published material on open banking and its mobile-payment switching rules. Primary sources:
Questions integrators ask about Global Pay
Which records can a connected Global Pay account hand back?
A consented session exposes the wallet balance and lock state, the full transaction statement the app shows on its home screen — filterable and exportable — plus international transfer records with their corridor, beneficiary type and booked rate, QR payment entries, downloadable e-receipts, saved Favourites and Frequents, and bill-payment and recharge history.
Is Global Pay covered by Oman's open-banking rules yet?
The Central Bank of Oman approved its Open Banking Regulatory Framework at the end of December 2024, and the bank-to-provider interfaces it describes are still being stood up. So the dependable basis today is the account holder's own authorization; as the consented channel goes live we move the connector onto it without changing what your side consumes.
How is the live exchange rate on a cross-border transfer captured?
Rates are quoted at send time and can move between the quote and the booked transfer. We record both the quoted rate the user saw and the rate the transfer settled at, so a stored remittance record reconciles cleanly against the figure shown in the app.
Global Pay runs on Comviva's mobiquity Pay — does that shape the work?
It does. We map the mobiquity session and token model and the OTP-plus-biometric step-up the app uses, so the connector authenticates the way a real client does and the sync is designed around session expiry rather than breaking when a token lapses.
Working with us
Source for the statement and transfer endpoints, an OpenAPI description of each call, the auth-flow report, and the tests land in your repository inside one to two weeks of a green light. Take it as a one-off source-code delivery from $300, paid only once it is in your hands and working as described — or skip the build entirely and call our hosted endpoints, paying per call with nothing upfront. Tell us what you need out of Global Pay and we will name the route and the price on our contact page.
Global Pay Oman — app profile
Global Pay is a consumer mobile-money and international-remittance app published by Global Money Exchange Co. LLC (GMEC) for Oman, package com.globalpay.consumer, launched in January 2026 per its announcements and built on Comviva's mobiquity Pay platform. It supports local send and receive, international transfers to bank accounts, mobile wallets, and cash pick-up with a live-rate calculator, cash withdrawal at Global Money Exchange branches, QR payments with static and dynamic codes, an exportable transaction statement, e-receipts, biometric login, wallet lock, Favourites and Frequents, and bill payment and recharge. GMEC reports growth from a single branch in 2002 to one of Oman's larger exchange companies. This page is an independent integration write-up and is not affiliated with GMEC.