Integrating a Bank Asia merchant's payment records

Every BA Micro Merchant login maps to a merchant ID issued by Bank Asia, and behind it runs a ledger of accepted payments — each one stamped with the channel it arrived on. The app takes bKash, Rocket, Nagad, SureCash, iPay and the card schemes (Visa, Mastercard, American Express, UnionPay), and surfaces real-time transaction updates plus periodic reports, per its store description. That ledger, and the settlement that follows it, is what a third party usually wants to reach.

The dependable basis for reaching that data is the merchant's own right to their account records. So the working route is interface integration: we observe how the app authenticates and how it asks Bank Asia's backend for transactions and settlements, against a merchant who has consented, and rebuild those calls as clean endpoints. The sections below name the data, the routes, and exactly what we hand over.

What sits behind a Bank Asia merchant login

These are the surfaces the app exposes to an authenticated merchant. Granularity is described as the app presents it; field-level confirmation happens during the build against a consenting account.

Routes to the data

Three apply to this app. They are not equal, and the recommendation sits at the end.

Authorized interface integration

We capture the app's authenticated session against a merchant who has consented, map the calls that fetch transactions, settlements and reports, and reproduce them as documented endpoints. Reach is wide — effectively whatever the merchant themselves can see. Effort is moderate; durability depends on Bank Asia leaving the request format stable, which we handle in maintenance. This is the route that works today for the data merchants actually ask us about.

User-consented credential access

A thinner variant: the merchant authorizes a session and we drive the same flow on their behalf for scheduled pulls, without rebuilding every call. Quick to stand up, useful when a single outlet just needs a nightly export. It shares the interface route's exposure to front-end change.

Native report export

The app already produces detailed reports. Where those export in a structured form, we wire them as a fallback feed — low effort, coarse granularity, fine for periodic statements but not for real-time reconciliation.

For most merchants the first route carries the project: it reaches the live ledger and settlement at the grain a finance team needs, and the consented-credential and report-export paths sit underneath it for scheduling and for periods when a deep pull is not warranted. Access to a consenting account is arranged with you at the start, not asked of you as a hurdle.

What lands in your repo

Each deliverable is tied to a real surface of this app, not a generic kit:

• An OpenAPI/Swagger spec covering the transaction-ledger, settlement and report calls, with the merchant-session auth documented.
• A protocol and auth-flow report: how the app establishes a session for a registered mobile number and merchant ID, how the token is carried and refreshed.
• Runnable source for the key endpoints in Python and Node.js — list transactions, fetch a settlement batch, pull a periodic report.
• A normalized schema that places bKash, Nagad, Rocket and card payments on one transaction shape so channel mix is one query.
• Automated tests against captured fixtures, plus interface documentation and data-retention guidance fitted to Bangladesh Bank's posture.

A settlement query, sketched

Illustrative shape of a normalized call over the rebuilt interface — field names and the exact auth header are confirmed during the build against a consenting merchant account.

POST /session  (merchant auth, illustrative)
  { "merchant_id": "BA-XXXXXX", "msisdn": "+8801XXXXXXXXX", "otp": "######" }
  -> { "session_token": "…", "expires_in": 900 }

GET /transactions?from=2026-06-01&to=2026-06-04
  Authorization: Bearer <session_token>
  -> [
       { "txn_id": "…", "ts": "2026-06-03T14:21:09+06:00",
         "amount": 1450.00, "currency": "BDT",
         "channel": "bkash", "rail": "mfs",
         "status": "settled", "settlement_batch": "S-20260604-07" },
       …
     ]

# token lapses at expires_in; refresh before a scheduled pull
if resp.status == 401:
    session = renew(merchant_id, refresh_creds)   # avoids silent stop

Where it gets used

• An ERP or POS pulling each outlet's takings nightly into reconciliation, split by channel and matched to the settlement batch.
• A lender underwriting a small merchant on real cash-flow from settlement history rather than a self-reported figure.
• A multi-outlet retailer consolidating Bangla QR takings across branches into one dashboard.
• An accounting SaaS auto-categorizing revenue by rail, so MFS and card income post to the right ledger accounts.

Operating inside the rules

Bank Asia is one of the banks supporting Bangla QR, Bangladesh Bank's interoperable national QR standard, which the central bank has moved to make mandatory at merchant points. Payments and settlement here sit under the Payment and Settlement Systems Act, 2024 and Bangladesh Bank's oversight. Bangladesh does not yet run a consumer-data-sharing regime the way the UK or Brazil do — the central bank has signalled open-banking guidelines and a standard API set are intended, with a working committee expected late 2025, but that is forward-looking, not current law. So the dependable legal basis we build on is the merchant's own authorization to reach their account.

We work authorized and documented: a consenting merchant, access logged, the data set minimized to what the integration needs, and an NDA where the engagement calls for one. Consent is scoped to the agreed surfaces and is revocable; when a merchant withdraws it, the pulls stop.

What we account for on this build

• The session model leans on a registered mobile number and an OTP, per the app's stated requirements, and the token is short-lived. We design the sync to renew the session before it lapses, so a scheduled pull does not silently stop returning data.
• MFS rails and the card schemes settle on different cycles. We map that per channel in the normalized schema, so a bKash payment and its later payout reconcile against the right settlement batch instead of looking unmatched.
• Multi-outlet merchants carry several QR points under one parent ID. We model the outlet-to-merchant hierarchy so consolidated and per-branch views both come out clean.
• If Bank Asia changes how the app signs or formats a request, we re-capture the flow against a consenting account and patch the client in maintenance — not a rebuild on your side.

From the merchant screens

Store screenshots we reviewed while mapping the app's surfaces. Tap to enlarge.

Sourcing and review

The data domains come from the app's own Google Play listing and store descriptions; the regulatory picture from Bangladesh reporting on open banking and the Bangla QR mandate, read June 2026. Specific sources opened:

• BA Micro Merchant on Google Play — feature set, supported channels, merchant-ID requirement.
• The Business Standard — Bangladesh's planned open-banking system and timeline.
• The Business Standard — Bangla QR mandated at merchant points.
• The Daily Star — how Bangla QR works and which banks support it.

Mapped by the OpenBanking Studio integration desk, June 2026.

The wider Bangladesh payments shelf

Same ecosystem, often integrated together into one merchant view:

• bKash — the largest MFS wallet; holds per-user balances, transfers and merchant payments.
• Nagad — Bangladesh Post Office's digital financial service; wallet balances, bill pay, merchant takings.
• Rocket — Dutch-Bangla Bank's mobile money; cash-in/out and merchant payment records.
• SureCash — payments and disbursements, including education and utility flows.
• iPay — an early online payment service with stored balances and transfers.
• Upay — UCB's wallet; send money, QR payments and bill pay.
• aamarPay — an aggregator gateway holding merchant transaction and settlement data.
• SSLCommerz — a major Bangladeshi gateway with broad rail coverage and merchant reporting.
• DMoney — a digital wallet for payments and transfers.
• TallyPay — a merchant-focused payments app in the same acceptance space.

Questions integrators ask about this app

Does the data come through Bangla QR or through the merchant account itself?

Both feed the same place. Bangla QR is the rail a customer pays over, but every accepted payment lands in the merchant's own ledger inside BA Micro Merchant, keyed to the Bank Asia merchant ID. We integrate against that authenticated merchant view, so a payment shows up whether the customer scanned with bKash, Nagad or a card app.

Can settlement records be split out by payment channel, so bKash sits apart from card takings?

Yes. Each transaction the app records carries the instrument it arrived on, and MFS rails settle on a different cycle from the card schemes. We model that timing difference in the normalized schema so channel-wise revenue and the matching payout batch line up in reconciliation.

There is talk of open banking in Bangladesh — should we wait for that route instead?

Bangladesh Bank has said it intends to publish open-banking guidelines and a standard API set, with a working committee expected late 2025 and rules targeted for 2026, per The Business Standard. None of that is in force yet, so the dependable basis today is the merchant's own consent to reach their account. We build on that now and can fold in a regulated consent flow later if and when it lands.

We already hold a Bank Asia merchant ID — what does the build look like from there?

The app name and what you want out of the data is enough to scope it; access and any compliance paperwork are arranged with you as we go. With a live merchant ID we capture the app's authenticated traffic against your consenting account, map the session and the transaction and settlement calls, then hand back runnable endpoints and docs.

The build runs in one to two weeks. You can have the runnable source delivered from $300, billed only after it is in your hands and the endpoints return what was described; or skip any upfront cost and call our hosted endpoints instead, paying only per call. Tell us the app and what you need from its data at /contact.html and we will scope it.

Mapping reviewed 2026-06-05.