Zakhir | زاخر API integration services (Sudan OpenFinance)

Deliverables checklist

• OpenAPI 3.1 / Swagger specification for every exposed endpoint
• Protocol & auth-flow report (token chain, refresh, replay protection)
• Runnable source for login, statement, bill-pay and airtime APIs (Python & Node.js)
• Postman collection plus pytest / Jest integration tests
• Excel / CSV / PDF statement exporters with idempotent paging
• Compliance briefing aligned with CBOS KYC/CDD and data-minimisation guidance

Two engagement models

• Source-code delivery from $300 — receive runnable API source plus full docs; pay after delivery upon satisfaction.
• Pay-per-call API billing — call our hosted Zakhir endpoints, pay per call, no upfront commitment; ideal for usage-based products.
• Optional managed maintenance: protocol watch, auth rotation, weekly regression run.

Where this fits

Treasury teams reconciling Sudan spend, remittance corridors that route into Sudanese wallets, NGO payouts to displaced populations, ERP add-ons that ingest Zakhir statements alongside Bankak or Bede flows, and analytics products serving merchants accepting Zakhir at the point of sale.

1. Diaspora remittance reconciliation

Context: a Gulf-based remittance operator pays out into Sudanese Zakhir wallets. Data / API: the /wallet/transactions endpoint returns inbound transfers with reference IDs; webhooks emit a credit.posted event. OpenFinance mapping: aligned with cross-border PISP-style flows — payout initiation upstream, confirmation polling and statement reconciliation downstream against a single canonical ledger.

2. NGO cash-assistance audit

Context: a humanitarian programme distributes aid to displaced households via Zakhir wallets. Data / API: beneficiary KYC status plus per-wallet statement exports keyed by programme cohort. OpenFinance mapping: AISP-style read-only access under explicit consent; data minimised to amount, timestamp and merchant category, with PII tokenised before reaching the donor reporting warehouse.

3. SME bill aggregator

Context: a Khartoum SaaS platform lets merchants pay Zain bills and electricity from one console. Data / API: /bills/zain and /bills/electricity POST endpoints; balance check before submit. OpenFinance mapping: payment-initiation pattern with idempotency keys, merchant-side webhook for asynchronous settlement, and a daily settlement statement pulled via /wallet/statement.

4. Cross-wallet personal finance dashboard

Context: a personal finance app shows users their balances across Zakhir, Bankak and the new Bede wallet. Data / API: normalised account, balance and transaction objects from every connected wallet. OpenFinance mapping: a connector layer that mirrors the spirit of UK Open Banking AISPs — same access-token model, same revocation flow, adapted to Sudan's licensing environment.

5. Agent-network analytics

Context: a fintech operating an authorized-agent footprint wants to see which Zakhir agents drive the most volume by state. Data / API: agent cash-in/cash-out events enriched with geo and fee data. OpenFinance mapping: data-product pattern — raw events ingested via webhook, aggregated nightly, exposed through a private GraphQL endpoint for the operations team.

Login & session bootstrap

POST /api/v1/zakhir/auth/login
Content-Type: application/json

{
  "msisdn": "+2499XXXXXXXX",
  "device_id": "uuid-v4",
  "otp": "123456"
}

200 OK
{
  "access_token": "eyJhbGciOi...",
  "refresh_token": "rt_8f...",
  "expires_in": 1800,
  "kyc_level": "FULL"
}

Statement query (paginated)

POST /api/v1/zakhir/statement
Authorization: Bearer <ACCESS_TOKEN>
Content-Type: application/json

{
  "wallet_id": "wlt_01HXYZ...",
  "from_date": "2026-04-01",
  "to_date":   "2026-04-30",
  "types": ["P2P", "AGENT_TOPUP", "BILL", "ELECTRICITY"],
  "page": 1,
  "page_size": 100
}

200 OK
{
  "items": [ { "id":"tx_...", "amount":"15000.00", "currency":"SDG",
               "type":"BILL", "biller":"ZAIN", "status":"SETTLED",
               "ts":"2026-04-12T08:31:04Z" } ],
  "next_page": 2,
  "total": 287
}

Webhook: credit posted

POST https://your-app.example/zakhir/webhook
X-Signature: sha256=...

{
  "event": "credit.posted",
  "wallet_id": "wlt_01HXYZ...",
  "tx_id": "tx_01HZ...",
  "amount": "50000.00",
  "currency": "SDG",
  "source": "FAWRI_FAISAL_ISLAMIC",
  "reference": "RMTN-2026-0042",
  "ts": "2026-05-09T19:14:22Z"
}

// Verify HMAC, ack 2xx within 5s, then enqueue.
// Errors return { "error": { "code":"...", "message":"...",
// "retryable": true } } with structured codes.

Regulatory alignment

Zakhir operates under licence from the Central Bank of Sudan (CBOS). Our integrations follow CBOS KYC/CDD identification rules — verification through a national ID, passport or other accepted document — and respect the simplified remote-onboarding rules CBOS has gradually relaxed. We avoid any flow that would conflict with CBOS payment-services circulars or the financial inclusion goals tracked by international observers such as the CGAP commentary on Sudan's financial system.

Data handling

• Authorized or documented public channels only — no scraping that breaches the app's terms.
• Per-user consent records, with revocation that propagates to caches and warehouses within 24 hours.
• Field-level minimisation: PII is hashed unless your downstream legitimately needs it.
• Transit TLS 1.2+; at-rest encryption with rotating KMS keys.
• Audit trail for every API call: request hash, actor, consent ID, response code.

About OpenFinance Lab

We are an independent technical studio focused on mobile-app protocol analysis and OpenData / OpenFinance / OpenBanking API integration. The team brings hands-on experience from payment gateways, retail banking, mobile-money platforms across Africa and the Middle East, and high-traffic fintech back-ends. We ship end-to-end financial APIs under licensing, security and compliance constraints rather than one-off scripts.

• Mobile money, retail banking, insurtech and cross-border clearing — Sudan, Gulf, East Africa
• Enterprise API gateways, security reviews, key-management hardening
• Custom Python / Node.js / Go SDKs, Postman collections and test harnesses
• Full pipeline: protocol analysis → build → validation → compliance briefing
• Source-code delivery from $300 — runnable API source plus full documentation; pay after delivery upon satisfaction
• Pay-per-call API billing — access our hosted API and pay only per call, no upfront cost; ideal for usage-based pricing

Contact

For quotes, scoping calls, or to submit your Zakhir / Sudan wallet integration requirements, open our contact page:

Contact page

Typical first reply within one business day. NDAs supplied on request before any sample code is shared.

Engagement workflow

1. Scope confirmation: which Zakhir surfaces (login, statement, bills, electricity, agent flow) you actually need.
2. Protocol analysis & API design (2–5 business days, complexity-dependent).
3. Build & internal validation against a sandbox or shadow account (3–8 business days).
4. Docs, samples and test cases (1–2 business days).
5. Typical first delivery: 5–15 business days; partner-bank approvals may extend timelines.

FAQ

Does Zakhir publish a public API?

What Zakhir data can be exposed via OpenFinance integration?

How long does a first Zakhir API drop take?

Is this compliant with Central Bank of Sudan rules?