Pulling account data out of Sacombank Pay, the authorized way

Sacombank Pay clears transfers up to 50 billion VND a day and links as many as five current accounts behind a single login — both figures come from the app's own store listing. That is the per-user state a third party wants to read: balances, a dated statement line, transfer history, savings, loans, and a Sapphire loyalty ledger, all sitting on Saigon Thuong Tin Commercial Joint Stock Bank's servers. This page is about the authorized ways to reach that data and what the studio hands over when the work is done.

The short version: account data lives behind an authenticated session, the regulated rail for reaching it is still being built out by Vietnamese banks, and a working integration today reads a consenting customer's session and migrates onto the official endpoints as Sacombank publishes them. Below is where the rules sit, what data is actually there, and how we'd build it.

Where Circular 64 puts Sacombank's data

Vietnam got a formal open-API regime late in 2024. Circular 64/2024/TT-NHNN, issued by the State Bank of Vietnam, took effect on 1 March 2025 and requires commercial banks to expose standardized APIs that let third parties reach customer data — but only with the data owner's consent, per the regime summaries published by Brankas and Open Conversations. The technical floor is specific: OAuth 2.0 for authentication, TLS 1.2 or higher in transit, JSON over REST with ISO 20022 compatibility, and consent that is time-bound, revocable and auditable.

Rollout is phased. As the regime reads, publicly disclosed product information comes first, consent-based queries of customer account data follow within roughly 18 months of the effective date, and payment initiation within 24 months; banks must comply fully by 1 March 2027. So the dependable basis for an integration right now is the customer's own authorization, not a present-day assumption that Sacombank's consent endpoints are already live. We treat Circular 64 as the rail the build moves onto, and design for it from day one.

What sits behind a Sacombank Pay login

These are the surfaces the app exposes to its own users, named the way the app describes them.

Routes in, and the one we'd pick

Three authorized routes apply here. Each reaches a different slice of the data with a different durability.

1 · Consent-based open API under Circular 64

This is the regulated path. It returns published product data already, and consent-based account data as Sacombank brings its phase-two endpoints online. Durable and official, with consent recorded the way the regulator expects. The access and onboarding for it are arranged with you during the engagement; we handle the OAuth client registration and consent wiring.

2 · Authorized protocol analysis of a consenting account

With the account holder's authorization, we capture the app's own HTTPS traffic and reconstruct the balance, statement and transfer-history calls, plus the OAuth / token / Smart-OTP chain that guards them. This reaches the broadest set of surfaces today. It needs a re-validation pass when the app changes between releases, which we own.

3 · User-consented session access

Where a given account is not yet covered by a published API, the holder consents to us operating their session for read access. It is the bridge that keeps coverage complete while the regulated route fills in.

For a build that needs to run before the regulated endpoints are widely live, we'd start with route 2 against a consenting account — it reaches balances, statements and transfer history now — and fold in Sacombank's Circular 64 consent API as the bank publishes it, so the same integration ends up on the regulated rail without a rewrite.

A balance-and-statement call, sketched

Illustrative only. Endpoint paths and field names are reconstructed during the build against a consenting account, not published here; the shape below reflects what Circular 64's technical floor implies and what we confirm in capture.

# OAuth 2.0 is mandated by Circular 64 (RFC 6749); TLS 1.2+ in transit.
POST /oauth2/token
  grant_type=authorization_code
  code=<consent_grant>                # time-bound, user-revocable
  -> { access_token, refresh_token, expires_in, consent_id }

GET  /accounts                          # up to 5 linked current accounts
  Authorization: Bearer <access_token>
  -> [ { account_id, alias, currency: "VND", balance } ]

GET  /accounts/{id}/statement?from=2026-05-01&to=2026-05-31
  -> { entries: [ { ref, posted_at, amount, counterparty, channel } ] }
     # channel is tagged "NAPAS247" / "VietQR" for instant transfers

# Step-up: Smart OTP / biometric signing gates a transfer.
# Reads (balance, statement) stay inside the consent scope.
on 401 -> run refresh_token flow
on 403 -> consent expired or revoked, re-prompt the account holder
      

What lands in your repo

Everything is scoped to this app's actual surfaces, not a generic banking stub.

• An OpenAPI / Swagger spec covering the account-list, balance, statement, transfer-history and savings / loan read surfaces.
• A protocol and auth-flow report: the OAuth token exchange, refresh, Smart OTP / biometric step-up, and the consent_id lifecycle as they behave here.
• Runnable source in Python and Node.js for the balance pull, paginated statement fetch, and transfer-history read.
• Automated tests that run against a consenting account or a sandbox.
• Interface documentation with field mappings, VND handling, and the Napas247 / VietQR channel tags.
• Compliance and data-retention notes lined up with Circular 64's consent-record requirements.

What we plan for on this build

A few things about Sacombank Pay specifically shape the work, and we handle each on our side.

• The app links up to five current accounts and lets authorized members receive a shared fund's balance and transaction alerts. We map that multi-account and shared-grant model so a consenting user's full set is read consistently, and a share that only covers one account is not over-read.
• Logins are guarded by Smart OTP and biometrics, and a transfer is signing-gated. We design the auth flow around that step-up so token refresh and transaction signing don't silently drop the session mid-sync, and we keep the sync aligned to the consent-expiry window so the feed doesn't lapse without warning.
• Profile updates run through chip-based national ID or a VNeID account, so the profile surface depends on eKYC state. We read that state rather than assume a fixed schema.
• Sacombank Pay ships frequent releases. When a new version shifts the in-app flows, we re-run the capture and patch the parser before the change reaches your sync.

Access, sandbox arrangements and any authorizations are set up with you during onboarding — part of the project, not a checklist you clear first. We work authorized, log what we touch, minimize the data pulled, and sign an NDA where the engagement calls for one.

Staying current as the app changes

Statement reads are as fresh as the bank's own ledger. Napas 247 entries land within seconds of settlement, so a reconciliation feed sees instant transfers almost immediately. Consent is time-bound under Circular 64; we schedule the refresh ahead of expiry so the feed does not stall. And because the app updates often, we pin the captured version and re-validate on each release rather than waiting for a break.

Screens we worked from

Public store screenshots used while mapping the surfaces above. Tap to enlarge.

Cost, and how the build runs

A runnable Sacombank Pay integration ships in one to two weeks. Source-code delivery starts at $300: you receive the runnable API source and its documentation, and you pay only after delivery, once it works for you. If you'd rather not host anything, our pay-per-call hosted API is the other model — you call our endpoints and pay per call, with nothing upfront. Tell us the app and what you want out of its data, and we take it from there — start a conversation here.

Vietnamese wallet and banking neighbours

Apps an aggregator would map alongside Sacombank Pay, each holding its own slice of server-side data. Framing is ecosystem, not ranking.

• MoMo — a payments super app with wallet balance, bill and transfer history across a large user base.
• ZaloPay — a wallet tied to the Zalo messenger, holding linked-bank and transaction records.
• VNPAY — a QR-led payment network with merchant and transfer data widely connected across banks.
• ShopeePay — wallet and payment history inside the Shopee marketplace.
• Viettel Money — a telco-backed wallet serving both urban and rural users with transfer and top-up records.
• Moca (GrabPay) — ride-hailing and food-delivery payments routed through Grab.
• VCB Digibank — Vietcombank's retail banking app with balances, statements and transfers.
• Techcombank Mobile — Techcombank's app holding similar account and transaction data.
• Sacombank mBanking — Sacombank's older mobile banking app, sharing the same backend accounts as Sacombank Pay.

Questions integrators ask

Does Sacombank Pay's open API already return customer account data, or just published product details?

Vietnam's Circular 64 took effect on 1 March 2025, and it phases the open APIs in by function: publicly disclosed product information first, consent-based customer account data within about 18 months, and payment initiation within 24 months. Until Sacombank publishes its consent-based endpoints, we read a consenting account through authorized protocol analysis and move the integration onto the regulated API as it goes live.

Can you cover all five linked current accounts and the shared-fund notifications?

Yes. With the account holder's consent we map the multi-account model so each of the up-to-five linked current accounts is read, along with any shared-fund grant that pushes balance and transaction alerts to authorized members.

How do Smart OTP and biometric login change an automated integration?

We model the Smart OTP and biometric step-up directly in the auth flow. Token refresh and transaction signing are handled so the session does not drop mid-sync, and reads stay inside the time-bound, revocable consent that Circular 64 requires.

Are Napas 247 and VietQR transfers visible in the data you pull?

Transfer history carries the channel, so instant Napas 247 and VietQR movements are tagged and can be reconciled against statement entries. Initiating a transfer is a separate, signing-gated action and is handled under the same consent and audit controls.

What was checked

Surfaces were read from Sacombank's own product page and the Google Play listing in June 2026; the regulatory picture from the State Bank of Vietnam's Circular 64 as summarized by Brankas and Open Conversations, and the instant-transfer rail from Napas's VietQR service page. Primary sources opened:

• Sacombank — Sacombank Pay product page
• Google Play — SACOMBANK PAY listing
• Brankas — Circular 64 and Vietnam open banking
• Napas — FastFund 247 with VietQR

Mapped by the OpenBanking Studio integration desk · June 2026.