Reaching Zakhir's balance and transfer data the authorized way

The Central Bank of Sudan licenses Zakhir as an electronic wallet, which means every balance, transfer and bill payment a user sees is held on Zakhir's servers, not on the phone. That is the whole reason this app is worth integrating: the record of who paid whom, how much in Sudanese pounds, and when, exists as server-side state behind a phone-number login. A remittance firm, a Sudanese merchant, or a treasury team that wants those records in its own systems needs a programmatic way in. Sudan has no Account Information Services scheme to provide one. So the route is built, not granted — and that is the work described here.

What Zakhir stores per account

Zakhir's public materials and app listing describe a fairly standard wallet surface: send and receive money between users, pay at a merchant, shop at local and online stores, top up the balance, deposit and withdraw, recharge airtime for all networks, and pay bills such as Zain and electricity. Each of those produces a server-side record. Mapped to what an integrator would actually consume:

None of this is exotic. It is the ledger of a working wallet, and it is the part worth the engineering.

The authorized route into Zakhir, given Sudan's rules

Three routes are realistic here. We would recommend the first as the backbone and treat the others as supplements.

1 — Authorized interface integration (recommended)

We capture and document the wallet client's own traffic — login and OTP against a Sudanese number, token issuance, then the balance and history calls — and rebuild it as a clean API under authorization from the account holder or your own authorized program. Reach is the full wallet surface above. Effort is moderate and front-loaded into the mapping. Durability is good once the protocol report exists, with a re-check when Zakhir ships a new client. Access and the test wallet are arranged with you during onboarding; that is our step, not a hurdle for you.

2 — User-consented credential access

For per-account pulls where an end user consents, the same captured flow runs on a per-user basis to fetch that user's balance and transactions. Narrower reach, simplest consent story, and a natural fit for an aggregation product where each Zakhir holder opts in.

3 — In-app history export as a thin fallback

Where a user can view or share their own activity, that view is the lowest-fidelity backstop — useful for one-off pulls, weak for continuous sync. We treat it as a fallback, not a foundation.

Route 1 carries the work; route 2 covers consented per-user cases; route 3 is only there for the edges. We say which fits your use after a short look at your volumes and authorization model.

A worked example: reading the Zakhir transaction feed

Illustrative shape only — exact field and path names are confirmed during the build against the live client, not guessed here.

POST /v1/auth/otp/verify
  { "msisdn": "+24991XXXXXXX", "otp": "######", "deviceId": "ob-studio-rig-01" }
-> 200 { "access_token": "…", "refresh_token": "…", "expiresIn": 900 }

GET /v1/wallet/balance        Authorization: Bearer 
-> 200 { "walletId": "ZK-…", "currency": "SDG", "available": 184350.00 }

GET /v1/wallet/transactions?cursor=&limit=50
-> 200 {
     "items": [
       { "txnId": "T-…", "type": "P2P_RECEIVE",
         "counterpartyMsisdn": "+24990XXXXXXX",
         "amount": 50000.00, "currency": "SDG",
         "status": "SUCCESS", "createdAt": "2026-05-12T08:41:07Z",
         "channel": "WALLET", "reference": "…" },
       { "txnId": "T-…", "type": "BILL_PAY", "biller": "ZAIN",
         "amount": 3000.00, "status": "SUCCESS", "createdAt": "…" }
     ],
     "nextCursor": "…"
   }

# token refresh on 401; backoff + idempotent replay on 5xx;
# biller hops (ZAIN / ELECTRICITY) tagged separately from wallet-core

The protocol report names the real auth chain, pagination behaviour, error and retry semantics, and which calls touch Zakhir's own ledger versus a biller. The runnable source implements exactly that.

What you get back from the engagement

Concrete artifacts, scoped to Zakhir's actual surface:

• An OpenAPI/Swagger spec for the wallet endpoints we map — auth, balance, transactions, transfer status.
• A protocol and auth-flow report: the OTP/token/refresh chain, headers, device binding, pagination, error model, and the wallet-core versus biller split.
• Runnable source for the key calls in Python and Node.js, with token refresh and retry handled.
• Automated tests covering auth, paging, and the transaction-type taxonomy (P2P send/receive, cash-in/out, merchant, bill, top-up).
• Interface documentation a developer can hand to a teammate.
• Compliance and data-retention guidance written for Sudan's situation — consent records, logging, and data minimization.

Three jobs this integration usually does

1. Remittance reconciliation. A provider paying funds into Sudan matches each disbursement to the Zakhir P2P_RECEIVE event by MSISDN, amount and timestamp, and closes the loop automatically instead of by screenshot.
2. Merchant settlement. A Sudanese store or marketplace pulls settlement-grade records of its pay-at-merchant transactions into its own books, separated from airtime and bill noise.
3. Business treasury view. A finance team aggregates a company's Zakhir wallet activity into a normalized statement for accounting and AML review, refreshed on a schedule.

Sudan's rules: CBoS licensing, and no data-protection statute yet

Two facts shape compliance here. First, Zakhir holds a Central Bank of Sudan electronic-money licence; mobile money is a recognized payment instrument in Sudan, and the national e-payment switch run by Electronic Banking Services (EBS) sits behind the bank rails the wallet touches. Second, per Data Protection Africa's Sudan fact sheet, Sudan has no comprehensive data-protection statute and no independent data-protection authority — a 2018 draft bill remains a draft, and the relevant instruments are sectoral (the Cybercrime Act 2007 and amendments, plus KYC under the country's AML/CFT framework). Section 55 of the constitution protects privacy of correspondence.

The practical consequence: there is no local statute we can lean on as a backstop, so consent is the control. We work from authorized, documented, or user-consented access only; we keep consent and access logs; we capture the minimum fields a use needs and drop the rest; and we sign an NDA where the engagement calls for one. Consent scope, expiry and revocation are written into the integration so a stale grant fails closed rather than quietly continuing.

Engineering realities we plan around for Zakhir

Specifics we account for, not things we ask you to solve:

• Android + Sudanese-MSISDN binding. The only client today targets Android and Sudanese numbers, so we build and verify against exactly that, with the test wallet and number arranged with you at onboarding. Because the API is rebuilt from the wallet's own calls, it keeps working if an iOS build or international numbers arrive later.
• Wallet-core versus biller traffic. Zakhir's own ledger calls are interleaved with Zain airtime, electricity and bill-pay hops. We separate them in the protocol report so your integration depends only on the wallet surface and does not break when a biller changes on its side.
• Fast client iteration. Wallet apps in Sudan move quickly under currency and connectivity pressure. When Zakhir ships a new build we re-capture and diff the traffic before anything in your integration is touched; that diff is part of how maintenance runs.
• No statutory safety net. With no Sudanese data-protection law to fall back on, the build is data-minimized by default and consent is logged by us, rather than assumed to be covered by a regulator.

Screens from the Zakhir app

Store screenshots, shown for interface reference. Tap to enlarge.

Where Zakhir sits among Sudan's wallets

Zakhir is one of several Sudanese payment apps an integrator may want unified behind a single schema. Named neutrally, for ecosystem context:

• Bankak (بنكك) — Bank of Khartoum's app, the most widely used in Sudan; holds bank-account and transfer data tied to a formal account.
• O-Cash — Omdurman National Bank's wallet, holding wallet and transfer records.
• Cashi — an electronic payment network described as Central Bank of Sudan-licensed; merchant and consumer payment records.
• MyCash — a mobile wallet usable without a formal bank account; balance and transfer history.
• RittalPay — a mobile digital wallet in the same no-bank-account segment as MyCash.
• Fawry / Fawry+ (Faisal Islamic Bank, Sudan) — bank-affiliated wallet and bill-payment records.
• Bravo Sudan Pay — a Sudan-focused payment app with consumer transaction data.
• Bedi (بيدي) — Zain's electronic wallet; mobile-money balance and transfer history.

Each keeps its own ledger; the integration value is a common shape across them, with Zakhir as one node.

What we checked, and when

This mapping was put together on 17 May 2026 from Zakhir's own site and customer terms, its Google Play listing (package sd.zakhir.wallet, per that listing), Sudanese fintech and mobile-money reporting, and a country data-protection reference. Primary sources opened:

• zakhir.net — features, account model, and the Central Bank of Sudan licensing statement.
• Google Play listing — platform, services, and verification description.
• The New Humanitarian — Sudan's digital-money landscape and peer apps.
• Data Protection Africa — Sudan — the absence of a comprehensive data-protection statute.

OpenBanking Studio · integration desk notes, 17 May 2026.

Questions Zakhir integrators ask us

Zakhir runs on Android and Sudanese mobile numbers only — does that cap what you can integrate?

No. The integration reads the wallet's own network calls, not its UI, so a single Android client and one Sudanese MSISDN is enough to map the full surface. The test number and wallet are set up with you during onboarding; the resulting API behaves the same regardless of which client made the original calls, and stays valid if an iOS build or international numbers arrive later.

Sudan has no open-banking mandate, so on what basis do you reach Zakhir's data?

There is no Account Information Services scheme in Sudan the way there is in the UK or Brazil, so the route is authorized interface integration: documented protocol analysis of the wallet's traffic under the account holder's consent or your own authorized program, which we paper during onboarding. Zakhir operates under a Central Bank of Sudan e-money licence, and the work is logged and data-minimized to fit that posture.

Can you separate Zakhir's own wallet ledger from the Zain top-up and electricity rails it talks to?

Yes. The protocol report labels each call as Zakhir-core (balance, P2P transfer, cash-in, cash-out) or a third-party biller hop (Zain airtime, electricity, bill pay). Your integration depends only on the wallet's own endpoints, so a change on a biller side does not ripple into your code.

We already run a remittance product paying into Sudan — can a Zakhir feed reconcile it without holding more data than we need?

Yes. We normalize incoming P2P_RECEIVE events to the few fields a payout reconciliation needs — counterparty MSISDN, amount in SDG, status, timestamp, reference — and leave the rest out. A working build of that slice lands in 1–2 weeks. Tell us the volumes and we will scope it at /contact.html.

Source for the Zakhir endpoints, with the OpenAPI spec, runnable Python and Node.js, and tests, starts at $300 and is invoiced only after delivery once you are satisfied with it; if you would rather not host anything, the same surface is available as a pay-per-call hosted API with no upfront fee. Either way the working build lands in 1–2 weeks. Send the app name and what you want from its data via /contact.html and we will scope it.