Reaching the wallet ledger inside upay

Every upay account carries something most Bangladeshi wallets do not surface so plainly: a multi-source ledger that splits incoming funds into Salary, Disbursement and Remittance streams, described in the app as "Your Own Wallet". That structure, plus the everyday flow of send-money, cash-out, bill payment and QR merchant transactions, is the data a partner usually wants to read. This brief maps where that data lives in the app and how we reach it under the account holder's authorization.

upay is the wallet brand of UCB Fintech, and it runs as a regulated mobile financial service under Bangladesh Bank. The route we take here is authorized interface integration: we analyze the app's own session traffic with a consenting account, then build a clean read interface on top of it. No regime in Bangladesh yet offers a consumer-consent open-banking rail to plug into, so the consented session is the dependable basis, and that is what the work is designed around.

What upay actually holds

The rows below come from the app's described feature set. Granularity reflects what a single authorized session can read, not a bulk feed.

Routes to the data

Two routes fit upay, plus a fallback. We would run the authorized session integration as the working path here, because it reaches the full in-app surface — the multi-source ledger and merchant tags included — and because Bangladesh has no consumer-facing open-banking consent rail to lean on instead. The consented-credential variant is for cases where a partner already holds the user relationship and wants the access framed around that.

Authorized interface integration (protocol analysis)

We map the app's session: login, device registration, token issuance and refresh, then the calls behind the wallet, statement, bill and QR screens. Reachable: effectively everything the app itself shows a logged-in user. Effort is moderate and the durability question is the app front end changing, which we account for in maintenance. Access is arranged with you during onboarding — the build runs against a consenting account.

User-consented credential access

Where you own the customer relationship, the integration runs under each user's explicit consent and device binding. Reachable: that user's own records. This route keeps the consent trail tight and is the cleanest fit for a product feature serving your own users.

Native export (fallback)

Where the app or a statement view offers a download or shareable record, we parse it as a low-effort supplement — useful for backfill, thin on real-time freshness. We treat it as a fill-in, not the main feed.

A call from the build

Illustrative shape, confirmed against a live session during the build — field names are normalized in delivery, not guaranteed to match upay's internal wire format.

POST /auth/token/refresh
Headers: X-Device-Id: <registered-device>   # upay binds to one device
Body:    { "refresh_token": "<rt>" }
-> 200   { "access_token": "<at>", "expires_in": 600 }

GET /wallet/ledger?source=remittance&from=2026-05-01
Headers: Authorization: Bearer <at>
-> 200
{
  "source": "remittance",
  "balance": { "amount": "12450.00", "currency": "BDT" },
  "entries": [
    { "id": "txn_8841", "type": "send_money", "counterparty": "01XXXXXXXXX",
      "amount": "-500.00", "ts": "2026-05-03T09:14:00+06:00" },
    { "id": "txn_8842", "type": "qr_merchant", "merchant": "Chaldal",
      "amount": "-1280.00", "ts": "2026-05-03T18:02:00+06:00" }
  ]
}
# error path: 401 -> token expired, re-run refresh; 423 -> device not registered

Amounts arrive in BDT; where the app renders Bengali numerals we convert to ASCII digits in the normalized output.

What lands in your hands

Each item is tied to upay's real surfaces, not a generic kit.

• An OpenAPI/Swagger spec covering wallet ledger (by source), transfer history, bill payments, recharge and QR merchant reads.
• A protocol and auth-flow report: the device-registration, token-issuance and refresh chain, with the 401/423 handling shown above.
• Runnable source for the core endpoints in Python and Node.js, including the device-bound session handling.
• Automated tests against the mapped responses, including the Bengali-numeral and multi-source split cases.
• Interface documentation plus data-retention and consent-logging guidance scoped to Bangladesh Bank's MFS rules.

Consent and the rules that apply

upay sits under Bangladesh Bank's Payment Systems Department and the Bangladesh Mobile Financial Services (MFS) Regulations, 2018. There is no consumer-consent open-banking statute in force in Bangladesh — Binimoy, the interoperable platform Bangladesh Bank backed, was suspended after 2024, and Bangla QR remains a merchant-payment standard rather than a data-sharing rail. So the basis we rely on is direct: the account holder authorizes access to their own data. We work from that authorization, keep consent records with scope and expiry, bind access to the user's registered device as upay itself does, and minimize the fields read to what your use case needs. Bangladesh's general data-protection statute is still in draft, so we apply data-minimization and NDA terms as standing practice rather than relying on a finalized law.

Things we handle on this app specifically

• Single-device binding. upay restricts an account to its registered device. We design the session to operate from one consented device and handle the registration plus OTP step inside the build, so the integration mirrors an authorized session instead of fighting the binding.
• Multi-source wallet split. The Salary / Disbursement / Remittance structure is core to upay. We model each source as its own ledger stream so balances and entries stay attributed to their origin rather than collapsing into one total.
• Bilingual, Bengali-numeral surfaces. The app runs in Bangla or English and can render Bengali digits and biller names. We normalize those into consistent UTF-8 fields and ASCII numerics so downstream systems get clean values.
• Front-end change. MFS apps update often. We wire a re-validation step into maintenance so a screen or flow change is caught and patched rather than silently breaking the feed.

Where this gets used

• An accounting tool pulling a merchant's upay receipts and separating QR settlements from P2P transfers.
• A payroll or remittance partner reading the Remittance and Salary wallet sources to confirm disbursement landed.
• A personal-finance app categorizing a consenting user's DESCO, Titas and WASA bill payments alongside recharge spend.
• A reconciliation service matching add-money events from banks and cards against expected settlement.

Pricing

The full upay interface — multi-source ledger, transfers, bills, QR — is the scope a typical build covers, and delivery comes in either form. Source-code delivery starts at $300: you get the runnable API source, spec, tests and documentation, and you pay after delivery once you are satisfied with it. Or use the hosted API and pay per call, with no upfront fee. A build runs on a 1–2 week cycle. Tell us the app and what you need from its data, and we arrange access and compliance with you — start at /contact.html.

How this was checked

Mapped against upay's Play Store description and feature list, Bangladesh Bank's MFS regulation circular, the Bangla QR background reporting, and UCB's own page for the co-branded card, in June 2026. Primary sources:

• upay on Google Play
• Bangladesh Bank — Mobile Financial Services (MFS) Regulations
• The Daily Star — what Bangla QR is
• UCB — UPAY-UCB co-branded card

Reviewed June 2026 by the OpenBanking Studio integration desk.

Screens referenced

Similar apps in the same space

If a unified integration across Bangladeshi wallets is the goal, these are the neighbours. Names are listed for context only.

• bKash — the largest MFS in the country, holding wallet balances, send-money and cash-out records for tens of millions of users.
• Nagad — Post Office-backed wallet with similar transfer, bill and recharge ledgers.
• Rocket — DBBL's mobile banking service, holding account-linked transaction history.
• SureCash — Rupali Bank-linked MFS, strong in disbursement and education payments.
• mCash — Islami Bank's wallet, with transfer and bill-payment records.
• Tap — Trust Axiata's wallet, holding wallet and merchant-payment data.
• OK Wallet — ONE Bank's MFS offering, with comparable transaction surfaces.
• UCB One — UCB's own retail banking app, sitting alongside upay in the same group.

Questions integrators ask

Can the export keep upay's Salary, Disbursement and Remittance wallet sources separate?

Yes. upay's multi-source wallet is its distinctive structure, and we model each fund source as its own ledger stream so salary, disbursement and remittance balances and entries do not get merged into one undifferentiated total.

How do you work with upay's single-registered-device restriction?

upay binds an account to one registered device. We design the integration to run from a single consented device session, handling the device registration and OTP step as part of the build rather than working around it, so the data flow mirrors a legitimate authorized session.

Which Bangladesh regulator and rules sit behind this integration?

upay operates under Bangladesh Bank's Payment Systems Department and the Bangladesh Mobile Financial Services (MFS) Regulations, 2018. The dependable basis we build on is the account holder's own authorization to access their data; we keep consent records and minimize the fields pulled.

Do you separate Bangla QR merchant payments from person-to-person send money?

Yes. Merchant payments made over Bangla QR carry a merchant tag, and we classify them distinctly from P2P send money and cash-out events so a merchant settlement view and a personal spend view can be built from the same feed.