Getting transaction data out of KPay's wallet

Every franc in a KPay balance is electronic money that Bridge Bank Senegal issues, while Quickpay — a subsidiary of the EDK Group — runs the wallet platform behind it, per the operator's own about page. That split matters for an integrator: the institution of record is a licensed bank, the technical surface you actually talk to is Quickpay's customer app. The data you want — a customer's running ledger of deposits, transfers, withdrawals and payments — sits server-side behind that app's login, in CFA francs. There is no public statutory feed for it in Senegal. The reachable, authorized path is the wallet interface itself, with the account holder's consent.

The honest bottom line up top: KPay's per-user ledger is real, structured and worth syncing, but it lives behind an authenticated mobile wallet, not a published data service. So a KPay integration is built mostly from the wallet interface a consenting customer already uses, and normalized into something your systems can query. Below is what's inside, the routes that genuinely apply, and what changes hands at the end.

How we'd reach KPay's data

Three routes apply to this wallet. None of them depends on KPay publishing anything.

1 · Authorized interface integration of the customer app

We map the traffic the KPay customer app makes to Quickpay's platform — login, token refresh, balance, the transaction list, transfer and payment calls — and rebuild those calls as a clean, documented client, under the account holder's authorization. Reachable here: balance, the full local ledger, bill and merchant records, and the status of regional and international transfers. Effort is moderate; durability tracks app releases, so a recapture step is part of upkeep. We set up a consenting test account and the capture tooling during onboarding.

2 · User-consented session access

Where the customer would rather authorize us inside their own session, we operate within their KPay credentials to pull and normalize exactly what they can see. This reaches everything in the customer view and is bounded by the OTP and session lifecycle. It suits one-off or low-volume pulls — a single business exporting its own statement, say.

3 · The PI-SPI rail, for live transfer status

For real-time transfer initiation and status, the BCEAO's interoperable instant-payment switch (PI-SPI), in force since 30 September 2025, is the regulated rail that links wallets, banks and microfinance across UEMOA. It is relevant once Quickpay is connected to the switch, and it answers "did this transfer land" better than it answers "what is this customer's six-month history".

For KPay specifically, the ledger you actually want — each depot, transfert and retrait with its fee line in XOF — only exists behind the authenticated wallet, so a build leans on route 1, uses route 2 where a single account holder is the subject, and treats PI-SPI as the piece that gives you live transfer state once the switch is wired in. We would say so plainly in the scoping call rather than sell you a route that doesn't fit your volume.

What the wallet actually holds

Mapped to how the app names things. Granularity is what a consented pull can resolve per record.

What you get at handover

A KPay engagement is a set of files, not a slide deck. For this wallet that means:

• An OpenAPI/Swagger spec covering the surfaces above — balance, ledger pagination, bill, merchant and transfer reads.
• A protocol and auth-flow report: the phone-plus-PIN login, bearer and refresh tokens, and the SMS-OTP step-up that guards sensitive actions.
• Runnable source for the key endpoints, in Python or Node.js, with the XOF and fee normalization built in.
• Automated tests against a consenting account, including the token-refresh and OTP-challenge paths.
• Interface documentation a new engineer can follow, plus retention and consent-record guidance fit for the CDP.

Each piece is tied to a real KPay surface. We do not ship a generic wallet stub with the name changed.

Sketch: pulling a customer's history

Illustrative shape — endpoint names and fields are confirmed during the build, not published by KPay. It shows the login, the OTP step-up, and a paginated ledger read with the fee line that matches KPay's published pricing (0% deposit, 0.7% transfer, 0% withdrawal).

# Authenticate: phone (MSISDN) + PIN -> short-lived bearer + refresh
POST /auth/login
  { "msisdn": "2217XXXXXXXX", "pin": "****" }
  -> { "access_token": "...", "refresh_token": "...", "expires_in": 900 }

# Sensitive reads/writes trigger an SMS OTP challenge (step-up)
POST /auth/otp/verify   { "challenge_id": "...", "code": "######" }

GET /wallet/balance     Authorization: Bearer <access_token>
  -> { "currency": "XOF", "available": 124500 }

GET /wallet/transactions?from=2026-05-01&page=1
  -> { "items": [
        { "id": "TX...", "type": "transfert",       "amount": -5000, "fee": 35,
          "counterparty": "+2217...", "channel": "wallet_to_wallet",
          "status": "success", "ts": "2026-05-14T09:21:03Z" },
        { "id": "TX...", "type": "depot",            "amount": 50000, "fee": 0  },
        { "id": "TX...", "type": "paiement_facture", "biller": "SENELEC",
          "amount": -8200, "status": "success" }
      ],
      "next_page": 2 }

# Handling: refresh on 401 before re-login; back off on OTP throttling;
# carry the international/CEDEAO FX leg as its own field, not folded into amount.
      

What we plan around in the build

Concrete things this wallet forces, and how we handle each — not a list you have to clear first.

• XOF and the fee line. Amounts are CFA francs with no minor units, and the transfer fee (0.7% per KPay's pricing) posts as its own movement. We normalize both so a customer's totals reconcile to the franc, and keep deposit and withdrawal at zero fee where the app does.
• OTP and session lifecycle. Login is phone plus PIN with SMS-OTP step-up on sensitive actions, and bearer tokens expire fast. We design the sync around that refresh window so a long pull does not silently die mid-run, and we handle the OTP challenge as a first-class step rather than a surprise.
• Three clients, one platform. The customer app (sn.kpay), KPay Agent (sn.kpay.agent) and KPay Marchand (sn.kpay.merchant) hit the same backend with different views. We scope which client's traffic a dataset actually needs, so agent float and merchant settlement data are captured from the right surface, not guessed from the consumer app.
• Release churn. When Quickpay ships a new app version, endpoints and field names can move. Maintenance includes a recapture pass that re-checks the mapped flows against the current release, so the client keeps working after an update instead of breaking quietly.

Operating inside Senegal's rules

KPay sits inside the UEMOA regulatory frame, and the two bodies that matter are clear. The BCEAO licenses electronic-money issuers under Instruction 008-05-2015 — that is the regime under which Bridge Bank issues KPay's e-money. Personal data is governed by Senegal's Commission de Protection des Données Personnelles (CDP) under Loi 2008-12 of 25 January 2008, which is consent-based and expects processing to be declared and minimized. There is no UK- or Brazil-style statutory account-information mandate here, so we do not pretend to ride one. The dependable basis is the account holder's own consent: scoped to the data the project needs, revocable, and recorded. We work authorized, log access, minimize what we hold, and sign an NDA where the client wants one. The PI-SPI switch adds a regulated interoperability rail for live transfers, but it does not replace consent as the basis for reading a customer's history.

What teams build on this

• A Dakar lender scoring a borrower's cash flow from their consented KPay ledger, instead of a paper statement.
• A merchant aggregator reconciling KPay QR settlements against its own point-of-sale records each night.
• A remittance startup mirroring CEDEAO and international transfer status end-to-end for its support team.
• A bookkeeping tool exporting a small business's KPay activity straight into XOF accounts.

Screens we worked from

The app's own store screenshots, used to map surfaces. Tap to enlarge.

The rest of Senegal's wallet field

Where KPay sits among the apps a Senegalese user is likely to also have. Same category, named for context — a unified integration usually has to speak to more than one.

• Wave — the low-fee disruptor; holds wallet balances and P2P history for a large share of Senegalese users.
• Orange Money — the telco incumbent; deep balance, transfer and bill-payment records tied to Orange lines.
• Free Money — Free's wallet; transfers, bill pay and merchant transactions for its subscriber base.
• Wizall Money — multi-country account (Senegal, Côte d'Ivoire, Burkina, Mali) with transfers, top-ups and bill payments.
• PayDunya / MyDunya — a payments layer and multi-wallet app aggregating Wave, Orange Money, Free Money and others.
• E-Money (Expresso) — the Expresso telco wallet; balances and transactional flows for its users.
• Maxit — an Orange super-app bundling money and telco services in one account view.
• Sendwave — inbound remittance into Senegalese wallets; holds transfer records on the sending side.

What we checked, and when

This mapping was put together in June 2026 from the operator's own pages, the store listing, and the regional regulators. We read KPay's about page for the Quickpay/Bridge Bank structure, the Play listing for the service set, the BCEAO instruction for the e-money regime, and the CDP for the data basis. Primary sources:

• KPay — À propos (operator and e-money issuer)
• KPay - Transfert d'Argent on Google Play (service set)
• BCEAO Instruction 008-05-2015 on electronic money
• CDP Senegal — Loi 2008-12 on personal data

Mapped by the OpenBanking Studio integration desk, June 2026.

Questions integrators ask about KPay

Does KPay's data sit behind one customer account, or spread across the agent network too?

The per-user ledger — balance, every depot, transfert and retrait, bill and merchant payment — is held server-side by Quickpay's platform on electronic money that Bridge Bank Senegal issues, and reached through the authenticated customer app (sn.kpay). Agent and merchant flows live in separate clients, KPay Agent and KPay Marchand, so we scope which surface a dataset needs before capture.

Is there a Senegalese open-banking rule we'd lean on, the way UK work leans on the FCA's?

No. Senegal and the wider UEMOA zone have no statutory account-information mandate equivalent to UK Open Banking or Open Finance Brasil. The dependable basis for a KPay integration is the account holder's own consent, handled under the CDP's Loi 2008-12 on personal data, inside the BCEAO electronic-money framework that licenses issuers like Bridge Bank.

Does the new BCEAO instant-payment switch change how we'd integrate KPay?

The BCEAO's interoperable instant-payment platform (PI-SPI), live since 30 September 2025, connects banks, electronic-money issuers and microfinance across the Union, so it matters for live transfer status once Quickpay is wired to the switch. The historical ledger you want for a customer still comes from the wallet interface, not the switch.

Can you mirror KPay's CEDEAO and international transfer statuses, not only balances?

Yes. International and regional CEDEAO transfers are first-class surfaces in the app, each carrying a corridor, recipient, an FX leg and a status that moves over time. We map those alongside balance and the local depot/transfert/retrait history, and normalize the XOF amounts and the fee line so a downstream system reconciles cleanly.

Putting KPay on your roadmap

Most KPay jobs run on a one-to-two-week cycle. You can take it as runnable source — the wallet client, the OpenAPI spec, tests and interface docs — from $300, billed only after it is handed over and you have checked it works; or skip the code entirely and call our hosted endpoints, paying per call with nothing up front. Tell us the app and what you need from its data on our contact page, and we will scope the route that fits your volume.