Reaching NexusPay account, card and transfer records

One app standing in front of four payment rails at once is the thing that makes NexusPay worth integrating. Dutch-Bangla Bank built it as the country's first fully cardless wallet, and per its Play Store listing and the bank's own NexusPay site it carries Nexus cards, Rocket mobile banking, Agent Banking and external Visa or Mastercard cards together, with QR and NFC payments across the DBBL network. A team that wants one consistent view of balances, statements and transfers from any of those rails is really asking to read what NexusPay already aggregates behind a single login.

The bottom line for an integrator: the richest, most queryable surfaces are the DBBL-side statement and transaction views, while the bridged cards and wallets give you balances, payment status and card tokens. Our working route is authorized protocol analysis of the app's own traffic, run against a consenting account, so the integration reads the same data the account holder sees and normalizes it across rails.

What sits behind a NexusPay login

Each row below is a surface the app actually exposes to its own user, mapped to where it comes from and what an integrator typically does with it.

Routes into NexusPay's data

Three approaches genuinely apply to this app. They are not mutually exclusive; a real build usually combines two.

Authorized protocol analysis of the app session

We observe and reconstruct the traffic the app makes on behalf of a consenting account: the login and token exchange, the card list, the DBBL statement calls, the transfer and QR flows. What becomes reachable is everything the user can see in the app. Effort is moderate and front-loaded; durability is good as long as a maintenance check tracks releases. Onboarding here is arranged with you during the engagement, against a test account or a consenting live account.

User-consented credential access

For a product where the end user is present, the integration drives the app's own auth with the user's consent and PIN, then reads their cards, statement and transactions. Reachable scope matches the account's own permissions; durability tracks the app's auth model. This is the cleanest fit when you are building something the NexusPay holder themselves opts into.

Native export as a fallback

Where a record is only ever shown on screen, we capture the statement and transaction views directly and structure them. It is narrower and slower than the session route, but it is dependable for the DBBL mini statement and last-transactions views and needs nothing beyond what the user can already display.

For NexusPay specifically we lead with authorized protocol analysis and fold in user-consented access wherever the end user is in the loop, because that pairing is what lets one feed speak for the Nexus card, the Rocket wallet and the Agent Banking line without three separate integrations. Native export stays in reserve for the DBBL-only statement screens.

What you receive

The deliverable is a working integration for the surfaces above, not a report about them.

• An OpenAPI/Swagger specification covering the card list, DBBL statement, transaction history and transfer surfaces as we model them.
• A protocol and auth-flow report: the login, token issue and refresh, and the session/cookie chain as observed during the build.
• Runnable source for the key endpoints in Python or Node.js, with the rail-tagging that keeps Rocket, Nexus and Agent Banking records distinct.
• Automated tests against recorded fixtures so a changed field surfaces before it reaches your data.
• Interface documentation an in-house engineer can extend without us.
• Data-retention and authorization guidance matched to how the account access was granted.

A statement pull, sketched

Illustrative only and confirmed against the live surfaces during a build — field names below stand in for what protocol analysis pins down for your account.

# Authorized session against a consenting NexusPay account.
# Field names are illustrative; the build confirms the real contract.

session = nexus.login(msisdn=USER_PHONE, pin=USER_PIN)   # -> access token + session ref
token   = session["access_token"]

# DBBL mini statement is account-scoped; non-DBBL cards return tokens, not history.
cards = nexus.get("/cards", token=token)                 # list, each tagged by rail
dbbl  = [c for c in cards if c["rail"] == "DBBL_NEXUS"]

stmt = nexus.get(f"/accounts/{dbbl[0]['acct_ref']}/mini-statement", token=token)

for line in stmt["entries"]:
    yield {
        "rail":       "DBBL_NEXUS",
        "posted_at":  line["txn_time"],      # ISO normalized on our side
        "amount":     line["amount"],
        "direction":  line["dr_cr"],         # DEBIT | CREDIT
        "settle_ref": line.get("npsb_ref"),  # present for Bangla QR / NPSB legs
        "narrative":  line["particulars"],
    }

# Errors: token expiry -> re-auth; account not DBBL -> mark balance-only, no history.

Where it plugs in

• A DBBL merchant reconciling Bangla QR takings against their point-of-sale, keyed on the NPSB settlement reference.
• An SME accounting tool syncing a business owner's NexusPay transaction history into its ledger nightly.
• A lender reading consented statement history to support an underwriting decision.
• A treasury view that unifies a Rocket balance and a Nexus card balance behind one number.

Authorization and Bangladesh Bank's timeline

The dependable legal footing here is straightforward: the account holder authorizing access to their own data. That is what every route above is built on. Bangladesh has no in-force open banking standard yet; reporting indicates Bangladesh Bank intends to publish unified API guidelines on a mid-2026 horizon, with a working committee expected first. We do not build against that standard as though it already governs, because it does not — but the integration is structured so it can re-point to a sanctioned API once one exists. Meanwhile the payment side already runs on shared rails: Bangla QR over NPSB, with instant settlement approved in December 2025, which is why settlement references matter in the data model. We work authorized, log access, keep consent records, minimize what is stored, and sign an NDA where the engagement needs one.

Engineering notes for this build

Two things about NexusPay shape how we build, and we plan for both rather than leaving them to surprise the integration.

• Multi-rail record shapes. Because the app fronts Nexus cards, Rocket, Agent Banking and external scheme cards, the same word — a "transaction" — means a different record on each rail. We tag every normalized entry with its source rail so a Rocket wallet movement never silently merges with a Nexus card debit.
• DBBL-only statement scope. The mini statement and last-transactions views exist only for Dutch-Bangla Bank accounts. We scope the history feed to those surfaces and mark non-DBBL cards as token-and-balance only, so downstream code never expects history the app does not show.
• Settlement timing. With Bangla QR settlement now instant but still routed through NPSB, a payment and its settlement line can land out of order. We reconcile on the settlement reference and merchant id, not on arrival sequence.
• Release drift. The app moves between versions (APK mirrors list a 2.x line), so a maintenance check rides each release and flags a changed field for us before it reaches your feed.

Screens we mapped

Public store screenshots we reviewed while sketching the surfaces above. Tap to enlarge.

The wider Bangladeshi wallet field

NexusPay shares its users with a crowded set of wallets and mobile financial services. When a product needs more than one of them, the same normalization approach carries across — each holds comparable per-user records behind its own login.

• bKash — the market-leading P2P wallet, holding balances, send-money history and merchant payments for a very large user base.
• Nagad — the Bangladesh Post Office-linked service, with wallet balances, transfers and bill payments.
• Rocket — Dutch-Bangla Bank's own mobile banking service, which NexusPay also bridges; account and transfer records.
• Upay — UCB's wallet, covering cash-in/out, send money, QR payments and bills.
• CellFin — Islami Bank's app combining accounts, payments and investment records.
• Tap (Trust Axiata Pay) — Trust Bank and Axiata's wallet for transfers, bills and recharges.
• TallyPay — a B2B and B2C payment automation platform aimed at SMEs.
• OK Wallet — One Bank's digital payment service.
• iPay — a digital wallet for transfers, payments and bills.

Sources and how this was put together

The surfaces and rails described here were checked in June 2026 against the app's public store listings, the bank's own NexusPay pages, and recent reporting on Bangladesh's payment infrastructure. Primary references:

• Dutch-Bangla Bank — NexusPay home
• NexusPay on Google Play (com.dbbl.nexus.pay)
• The Daily Star — Bangla QR adoption mandate and NPSB routing
• The Business Standard — Bangladesh open banking plans

Mapped by the OpenBanking Studio integration desk · June 2026.

Questions integrators ask about NexusPay

Which records are DBBL-only versus available across every linked card?

In the app, the mini statement and the last-transactions statement are limited to Dutch-Bangla Bank accounts. Cards from other schemes loaded into the wallet behave as balance and payment instruments rather than as history sources, so we build the statement feed against the DBBL surfaces and treat the rest as token and balance lookups.

Does NexusPay's Bangla QR settlement timing affect reconciliation code?

It does. Bangla QR routes through NPSB and Bangladesh Bank approved instant settlement for it in December 2025, so a merchant payment and its settlement line can still arrive separately. We key reconciliation on the settlement reference and the QR merchant id rather than on arrival order.

How does NexusPay bridging Rocket, Nexus and Agent Banking change the data model?

NexusPay sits in front of several rails at once: Nexus cards, Rocket mobile banking, Agent Banking and external Visa or Mastercard cards. Each rail describes a transaction differently, so the normalized schema we ship tags every record with its source rail and keeps a Rocket wallet movement distinct from a Nexus card debit.

What is the regulatory basis given that Bangladesh has no open banking standard yet?

The dependable basis is the account holder's own authorization for their own data. Bangladesh Bank has signalled unified open banking API guidelines, with reporting pointing to a mid-2026 target, but that standard is not in force today, so we do not build against it as if it were. We can re-point the integration to it once it lands.

Source-code delivery starts at $300 — runnable API source for the NexusPay surfaces above, the protocol and auth-flow report, tests and interface documentation, paid only after delivery once you are satisfied. The other path is to call our hosted endpoints and pay per call with no upfront fee. Either way the cycle is one to two weeks. Tell us the data you need from NexusPay and we will scope it; start the conversation here.