Reaching MoMo account and transaction data through Vietnam's Open API regime

The authorized way into MoMo's data

By Decision Lab's Q2 2024 survey MoMo was the e-wallet 62% of Vietnamese respondents used most, and behind that reach sits a dense set of per-user records: a wallet balance, a running transaction ledger, links to most large Vietnamese banks, plus savings, loan and BNPL positions held with partner institutions. Two authorized routes reach it, and which one carries more of the data depends on whether you want the wallet's own surfaces or the bank side of a user's flows.

The bank-linked half has a regulated path. Circular 64/2024/TT-NHNN, in force since 1 March 2025 per the official implementation notice, defines consent-based bank Open APIs in Vietnam. The wallet-native half — MoMo's own QR pays, bill payments and the balance itself — is reached by documented protocol analysis of the app's authenticated traffic, run under the account holder's consent. We would build on the consent-based bank channel where a flow touches a linked bank, and fall back to protocol analysis for everything that lives only inside the wallet. For a single consenting user, the two combine into one normalized feed.

What sits behind a MoMo login

Each row below is a surface the app exposes to its own user. The integration maps it to where it originates, how fine-grained it is, and the typical use a third party puts it to.

What lands at the end of the build

The output is working software for the surfaces above, not a report. For a typical MoMo engagement that means:

• An OpenAPI 3.1 specification covering the endpoints we implement — balance read, transaction list with pagination, linked-bank enumeration, bill-history pull.
• A protocol and auth-flow report: how the session token is obtained and refreshed, how the QR/VietQR payment path is structured, and where the bank-link handshake sits.
• Runnable source for the key calls in Python and Node.js, with a normalized transaction model so MoMo records line up with records from a bank or another wallet.
• Automated tests against captured fixtures, plus a replay harness so a maintenance run can confirm parsing still matches live responses.
• Interface documentation and data-retention guidance — what is logged, what is minimized, how consent is recorded and revoked.

How a transaction pull looks

Illustrative, and confirmed against live behavior during the build rather than promised in advance. After a consented session token is held, the wallet ledger is paged and each row normalized:

POST /auth/session/refresh
  { "device_id": "<bound>", "refresh_token": "<consented>" }
  -> 200 { "access_token": "...", "expires_in": 900 }

GET /wallet/transactions?from=2026-05-01&cursor=0&limit=50
  Authorization: Bearer <access_token>
  -> 200 {
       "items": [
         { "id": "...", "ts": "2026-05-14T09:02:11+07:00",
           "amount": -120000, "currency": "VND",
           "counterparty": { "phone_masked": "09xx xxx 318" },
           "funding": "wallet", "type": "qr_pay" }
       ],
       "next_cursor": 50 }

# normalize -> { tx_id, booked_at, amount_minor, direction,
#                counterparty_ref, source: "momo" }
# 401 -> refresh once, then retry; repeated 401 surfaces a
#        consent-expired event rather than a silent gap.

Field names are settled during the build against captured traffic; the shape above shows the normalization target, not a published contract.

Consent and the rules that bind it

Two Vietnamese frameworks govern this work. Circular 64/2024/TT-NHNN puts explicit customer consent at the centre of bank Open API sharing and rolls access out in phases — information query first, then consent-based access, then payment initiation. Personal data sits under Law 91/2025/QH15, effective 1 January 2026, which raised Vietnam's rules from the earlier Decree 13/2023 to statutory level; consent under it must be voluntary, specific, and recorded in a form that can be reproduced in writing.

In practice that shapes the integration: access is scoped to the data domains a project actually needs, consent carries an expiry and a revocation path that the sync respects, and every access is logged against the consent record. Where a deployment handles data for others, we work under NDA and minimize what is stored. The dependable basis for reaching a user's MoMo data is that user's own authorization; the Open API channel is the regulated way to exercise it on the bank side.

Things we account for in a MoMo build

A few specifics drive design decisions on this app:

• The wallet balance and the linked bank are separate origins. A top-up moves money from a bank account into the capped wallet, so we model two ledgers and a transfer between them rather than one balance — otherwise reconciliation double-counts. The cap (reported around VND 100 million under SBV rules) is held as a validation bound, not a constant baked into logic.
• Savings, investment and BNPL surfaces sit behind partner institutions — fund managers, and lenders such as TPBank — not MoMo's own core. We put each partner behind its own adapter so a change on one partner's side does not ripple into the wallet parsing, and we add a re-validation step in maintenance to catch those early.
• The app spans phone and Wear OS, where the watch generates a QR/Barcode after a PIN and syncs back to the phone. We treat the phone session as the source of record and the watch as a derived view, so duplicate events from the two surfaces collapse to one.

Access — a consenting account or a sandbox, plus any authorizations — is arranged with you during onboarding; it is part of how the project runs, not something to settle before we begin.

How an engagement is priced

Source for the key MoMo endpoints lands inside a 1–2 week cycle, and the first model bills only after it runs: source-code delivery starts at $300, paid once you have the runnable integration in hand and are satisfied it works. The second model is a hosted API — you call our endpoints for MoMo data and pay per call, with no upfront fee. You give us the app name and what you need from its data; we handle the route, the build and the access arrangements. Start the conversation at /contact.html.

Keeping the feed honest

MoMo's app front end and its partner surfaces move, so the integration ships with a replay harness over captured fixtures. A scheduled run compares parsing against live responses; when a field shifts or a partner ledger changes shape, the maintenance pass flags it instead of letting rows go missing. Consent expiry is surfaced as an explicit event, not a silent empty result.

What was checked, and where

Compiled from the app's own Play Store description and four primary sources opened in June 2026: the State Bank's Open API implementation notice, an Open API regulatory analysis, Vietnam's personal-data law coverage, and a profile of MoMo's super-app scope. Concrete figures are attributed where stated and otherwise left out.

• Circular 64/2024/TT-NHNN — Open API implementation from 1 March 2025
• Open Banking Vietnam — analysis of the new Open API rules
• Vietnam's Law on Personal Data Protection (Law 91/2025/QH15)
• MoMo's super-app and financial-service scope

OpenBanking Studio · integration desk mapping, June 2026.

Where MoMo sits among Vietnamese wallets

The same integration pattern applies across the local e-wallet field, and a unified feed usually spans several of these at once:

• ZaloPay — wallet tied to the Zalo messenger; holds transfers, QR pays and bill records per user.
• VNPay — runs the interoperable VNPay-QR network; transaction and merchant-settlement data behind linked accounts.
• ShopeePay — marketplace-linked wallet; order-adjacent payment and refund history.
• Viettel Money — telco-backed wallet with strong rural reach; mobile money balances and transfers.
• Moca (GrabPay) — payment layer inside Grab; ride and food payment events.
• Payoo — payment gateway and bill-collection platform; biller and settlement records.
• SmartPay — merchant-focused wallet; small-business transaction ledgers.

Interface evidence

Store screenshots, useful for confirming which surfaces a user sees. Select to enlarge.

Questions integrators ask about MoMo

Can MoMo transaction history be pulled with the same fields a user sees in the app?

Yes. The in-app history records the counterparty phone number, timestamp, amount and the funding account used; our integration normalizes those into dated transaction records with stable identifiers, so a downstream ledger keeps the same fields the user sees on screen.

Does Vietnam's Circular 64 change how MoMo-linked data can be reached?

It opens a consent-based path. Circular 64/2024/TT-NHNN took effect on 1 March 2025 and phases bank Open APIs in as information query, consent-based access, then payment initiation. Because MoMo links to most large Vietnamese banks, the bank side of a user's flows can be reached through that consented channel, with the wallet-native surfaces covered by authorized protocol analysis.

How do you handle MoMo's bank linkage and the VND 100 million wallet cap?

We model the wallet balance and the linked-bank funding source as separate data origins, because a top-up crosses from a bank account into the capped wallet. The balance ceiling (reported at VND 100 million per SBV rules) is treated as a validation bound in the schema rather than a hard number we assert, so reconciliation logic does not break when limits change.

Which MoMo surfaces are hardest to keep stable over time?

The savings, investment and BNPL ledgers, since those sit behind partner institutions such as fund managers and lending banks rather than MoMo's own core. We isolate each partner surface behind its own adapter and add a re-validation pass to maintenance so a partner-side change is caught early instead of silently dropping rows.