Pulling wallet, transfer and statement data out of Global Pay Oman

Global Money Exchange Co. LLC put Global Pay live in January 2026 on Comviva's mobiquity Pay platform, per the company's launch announcement. The wallet now keeps per-user balances, a full transaction statement, and cross-border remittance records for customers across Oman — exactly the structured ledger a payments team, an accounting tool, or a remittance aggregator wants to read in one place. This page is about getting that ledger into your own systems as running code: a thin client library, a sync loop, and tests, with the access and consent work handled as part of the build rather than handed to you as homework.

The honest bottom line: everything a Global Pay user can see in the app — their balance, their statement, a given remittance with its locked rate and e-receipt — is reachable for a consenting account, and we deliver it as a normalized feed. The remittance side is the richest part, because each international transfer carries a corridor, a payout method, and an exchange rate captured at submission. That is the data most teams come here for.

Account data the app holds

The table maps each surface to where it shows up in the app, how fine-grained it is, and the typical reason an integrator wants it. Rows reflect Global Pay's actual screens and the feature list on its store pages, not a generic wallet template.

Routes to the data, and the one we would take

Three authorized paths fit Global Pay. They differ in reach, durability, and how much setup we do up front — and we arrange the access for each one with you during onboarding, not as a gate you clear first.

Authorized protocol analysis (recommended to start)

We observe and reconstruct the traffic the app exchanges with its mobiquity Pay backend for a consenting account, then build typed clients for login, balance, statement, transfer, and receipt calls. Reach is everything the user sees. Effort is moderate; durability is tied to app releases, so we version the client and keep a small contract test that flags a change before it reaches your data. This gives full coverage on the fastest timeline.

Oman open-banking consent (the durable path as it matures)

The Central Bank of Oman approved an open-banking regulatory framework at the end of 2024, and its rollout is phased. As consent-based access for licensed institutions comes online, it becomes the long-run, regulator-backed route, and we set up the consent flow and token handling with you and the consenting account. We treat this as where the integration migrates over time, not a precondition for starting.

Native export, as a stopgap

Global Pay lets a user filter, download, and export statements and share e-receipts. We can wire that into an ingestion job for proof-of-payment files while the live client is built — useful, but coarse and file-shaped compared with a delta-synced feed. In practice we lead with protocol analysis for full, normalized coverage, fold the export in for receipts, and move the spine onto open-banking consent as that framework opens up.

What lands in your repo

The deliverable is working software first, paperwork second. For Global Pay that means:

• A client library in Python and Node.js wrapping the login and token-refresh chain, balance, statement query, transfer lookup, and e-receipt fetch — importable, typed, documented.
• A sync worker that backfills historical statements once and then runs a cursor-based delta against the transaction feed, deduplicated by transaction id.
• An automated test suite (pytest and Jest) that runs against a consenting account or sandbox and asserts the field shapes hold, so a backend change shows up as a red test rather than quietly corrupting your ledger.
• A normalized schema mapping transactions, transfers, receipts, and beneficiaries onto stable names that drop into your store.
• A batch-versus-realtime sync design sized to your wallet volume and freshness needs.

Alongside the code you also get an OpenAPI description of the mapped surface, a short auth-flow report covering the token and session chain, interface documentation, and data-retention guidance. Those round out the handover; the running client and sync loop are the point.

A sample pull: statement and a remittance

Illustrative use of the delivered Python client. Field names are normalized in delivery and confirmed against a consenting account during the build; the auth and refresh chain is handled inside the client so your code never touches raw tokens.

from globalpay import GlobalPayClient   # delivered SDK

gp = GlobalPayClient.from_session(refresh_token=TOKEN)   # token chain handled internally

# backfill + delta: pull statement entries newer than the last cursor
page = gp.statements.list(since="2026-05-01", cursor=None, limit=100)
for txn in page.items:
    print(txn.id, txn.type, txn.amount_omr, txn.counterparty, txn.description)
    # txn.type -> "send" | "receive" | "qr_pay" | "bill" | "withdrawal"

# open one international transfer with its locked rate + receipt
remit = gp.transfers.get(page.items[0].id)
remit.corridor        # e.g. "OM-IN"  (India, Pakistan, Philippines, Egypt ...)
remit.payout_method   # "bank_account" | "mobile_wallet" | "cash_pickup"
remit.fx_rate         # rate captured at submission, not current market
remit.e_receipt_url   # downloadable e-receipt reference

# resume safely next run from where this page ended
save_cursor(page.next_cursor)

The normalized transfer record looks like this once mapped — the shape your ledger actually consumes:

{
  "id": "txn_...",
  "kind": "international_transfer",
  "amount_omr": "120.000",
  "corridor": "OM-IN",
  "payout_method": "bank_account",
  "fx_rate": "229.41",
  "settled_amount": "27529.20",
  "settled_currency": "INR",
  "beneficiary_ref": "ben_...",
  "e_receipt_url": "https://.../receipt/...",
  "created_at": "2026-05-12T08:41:11Z"
}

Where teams plug it in

• A remittance comparison or tracking product reading a user's outbound transfers, with the submitted FX rate kept intact for accurate corridor reporting.
• An SME bookkeeping tool that ingests Global Pay bill payments and QR settlements and categorizes them next to other accounts.
• A treasury or reconciliation job matching wallet top-ups and withdrawals at Global Money Exchange branches against an internal ledger.
• A personal-finance aggregator that adds a Global Pay wallet beside a user's bank and other Oman wallets in one normalized feed.

Consent and Oman's open-banking rules

Global Pay is a Central Bank of Oman regulated payments product, and GMEC describes the platform as PCI-DSS certified in its launch announcement. We work inside that posture: authorized access only, every pull logged, the data set minimized to what your use case needs, and an NDA where the engagement calls for one. Consent from the account holder is recorded, scoped to the surfaces you actually use, and revocable — when consent ends, the sync stops and we hold no standing credentials.

The regulatory direction is clear. The Central Bank of Oman approved an open-banking regulatory framework at the end of 2024, following a public consultation that closed in 2024, covering consent management, data standards, and security. The rollout is phased rather than fully live, so we do not lean on specific scheme obligations as settled today; the dependable basis for the integration is the consenting user's own authorization, and the consent-based route is where the build migrates as the framework opens to licensed third parties.

What we plan around in this build

A few Global Pay specifics shape the engineering, and we handle each rather than pass it back to you:

• Biometric, PIN-less sessions. The app logs in and transacts with face or fingerprint instead of a manual PIN. We design the session and refresh handling around that device-bound token so an unattended sync keeps running without re-prompting biometrics every cycle; the consenting account is set up with you at onboarding.
• A user-lockable wallet. Holders can lock the wallet for incoming or outgoing payments at will. We treat a locked state as a first-class condition so the sync degrades gracefully and reports it, instead of erroring or silently stalling.
• Rate-at-send on remittances. International transfers lock an exchange rate at submission. We snapshot that rate and the settled amount with the transaction, so your records reflect what the recipient received rather than the rate at read time.
• Interoperable QR. QR accepts customers of any Oman bank or provider and also drives branch cash withdrawals. We normalize merchant, peer-to-peer, and withdrawal QR events into distinct typed records so they reconcile cleanly.

Interface evidence

Store screenshots used while mapping the surfaces above. Select one to enlarge.

Other Oman wallets and exchanges you might unify

If the goal is one feed across Oman payments, these neighbouring apps hold comparable data. Listed for context, not ranked.

• Thawani Pay — Oman's first non-bank payment service provider licensed by the Central Bank of Oman; wallet balances, QR, bill pay, and local transfers.
• pay+ — the Ooredoo and National Bank of Oman wallet with international remittance via MoneyGram; wallet and transfer history.
• Friendi Pay Oman — free wallet-to-wallet transfers within Oman plus corridor remittance; peer-to-peer transfer records.
• Unimoni Oman — remittance and foreign-exchange brand with an app; outbound transfer and beneficiary data.
• Modern Exchange Oman — beneficiary-driven remittance flows; transfer requests and recipient details.
• Oman Exchange — exchange house with money-transfer and currency services; remittance history.
• Lulu Exchange — remittance house with a consumer app; outbound transfers across corridors.
• MoneyGram — the global payout network many Oman corridors settle through; pickup and payout records.

Integrator questions

Can we get new Global Pay transactions soon after they post, or only as an overnight batch?

Both. The delivered client backfills historical statements once, then runs a cursor-based delta sync against the home-screen transaction feed on whatever interval you set — a few minutes for an active wallet, hourly for a quieter one. Where a consenting account allows a notification poll, new entries land within that poll window rather than waiting for a nightly run.

Does the normalized data keep the live FX rate that was shown on an international transfer?

Yes. International transfers carry the corridor, the payout method (bank account, mobile wallet or cash pick-up), and the exchange rate locked at the moment of submission. We capture that submitted rate, not the current market rate, so your ledger matches the amount the recipient actually settled. The e-receipt reference is attached to the same record.

How does Oman's open-banking framework change how we reach this data?

The Central Bank of Oman approved an open-banking regulatory framework at the end of 2024 and its rollout is phased. As consent-based access for licensed institutions matures, that becomes the durable long-run route. Until it is broadly live, the dependable basis is the account holder's own authorization, which is what we build against from day one.

We already download statements from the app by hand — what does an integration add?

The in-app export gives you coarse files on demand. The integration gives you typed records — transactions, transfers, e-receipts, beneficiaries — with stable field names, deduplicated by transaction id, refreshed automatically, and shaped to drop straight into a ledger or reconciliation job instead of a spreadsheet you re-import.

How this was put together

Mapped on 8 June 2026 from Global Pay's Google Play listing and its iOS App Store entry, the GMEC and Comviva launch announcement, and the Central Bank of Oman's open-banking material; the package id and feature set are taken from those public pages, and the FX and corridor behaviour from the app's described flows. Primary sources opened:

• Global Pay Oman on Google Play (com.globalpay.consumer)
• GMEC / Comviva launch announcement (PR Newswire)
• Central Bank of Oman — Open Banking Regulatory Framework
• FinTech Futures — CBO approves open-banking framework

OpenFinance Lab · integration engineering notes, reviewed 2026-06-08.

A first working pull on Global Pay typically lands inside a one-to-two-week cycle. You can take it as a source-code delivery from $300 — runnable client, sync worker, tests, and docs handed to you, paid after delivery once you are satisfied. Or skip the build and call our hosted endpoints, paying per call with no upfront fee. Either way you give us the app name and what you want from its data; we handle the access, consent, and compliance work with you. Tell us which records you need and the corridors that matter, and we will scope it: Start a Global Pay integration