Reaching bKash Merchant's payment and transaction records

A bKash merchant sees a payment, a voice prompt fires, and one line appears on the home screen with the amount, the charge, a transaction ID and a reference. That single event is the thing most integrators actually want out of this app — the moment money arrives, in a shape a till or an ERP can act on. The app then keeps a rolling 30-day ledger and emails a monthly statement on top. Our work is to take those surfaces, which a merchant already sees in their own account, and make them callable from your own systems.

The route we would run is authorized protocol analysis of the merchant app's own traffic, performed with the account holder's consent. There is no consumer open-banking consent rail in Bangladesh to ride yet, so the merchant's authorization over its own account is the firm ground here. Everything below is mapped against the surfaces the Bengali app description names directly.

Data the app holds

Each row is a surface the app exposes to the signed-in merchant. Origin is where it lives inside the app; the last column is what an integrator typically does with it once it is callable.

Routes in

Two routes genuinely fit this app, and a third sits behind them as a backstop.

Authorized protocol analysis of the app traffic

We observe and document how the signed-in merchant app talks to its backend, then rebuild the calls that back the ledger, summary and notification surfaces. Reachable: everything in the table above that the account itself can see. Effort is moderate — the login handshake (account number, OTP, PIN) and the session token need careful mapping. Durability is good for the data shapes and moderate for endpoints, which can shift when the app updates; we account for that with the re-validation step noted below. Access is arranged with the merchant during onboarding, against a consenting account, so the build runs on real surfaces.

User-consented credential access for unattended sync

For a merchant who wants their own data flowing into their own systems on a schedule, we wrap the authenticated session in a service that holds consent, refreshes the token, and pulls the ledger and statements without a person logging in each time. Reachable: the same read surfaces, on a timer. This is the right shape for reconciliation and accounting pipelines.

Native statement export as a backstop

The app already emails a monthly statement and can generate periodic statements on demand. Where a structured feed is not warranted, we parse those statements into clean records. It is lower-fidelity than the live ledger and it lags, but it is sturdy and needs little maintenance.

For most merchants the live protocol route is the one worth building, because the real value here is the instant payment event and the 30-day ledger, not a month-end file. The consented-sync wrapper is what makes that route run unattended; the statement parser is there for the cases that only need an archive.

A look at the wire

Illustrative shape of the ledger pull after the merchant session is established — field names follow what the app surfaces, and exact parameters are confirmed during the build against a consenting account.

// 1) Session established earlier: merchant no -> OTP -> PIN -> session token
// 2) Pull the rolling 30-day ledger that backs the Transactions tab

POST /merchant/v?/transactions/list
Authorization: Bearer <session_token>
Content-Type: application/json
{
  "filter": "in",            // in | out | counter, matching the app's tabs
  "from": "2026-05-20",
  "to":   "2026-06-19",
  "page": 1
}

// Normalized response we emit downstream (mapped from the app's fields)
{
  "items": [
    {
      "txn_id": "BGK7H2...",      // "Transaction ID" on the home/detail screen
      "ts": "2026-06-19T11:04:21+06:00",
      "direction": "in",
      "amount": 1450.00,
      "currency": "BDT",
      "charge": 0.00,
      "counterparty": "017XXXXXXXX",
      "reference": "invoice-3391"
    }
  ],
  "next_page": null
}

// Token refresh wired so a scheduled sync never falls back to manual login
async function ledgerSince(token, fromDate) {
  let tok = token;
  let res = await call(tok, fromDate);
  if (res.status === 401) { tok = await refresh(tok); res = await call(tok, fromDate); }
  return res.body.items;
}

What lands on your side

Tied to this app's actual surfaces, a delivery is:

• An OpenAPI/Swagger spec covering the ledger, summary, statement and notification reads as we model them.
• A protocol and auth-flow report: the merchant-number / OTP / PIN handshake, the session token, and how it refreshes.
• Runnable source for the key surfaces in Python or Node.js — the 30-day ledger pull, the summary, the statement fetch, and a notification listener.
• A webhook bridge that turns the instant/voice payment event into an HTTP POST to your endpoint.
• Automated tests against recorded responses, so a future app change shows up as a failing test, not a silent gap.
• Interface documentation and data-retention guidance keyed to a Bangladesh merchant's obligations.

Engineering we handle

Things specific to this app that we plan for so you don't have to:

• The OTP-plus-PIN session. Login runs account number, then an OTP, then a PIN. We map that chain and the token it returns, and design the sync around the token's lifetime so a scheduled pull re-authenticates cleanly rather than silently expiring mid-run.
• The 30-day ledger window. The Transactions tab only reaches back 30 days. For anyone who needs a longer history we build an incremental harness that pages the window forward on each run and accumulates records on your side, so the rolling limit never becomes a data hole.
• Front-end churn. A merchant app this active ships updates often. We keep a re-validation pass in maintenance that flags when an endpoint or field shifts after an app release, so the integration is corrected before it drifts.
• Bangla QR and counter context. Payments arrive over the interoperable Bangla QR rail and through counter and merchant-number flows, which the app tags differently (the in/out/counter filter). We preserve that tagging in the normalized feed so reconciliation can tell a counter sale from a transfer.

Access, the consenting account, and any compliance paperwork are set up together during onboarding. We work authorized, logged and data-minimized, under NDA where the merchant wants one.

Authorization & data rules

bKash sits under Bangladesh Bank, which runs the MFS Regulations 2022 and, more recently, the Payment and Settlement Systems Act 2024 that underpins the 2025 E-Money Issuer and Payment System Operator rules. A consumer-facing open-banking consent regime — the kind you'd find under UK Open Banking or India's Account Aggregator — is still being shaped here rather than in force, and the Personal Data Protection Ordinance was only approved in October 2025 with its implementing detail still to come. So we don't pretend to ride a consent rail that isn't live. The dependable basis is the merchant's own authorization over its own account, captured in writing as part of the engagement.

Practically that means: we pull only what the consenting merchant can already see, we keep consent and access records, we minimize and scope the data to what the integration needs, and we hold everything under NDA. As Bangladesh's data-protection and open-banking detail firms up, an integration built this way is straightforward to re-base onto a formal consent flow.

App screens

Reference screenshots from the listing — tap to enlarge.

Nearby wallets

Other Bangladesh mobile financial services and merchant wallets an integrator often touches alongside bKash. Named for context — a unified integration typically normalizes several of these into one feed.

• Nagad — MFS operated with Bangladesh Post Office; merchant and personal wallets with its own transaction and statement records.
• Rocket — Dutch-Bangla Bank's MFS, one of the oldest; agent, merchant and bill-pay flows.
• Upay — United Commercial Bank's wallet; send money, merchant payment and utility bills.
• mCash — Islami Bank Bangladesh's MFS; account-linked transfers and merchant acceptance.
• NexusPay — Dutch-Bangla Bank's cardless app spanning accounts, cards and wallet in one place.
• Tap — Trust Axiata Pay; consumer and merchant payments with a transaction ledger.
• SureCash — payment platform widely used for disbursements and education fees.
• Dmoney — digital payment service used for P2P and merchant settlement.

How this was checked

Surfaces were taken from the bKash Merchant Play Store listing and its Bengali feature description (latest transaction, 30-day ledger, summary, statement, limits, voice and instant notifications). Regulatory context comes from Bangladesh Bank and current Bangladesh fintech reporting, read on 2026-06-19. Sources:

• bKash Merchant on Google Play
• Bangladesh Bank — Payment Systems
• The Daily Star — What is Bangla QR
• Future Startup — State of MFS in Bangladesh, 2025

Mapped by the OpenBanking Studio integration desk, June 2026.

Questions

Can the 30-day transaction history in the bKash Merchant app be pulled programmatically?

Yes. The app's Transactions tab exposes a rolling 30-day ledger with date, amount, account number, charge, transaction ID and reference per row, plus in/out/counter filters. We map the request that backs that view and turn it into a normalized feed your accounting or reconciliation system can poll on a schedule.

Does Bangladesh have an open-banking consent regime we would ride for this bKash Merchant integration?

Not a formal one yet. Bangladesh Bank operates the MFS Regulations 2022 and the Payment and Settlement Systems Act 2024, and the Personal Data Protection Ordinance was approved in October 2025, but a consumer-facing open-banking consent framework is still being shaped. So the dependable basis for this work is the merchant's own authorization over its account, handled under NDA.

How do you handle the OTP-plus-PIN login the bKash Merchant app uses?

Onboarding goes through the merchant account number, an OTP check, then a PIN, as the app describes it. We document that handshake and the session token it issues, then build a refresh routine so the integration re-authenticates cleanly instead of forcing a manual login on every run. Credentials stay with the merchant and are accessed only with their consent.

Can the instant and voice payment notifications become a real-time webhook?

That is one of the more useful surfaces here. The app fires an instant notification, including a voice prompt, the moment a payment lands. We capture that event path and re-emit it as a webhook to your endpoint, so a POS, ERP or messaging flow reacts to a received payment within seconds rather than waiting for a batch.

One concrete delivery to set expectations: a runnable bKash Merchant ledger-and-notification integration usually moves in a 1–2 week cycle. You can take it as source-code delivery from $300 — the runnable API source plus its spec, tests and documentation, and you pay after delivery once you're satisfied with it. Or skip the build entirely and use our hosted API on a pay-per-call basis, with no upfront fee and billing only for the calls you make. Tell us the requirement and which model suits you on the contact page and we'll scope it against your merchant account.