Connecting to Viettel Money's wallet and payment records

Licensed for Mobile Money by the State Bank of Vietnam in late 2021, Viettel Money grew out of the older ViettelPay app (package com.bplus.vtpay, per its Play Store listing) into a wallet that, by its own description, bundles roughly three hundred services behind one phone-number account. For an integrator the value sits in the ledger underneath all of that: every QR payment, interbank transfer and utility bill leaves a structured, timestamped record tied to one wallet. That is the data this brief is about, and the authorized way to reach it.

The bottom line first. The records you would want are real and per-user, but they live behind a phone-number plus OTP login with device binding, not a self-serve feed you can subscribe to. The dependable way in today is authorized protocol analysis of the app's own authenticated session, run under your written consent, with the work designed to slide onto Vietnam's consent-based open API as that channel reaches wallet operators.

What the wallet actually holds

Each row below is a surface the app exposes to its own user. The granularity column reflects how the record reads inside Viettel Money, named the way the app presents it where possible.

Authorized routes to the data

Three routes apply to a wallet of this shape. Each is something we set up and run with you; access, consent records and any sandbox arrangement are handled inside the engagement.

Authorized protocol analysis of the app session

We capture and document the traffic the Viettel Money app exchanges with its backend while signed into an account you control, then rebuild the calls — balance, history, bill lookup — as clean endpoints. This reaches every surface in the table above, is the quickest to stand up, and is durable as long as we wire periodic re-validation against front-end changes into maintenance. Done under your written authorization, logged and data-minimized.

Consent-based open API under Circular 64

Vietnam's open-API regime is being switched on across the banking sector in phases. Where Viettel Money exposes a consent endpoint for account information, this is the most durable path because it is native and customer-authorized at the source. We build the consent and token handling now so the integration can adopt it the moment the wallet surface is live.

User-consented session access

For a narrower job — one account holder who wants their own data pulled out — we operate against that consenting user's session with their credentials, scoped to exactly the records they approve. Useful for single-tenant aggregation rather than fleet-wide sync.

For most buyers the protocol-analysis route is the one we would actually build first: it is the only path that reaches the full Viettel Money ledger today, and because we structure the endpoints and auth handling the same way the consent API will expect, the later switch to Circular 64 access is a swap of the transport, not a rewrite. The user-consented route is the right call only when the scope is a single, cooperating account.

Reconstructing the session

An illustrative shape of the authenticated flow we document — field names confirmed against the live session during the build, not guessed. Viettel Money logs in from a phone number and a one-time code, then carries a short-lived session token that we refresh ahead of expiry so a long-running sync does not drop mid-stream.

# 1) Phone-number + OTP login -> session token (illustrative)
POST /auth/v2/login
{ "msisdn": "84xxxxxxxxx", "otp": "######", "deviceId": "<bound-device>" }
-> 200 { "accessToken": "...", "refreshToken": "...", "expiresIn": 900 }

# 2) Pull transaction history for a window
GET /wallet/v1/transactions?from=2026-05-01&to=2026-05-31&page=0&size=50
Authorization: Bearer <accessToken>
-> 200 {
     "items": [
       { "txnId": "...", "type": "TRANSFER_OUT", "amount": 250000,
         "currency": "VND", "counterparty": "84yyyyyyyyy",
         "channel": "P2P", "status": "SUCCESS", "ts": "2026-05-14T09:21:07+07:00" }
     ],
     "page": 0, "hasNext": true
   }

# 3) Refresh before expiresIn lapses; handle 401 -> re-auth, 429 -> backoff
# Amounts are integer VND (no decimal subunit) — normalized on our side.
      

What lands in your repository

The output is a working integration for the surfaces above, not a report. For Viettel Money that means:

• An OpenAPI/Swagger specification covering the balance, transaction-history, bill-lookup and savings endpoints as we modeled them.
• A protocol and auth-flow report documenting the phone-number/OTP login, the bearer-token refresh cycle and device binding.
• Runnable source for the key calls in Python and Node.js, including pagination over the history feed and VND normalization.
• Automated tests against recorded fixtures so a backend change shows up as a failing test, not a silent data gap.
• Interface documentation plus consent and data-retention guidance aligned to how this wallet's data must be handled.

Consent and the legal frame

Two instruments shape this work in Vietnam. Open data sharing is governed by the State Bank of Vietnam's Circular 64/2024/TT-NHNN, in force since 1 March 2025, which sets a consent-centric open-API framework rolled out in stages — information query, then consent-based access, then payment initiation — with bank API catalogs due in mid-2025 and full compliance targeted for March 2027. Personal data sits under the new Personal Data Protection Law (Law 91/2025/QH15, effective 1 January 2026) and its guiding Decree 356/2025/ND-CP, which replaced the earlier Decree 13/2023; both require clear, specific, recordable consent before financial data is processed.

We work to that posture by default: access is authorized in writing, every pull is logged against a consent record, only the fields a use case needs are retained, and an NDA covers the engagement where you want one. Consent scope, expiry and revocation are designed into the sync rather than bolted on.

Engineering notes we account for

Specific things about Viettel Money that shape the build, all handled on our side:

• OTP and device binding. Login is phone-number plus one-time code with the session tied to a registered device. We design the token lifecycle around that — refreshing before the short expiry and handling re-auth cleanly — so syncs survive without manual re-login.
• The off-app rail. Viettel Money is built to work over a Viettel signal without internet, via USSD and SMS, especially in rural areas. Those transactions still post to the same ledger, so we capture them through the app's history feed and flag records that originated off-app, keeping the dataset honest about how the customer transacted.
• Partner-originated loans. Cash loans are provided by Viettel's lending partners, not the wallet. We model them as a distinct source with their own principal, term and APR fields rather than assuming one unified ledger, so repayment schedules stay accurate.
• VND amounts. Values are integer dong with no decimal subunit. We normalize consistently to avoid the silent factor-of-100 errors that bite when a currency is assumed to have cents.

Where a sponsor sandbox or a consenting test account is needed, that is arranged with you during onboarding — the build runs against whichever fits your authorization.

Interface evidence

Store screenshots of the surfaces referenced above. Select to enlarge.

Where teams put this

• Reconciliation. A merchant pulls QR and transfer history nightly to match Viettel Money settlements against its own order book.
• Personal finance aggregation. A budgeting app folds a user's wallet balance and bill payments into a single net-worth and spend view alongside their bank accounts.
• Lending decisions. A partner reads consented transaction and savings history to assess cash-flow before extending credit, with loan records kept as their own source.
• Loyalty operations. A brand reconciles Viettel++ point earn-and-burn against its own campaign data.

How this was checked

Drafted in June 2026 from the app's own Play Store description and from primary regulatory and market sources for Vietnam — the Mobile Money licensing background, the open-API circular, the data-protection regime, and the wallet landscape it sits in. Key references, opened directly:

• Viettel Money on Google Play — feature set, services, package ID.
• Circular 64/2024/TT-NHNN, open API in banking — scope and phased timeline.
• Vietnam's Personal Data Protection Law — Law 91/2025/QH15 and the consent regime.
• Vietnam e-wallet players overview — same-category landscape.

Mapped by the OpenBanking Studio integration desk · reviewed June 2026.

Wallets in the same integration space

Other Vietnamese payment and wallet apps an aggregator often needs alongside Viettel Money. Listed for context, not ranked.

• MoMo — the market-leading wallet, holding balances, transfers, bill payments and a wide partner-merchant ledger.
• ZaloPay — wallet tied to the Zalo messaging network, with P2P transfers and in-chat payment records.
• VNPay — bank-integrated QR payment layer; transaction data flows largely through partner banks' e-banking.
• ShopeePay — wallet inside the Shopee marketplace, holding order-linked payments and refunds.
• SmartPay — merchant-focused wallet with point-of-sale and bill-payment records.
• GPay — wallet within the G-Group ecosystem, carrying transfers and service payments.
• Payoo — long-running bill-payment and collection platform with biller-level records.
• Timo — digital banking service holding account balances and statements.
• VTC Pay — gateway and wallet with gaming and online-service payment history.

Questions integrators ask

Which Viettel Money records can be reconciled against a bank statement?

The transaction history is the reconcilable layer: phone-number and interbank transfers routed over Napas, QR merchant payments, and bill or top-up charges, each carrying a timestamp, counterparty reference and a VND amount. We normalize those into a statement-shaped feed you can match line by line.

Does Vietnam's Circular 64 open-API regime reach a mobile-money wallet like Viettel Money yet?

Circular 64/2024/TT-NHNN took effect on 1 March 2025 and phases consent-based data sharing in across banks first, with catalogs due mid-2025 and full compliance set for March 2027. Wallet operators sit at the edge of that rollout, so for now we run the integration as authorized protocol analysis under your written consent and move it onto the consent API as that surface opens.

How do you handle the cash loans that Viettel says its partners provide?

Those loans are originated and serviced by Viettel's lending partners, not by the wallet itself, so the repayment schedule lives behind a partner boundary. We model loan records as their own source with principal, term and APR fields rather than folding them into the wallet ledger, which keeps the data accurate when a borrower's schedule differs from their wallet activity.

Viettel Money also works over USSD without internet. Are those off-app transactions reachable?

The protocol-analysis route captures what the app's authenticated session exposes over HTTPS. Transactions made through the USSD or SMS rail still post back to the same account ledger, so they appear in the history feed, but we flag any record that originated off-app so your dataset reflects how the customer actually transacted.

One last practical point on getting started. Source-code delivery begins at $300 and is billed only after we hand over the working integration and you have checked it does what you need; the alternative is to skip the build fee entirely and call our hosted endpoints, paying per call with nothing upfront. Either way the cycle runs one to two weeks, you give us the app name and what you want out of its data, and we arrange the access and compliance side with you. Start the conversation at /contact.html.