Reaching Soonapay's money-movement records through a consented account

Every confirmed transfer inside Soonapay is a small structured event: an amount, a currency, a counterparty, a corridor, a status, a timestamp. Multiply that by local payouts, international remittance legs, airtime top-ups, bill settlements and virtual-card spend, and the account behind one Soonapay user is a real-time ledger of money in motion. That ledger is the thing a partner, an accountant, a treasury team or a downstream service wants to read — and it is what an authorized integration makes queryable. Soona-Pay, published by Soona Technology Ltd per its App Store listing, runs primarily in Sudan with cross-border corridors, and its data sits behind an authenticated account rather than in any open feed.

The short version: the data is rich and worth syncing, the account is the gate, and the route that holds up here is mapping Soonapay's own authenticated traffic under the account holder's authorization, then re-validating that map when the app changes. The rest of this page is the detail behind that judgment — what the surfaces are, how we reach them, what we hand over, and how Sudan's rules shape consent.

What the account actually holds

These are the surfaces a consented Soonapay session exposes, named the way the app presents them where the listing makes that clear. Granularity is what an integrator should expect per record, not a promise of fields we have not seen.

How we reach it

Two or three routes genuinely apply to a wallet like this. None of them depends on anything the customer must clear first — onboarding and access are arranged with the account holder as part of the work.

Protocol mapping of Soonapay's authenticated traffic

With the account holder's authorization, we observe how the app authenticates and how it requests each surface, then reproduce those calls in clean code. This reaches everything in the table above, because it reads exactly what the app reads. Effort is moderate; durability is good once the auth chain and endpoints are documented, and we re-validate the map whenever the app front end shifts. For Soonapay this is the route we would actually run — it covers the full ledger, it does not wait on any external scheme, and it survives ordinary app updates with a maintenance pass.

User-consented session access

A lighter variant for one-off or low-volume needs: the account holder consents, and we drive the authenticated session to export the records they want. Quick to stand up, but it leans on a live session, so it suits periodic pulls more than a continuous high-throughput sync.

Licensed-rail access

Where a client is itself a licensed participant, money-movement data can route through Sudan's regulated payment infrastructure — the switch operated by Electronic Banking Services under Central Bank of Sudan supervision. Onboarding here is heavier and institutional, but the resulting link is the most durable. We scope this only when the client holds, or is pursuing, the relevant license.

Auth and query flow

Illustrative shape of a consented pull, confirmed against the live surfaces during the build. Field names are normalized on our side; the raw payload arrives bilingual.

POST /api/v1/auth/login
{ "msisdn": "+2499XXXXXXXX", "pin": "••••", "device_id": "<registered>" }
  -> 200 { "access_token": "<jwt>", "refresh_token": "<…>", "expires_in": 1800 }

# token expires mid-pull on long histories — refresh, don't re-login
GET /api/v1/transfers?from=2026-01-01&cursor=<next>
Authorization: Bearer <jwt>
  -> 200 {
       "items": [
         { "id": "...", "amount": "150000", "currency": "SDG",
           "direction": "out", "corridor": "local",
           "counterparty": "...", "status": "completed",
           "created_at": "2026-05-12T08:41:00Z" }
       ],
       "next_cursor": "..."        # resumable; survives a dropped connection
     }

# normalize before schema: Arabic-Indic digits -> ASCII, RTL labels mapped
def to_canonical(rec):
    return {
        "amount": ar_digits_to_int(rec["amount"]),
        "currency": rec["currency"],            # keep code; never collapse to one base
        "kind": classify(rec["corridor"]),      # local | cross_border
        "status": rec["status"],
        "ts": rec["created_at"],
    }

Two things in that flow are not incidental: the access token is short-lived, so any pull over a long transfer history has to refresh rather than re-authenticate; and the cursor is resumable, which matters in a market where connections drop. Both are handled in the runnable source, not left to the caller.

What lands in your repo

The output is working code and the documents around it, tied to Soonapay's real surfaces:

• An OpenAPI/Swagger specification covering the transfer, top-up, bill-pay, card, balance and beneficiary endpoints as mapped.
• A protocol and auth-flow report: the login, JWT issuance and refresh chain, and how each surface is requested.
• Runnable source for the key endpoints in Python or Node.js, including the digit-normalization and resumable-cursor handling shown above.
• Automated tests against recorded fixtures, so a future app change fails loudly instead of silently returning wrong data.
• Interface documentation a developer can hand to the next engineer, plus data-retention and consent-logging guidance for the records you hold.

Consent and who watches the rails

Sudan's e-money and mobile-payment activity is supervised by the Central Bank of Sudan, which licenses providers and oversees the national retail switch run by Electronic Banking Services; the governing instruments include the Electronic Transactions Act and the Bank's AML/CFT requirements, per the CBoS laws-and-regulations index. There is no comprehensive standalone personal-data-protection statute in force in Sudan that we rely on here, so we do not pretend one governs the work. The dependable basis is the account holder's own documented authorization — scoped to named data domains, time-boxed, and revocable. We record consent per pull, log access, minimize what is retained to the fields the client actually needs, and work under NDA where the engagement calls for it. That is how the studio operates regardless of market; in Sudan it is also the honest legal footing.

Engineering notes specific to this build

Things we account for because Soonapay is what it is, not a generic wallet:

• The payloads are bilingual. Field labels and numerals come back in Arabic and English, so the parser normalizes Arabic-Indic digits and right-to-left strings to one canonical schema before any business logic runs.
• Transfers cross currencies. A single account can hold SDG, USD or SAR records, so amounts always carry their currency code and we keep FX context per transaction rather than flattening to one base unit.
• Sessions expire mid-pull. We build the sync around the token-refresh window so a long history export does not die halfway and re-trigger a fresh login.
• Connectivity is volatile. In the Sudanese market networks drop, so pulls are idempotent and cursor-resumable, and a re-validation pass is part of maintenance for when the app's front end moves.

Pricing

Source code lands in your repository, not a slide deck — that is the unit of work here. There are two ways to pay for it. You can take source-code delivery from $300: runnable API source plus the spec, tests and interface docs, and you pay after delivery once the integration runs and you are satisfied. Or you can use the hosted API and pay per call: you hit our endpoints, you pay only for the calls you make, and there is no upfront fee. Either way the cycle is one to two weeks. Tell us the app and what you need from its data, and we handle the access and compliance arrangements with you from there — start at /contact.html.

Interface evidence

Store screenshots of the surfaces described above. Click to enlarge.

Keeping the map current

An app this active changes its front end, and a mapped integration that is not watched will quietly start returning gaps. The fixture-backed tests are the trip-wire: when a field moves or an endpoint shape shifts, a test fails and the maintenance pass updates the map. For polling cadence, balances and recent transfers are worth pulling often; profile and beneficiary data change rarely and can sync on a slower schedule. We size the refresh windows to the surface, not one blanket interval.

Comparable apps in the same space

Other Sudan and regional finance apps hold overlapping data; naming them widens the picture for anyone building a unified view across wallets. These are listed for context, not ranked.

• Bankak — the Bank of Khartoum app; account, transfer and bill data behind a bank login.
• Cashi — a licensed Sudanese payment network with bill payment, local remittance and cash-in/out records.
• Dahabshiil — cross-border remittance to many countries; send/receive transaction histories.
• Faisal Islamic Bank (Sudan) — bank-account and payment records behind its mobile app.
• Ocash — Omdurman National Bank's wallet, holding balances and payment activity.
• Bede Sudan — a Sudan-focused finance app with wallet and payment surfaces.
• Baladna Digital — digital banking records for the Sudanese market.
• AlNile Sahil — payment and transfer data in the same regional ecosystem.
• RittalPay — a mobile wallet that operates without requiring a formal bank account.

Questions an integrator tends to ask

Can you separate the local Sudan transfers from the international corridors in the data?

Yes. Each transfer record Soonapay holds carries a currency code and counterparty detail, so the corridor is derivable per transaction rather than guessed. We tag local versus cross-border on the way into the normalized schema, keeping the original currency (for example SDG against USD or SAR) alongside any FX context so reconciliation stays exact.

How do you handle the Arabic and English fields Soonapay returns?

The app ships bilingual, so payload labels and numerals arrive in both Arabic and English. Our parser normalizes Arabic-Indic digits to ASCII, handles right-to-left strings, and maps both label sets to one canonical field name, so downstream code never has to branch on language.

Do the virtual Visa card transactions come through, or only the card metadata?

Both, to the extent the account surfaces them. Card lifecycle state — issuance, status, masked identifier and limits — maps cleanly, and per-card transaction lines are pulled where the account exposes a card-activity view. We confirm which of the two is present during the build and document exactly what each card record contains.

Which regulator covers a Sudan-based wallet like Soonapay?

E-money and mobile payment provision in Sudan sits under the Central Bank of Sudan, which licenses providers and oversees the retail payment switch operated by Electronic Banking Services. Sudan has no comprehensive standalone data-protection statute, so the dependable basis for an integration is the account holder's own documented authorization, recorded and scoped per pull.

Sources and review

Checked in June 2026 against the app's store listings and Sudan's payment-regulation references: the Google Play listing and Apple App Store listing for the feature set, publisher and market signals; the Central Bank of Sudan laws and regulations index for the regulatory instruments; and this overview of Sudan's payment rails for how the national switch and licensing work. Where a fact was not findable it is left stated as unknown rather than filled in.

Mapped by the OpenBanking Studio integration desk · June 2026.