Vietnam's Payment Rails: VietQR, NAPAS 247, and What Operators Need to Know

Vietnam's payment infrastructure has changed more in the past four years than in the preceding two decades. NAPAS 247, the country's real-time interbank transfer system, processed 8.9 billion transactions in 2024 — a 33.8% increase year-over-year. VietQR, the unified QR payment standard, has enrolled 40+ banks and e-wallets onto a common format. Yet most foreign operators approaching the Vietnamese market still route payments through fragmented e-wallet integrations, unaware of the underlying rails that determine cost, speed, and regulatory exposure.

This article maps the actual infrastructure stack — how NAPAS 247 and VietQR work, who controls access, what the licensing requirements are, and what a practical integration path looks like for operators building payment flows that touch Vietnam.

NAPAS 247: The Real-Time Interbank Backbone

NAPAS (National Payment Corporation of Vietnam) is the state-owned payment infrastructure operator, majority-owned by the State Bank of Vietnam (SBV) with commercial banks holding minority stakes. NAPAS operates several payment rails, but the one that matters most for operators is NAPAS 247 — the real-time real-time rail for interbank fund transfers, available 24 hours a day, seven days a week.

NAPAS's 24/7 interbank fast-transfer service went live nationally in 2016, replacing the previous batch-processing interbank settlement system that ran on business hours only. The "NAPAS 247" brand name dates to June 2021, when NAPAS launched it alongside the VietQR standard — a distinction worth keeping straight, because the service and the brand are commonly conflated into a single launch date that matches neither. The key parameters:

• Speed: Settles within seconds. Neither NAPAS nor the SBV publishes a processing-time figure, and individual bank disclosures range from roughly 5–10 seconds to up to a minute, so any single number you see quoted for this rail is someone's estimate rather than a published parameter
• Availability: 24/7/365, including Vietnamese public holidays
• Transaction limit: VND 500 million per transaction (~$20,000 USD) for retail transfers; higher limits apply for corporate accounts through specific bank channels
• Participant count: 40+ member banks as of 2025, covering effectively all licensed commercial banks in Vietnam
• Volume growth: NAPAS 247 processed 8.9 billion instant transfers in 2024, up 33.8% year-over-year, with daily volume exceeding 26 million transactions (NAPAS/ClearingPost, 2025)

The technical model is a hub-and-spoke architecture. NAPAS operates the central clearing switch; member banks connect via the NAPAS Gateway. Transactions originate from a sender's bank account, route through the NAPAS switch, and credit the recipient's account at the destination bank — all within the 15-second window.

How Banks Connect to NAPAS 247

Every licensed commercial bank in Vietnam participates in NAPAS through a bilateral membership agreement. The participation is not voluntary for banks — the SBV has made NAPAS membership a de facto requirement for banks holding retail banking licenses. For operators, this means that any Vietnamese bank account is, in principle, reachable via a NAPAS 247 transfer.

The practical limitation is on the access side. NAPAS 247 transfers can only be initiated by licensed entities. A foreign operator cannot connect to NAPAS directly — access requires either: (a) a Vietnamese commercial bank account and a direct API relationship with that bank's payment gateway, or (b) a licensed payment intermediary acting as the access point.

VietQR: The Unified QR Standard

VietQR is Vietnam's national QR payment standard, developed by NAPAS and the SBV and formally launched in 2021. Before VietQR, Vietnam had multiple incompatible QR formats: VNPay's QR, individual bank QR codes, MoMo's QR, and others — meaning a merchant needed multiple QR codes displayed at checkout to capture different app users.

VietQR solves this by standardizing QR code encoding across all participating banks and e-wallets. A single VietQR code encodes the recipient's bank account details (bank code, account number, amount, and transaction reference) in EMV QR code format. Any VietQR-compliant app — whether a bank's mobile app, MoMo, ZaloPay, or VNPay — can scan the code and initiate a transfer.

The underlying settlement for a VietQR scan at a bank-linked app flows through NAPAS 247 as an interbank transfer. The QR code is the front-end; NAPAS 247 is the back-end. This architecture means:

• VietQR merchant acceptance is effectively zero-MDR for bank account-linked payments (the transfer is a standard NAPAS IBFT, which banks generally do not charge merchants to receive)
• E-wallet scans of VietQR codes may route differently — some wallets convert to an internal transfer before initiating the NAPAS leg, which can add a fee on the wallet side
• Reconciliation is straightforward because each VietQR transaction carries a structured reference field that maps to the merchant's order ID

VietQR Adoption and Limitations

As of Q1 2025, VietQR is accepted by 40+ banks and all major e-wallets. The SBV has mandated VietQR compatibility for all payment intermediaries holding licenses. Physical merchant adoption is high in urban areas — convenience stores, restaurants, and market stalls in Ho Chi Minh City and Hanoi commonly display VietQR codes.

The limitation is on the pull-payment side. VietQR is designed for push payments (the customer initiates the transfer). There is no standardized pull mechanism in VietQR for merchant-initiated charges, recurring billing, or subscription payments. Operators needing to pull funds from a customer's Vietnamese bank account need a different solution — typically a card-on-file arrangement or an e-wallet direct debit agreement.

The E-Wallet Layer: VNPay, MoMo, ZaloPay

Vietnam's dominant e-wallets are VNPay, MoMo, and ZaloPay. Each holds a payment intermediary license from the SBV, and each operates as both an access layer for NAPAS 247 and a closed-loop transaction network for wallet-to-wallet payments.

VNPay (operated by VNPay JSC, part of VNLIFE) is the largest e-wallet by merchant terminal coverage and was first to scale national QR acceptance in Vietnam. VNPay holds licenses as both a payment gateway and an e-wallet. Note: VNPay is privately held — not state-owned, and not a VNPT subsidiary. VNPT is the separate state telecommunications operator, which runs its own VNPT-Pay product (a different wallet than VNPay). Confusing the two is a common error; they are different companies.

MoMo (legal entity: M_Service JSC — M_Service is MoMo's corporate name, with major shareholders including Warburg Pincus and others) reports over 30 million users — cumulative, not monthly actives, and reaffirmed in MoMo's own 15th-anniversary release of November 2025 — and is Vietnam's dominant consumer P2P wallet. MoMo's strength is in peer-to-peer transfers, bill payments, and in-app purchases. It has an extensive agent network for cash top-up, which is important in a market where a significant portion of the population still operates primarily in cash.

ZaloPay is backed by VNG Corporation, Vietnam's largest tech company, and benefits from distribution through Zalo — Vietnam's dominant messaging app with roughly 79 million monthly active users (VNG's own Q3 2025 reporting). ZaloPay is deeply integrated into the Zalo app, which gives it a distribution advantage for user-initiated payments but limits its standalone merchant acceptance footprint.

E-Wallet Fragmentation: The Operator Problem

For operators needing to accept payments from Vietnamese consumers, the e-wallet landscape requires either integrating with all three major wallets separately or using an aggregator. Direct integration with VNPay, MoMo, and ZaloPay requires individual contracts, separate API integrations, separate settlement accounts, and separate reconciliation flows. Each wallet has different API standards, sandbox environments, and merchant onboarding requirements.

The aggregator path — using a payment gateway that provides unified access — simplifies integration but adds a fee layer. Major aggregators operating in Vietnam include VNPay (which also acts as a gateway for other wallets), Payoo, and international providers like 2C2P and Checkout.com who have built local wallet acceptance into their Vietnamese products.

Licensing Requirements: What the SBV Requires

The SBV issues two categories of license relevant to payment operators:

Payment intermediary license (Giấy phép hoạt động cung ứng dịch vụ trung gian thanh toán): This is the primary license for companies providing payment gateway services, e-wallets, or financial switching services in Vietnam. Requirements include:

• Established legal entity in Vietnam (foreign ownership restrictions apply — typically 49% maximum foreign ownership in a licensed payment company, though this is subject to ongoing regulatory review)
• Minimum charter capital of VND 50 billion (~$2 million USD) for gateway services; higher for e-wallet services
• Dedicated payment systems and data storage in Vietnam (data localization requirement under the Cybersecurity Law)
• SBV technical audit of the payment system before license issuance
• Anti-money laundering program meeting SBV standards

Payment service provider agreement model: Foreign operators who cannot or choose not to obtain a direct SBV license can provide services through a licensed Vietnamese payment intermediary. Under this model, the Vietnamese licensed entity acts as the payment service provider; the foreign operator is a technology provider or downstream partner. Revenue sharing arrangements vary. This path is faster (no SBV license application required) but creates dependency on the Vietnamese partner's license status and commercial terms.

SBV Sandbox: The SBV launched a fintech sandbox in 2021, allowing licensed sandbox participants to test payment services with real transactions under a regulatory exemption. The sandbox covers credit scoring, P2P lending, and payment services. Foreign-invested companies can participate under certain conditions. Sandbox authorization is not equivalent to a production license but provides a path for proof-of-concept before committing to full licensing.

Practical Integration Architecture for Foreign Operators

For a foreign operator processing payments from Vietnamese customers or disbursing to Vietnamese recipients, the practical integration options are:

Option 1: Bank partnership with API integration Partner with a top-tier Vietnamese commercial bank (Vietcombank, Techcombank, VPBank, MB Bank are the most API-mature) that provides merchant payment services. The bank holds the NAPAS 247 membership; you integrate via the bank's payment API. This gives NAPAS 247 access, VietQR generation capability, and often e-wallet acceptance bundled. Settlement is to a Vietnamese VND account. FX conversion back to the operator's base currency requires a separate arrangement.

Option 2: Licensed aggregator Use a licensed payment aggregator operating in Vietnam — 2C2P, Checkout.com, or VNPay's gateway product. These provide unified access to NAPAS, VietQR, and major e-wallets through a single API, with multi-currency settlement options. MDR for card transactions is typically 2.5–3.5%; e-wallet and NAPAS transfer acceptance fees are lower. The trade-off is less control over bank relationships and higher per-transaction cost versus a direct bank integration.

Option 3: SBV-licensed subsidiary For operators with significant Vietnam volume or strategic reasons to hold a local license, obtaining a payment intermediary license directly provides the most control. Timeline is typically 12–24 months from entity incorporation to license issuance. This path is appropriate for operators expecting to process more than $50–100 million per year in Vietnam volume — below that threshold, the licensing overhead rarely justifies the cost savings versus an aggregator.

The Disbursement Side: Paying Out to Vietnamese Bank Accounts

For operators disbursing to Vietnamese recipients — marketplace sellers, gig workers, insurance payouts — NAPAS 247 IBFT is the standard mechanism. The practical requirements:

• You need either a Vietnamese bank account from which transfers originate, or a licensed payment partner who initiates NAPAS transfers on your behalf
• Recipients need a Vietnamese bank account (NAPAS member bank) and their account number + bank code
• VietQR can be used to collect the recipient's account details in a standardized format if you build a VietQR scanning flow in your application
• NAPAS 247 transfers complete in seconds; your licensed partner may impose cutoffs or batch schedules for operational reasons — confirm settlement timing with the partner directly

Recurring Billing in Vietnam: Four Proprietary Schemes, No Rail

The limitation flagged above — that VietQR is push-only and offers no merchant-initiated pull — is the single most consequential fact for anyone selling subscriptions into Vietnam. It is also where most market guides stop. This section is what sits behind it.

The short version: recurring billing in Vietnam exists, it works, and on the card side it is not a rail feature.

Two different things need separating here, because conflating them is the usual error. On the bank-account side Vietnam does have a regulated pull instrument: ủy nhiệm thu, the payee-initiated collection service governed by Circular 15/2024/TT-NHNN, issued the same day and effective the same day as the card circular. Article 3(4) defines it as the bank debiting the payer's account at the payee's request "trên cơ sở thỏa thuận bằng văn bản" — on the basis of a written agreement between payer and payee — and Article 9 sets out the operating rules, including the case where the payer "đã ủy quyền cho ngân hàng được quyền tự động trích nợ": has authorised the bank to debit automatically. That is a pre-authorised, creditor-initiated pull with a mandate behind it.

What Vietnam does not have is a centralised interbank scheme layered over that instrument — no common rulebook, no standard mandate format, no R-message set of the kind SEPA Direct Debit or Bacs provides. And on the card side there is no MIT framework at all. So for a merchant wanting to charge a customer on a schedule, the practical options are four proprietary, contractually-gated schemes that differ from one another in ways that matter, including one widely treated as recurring that is not.

The card circular is silent — which is not the same as Vietnamese law being silent

Start by discarding a stale premise. Circular 19/2016/TT-NHNN on bank card operations is repealed. The instrument in force is Circular 18/2024/TT-NHNN, effective 1 July 2024 (with some articles phased to 1 October 2024 and 1 January 2025 — none of them the ones relied on here), which repealed 19/2016 together with six amending circulars — 30/2016, 26/2017, 41/2018, 28/2019, 22/2020 and 17/2021. Any Vietnam payments analysis still citing 19/2016 as live regulation is working from a pre-July-2024 picture.

More importantly for this section: Circular 18/2024 says nothing about stored card credentials, tokenisation, or merchant-initiated transactions. The word "token" does not appear in the instrument. Its storage provisions concern customer identification and biometric data, not payment credentials.

That silence is specific to the card circular, and it should be read as neither permission nor prohibition. It is the direct reason every card and wallet mechanism below is a private scheme with its own consent model, its own limits, and its own approval gate, rather than a standard an operator can build to once. Anyone who tells you Circular 18/2024 "permits" or "governs" recurring card payments in Vietnam is inventing it — and anyone who tells you Vietnam has no regulated pull instrument at all has not read Circular 15/2024.

The routing mandate is narrower than usually stated

Circular 18/2024's Article 22 carries the domestic switching mandate, and its two clauses have different scopes — a distinction that gets flattened in most summaries and directly affects foreign merchants.

Clause 1 is unconditional: switching and electronic clearing for card transactions on BINs issued by the State Bank must go through an SBV-licensed switching organisation. That is the domestic-card rule.

Clause 2, covering cards on international-scheme BINs, applies only to "giao dịch nội địa xuất trình thẻ", which Article 3(10) defines with two limbs: the card must be issued by an issuer in Vietnam, and used at an ATM or a point-of-sale card-acceptance device in Vietnam. Both limbs must hold.

The consequence: card-not-present e-commerce on a Visa or Mastercard BIN sits outside the clause 2 mandate — and so, on the first limb, does a foreign-issued card even when presented in person. For a foreign merchant selling online, that is the difference between a hard architectural constraint and a commercial choice, and it is worth confirming against your own card mix before designing around a mandate that may not bind your traffic.

The four mechanisms, ranked by what the documentation actually supports

1. MoMo Subscription — the most completely documented pull.

MoMo publishes the most complete recurring stack of the three wallets, and its documentation states the pull property explicitly: customers "are requested to give pre-authorization for their future payments," and "payments will be done at fixed intervals without any specific payment action from the consumer follow a subscription model."

The scheme has real subscription semantics rather than a bare token. Frequency is an enumerated field — DAILY, WEEKLY, BI_WEEKLY, MONTHLY, BI_MONTHLY, QUARTERLY, SEMI_ANNUALLY, YEARLY — and amount type distinguishes FIXED ("Amount charged in each frequency cycle will be the same as recurringAmount") from VARIABLE ("Amount charged in each frequency cycle can be variable"), with recurringAmount functioning as the ceiling for variable charges. Binding is a distinct step: the merchant exchanges a callbackToken from the first transaction for a durable subscription token.

The operational catch is not technical. MoMo requires merchants to complete a Tokenization Evaluation Form before integrating. Tokenisation is approval-gated, not self-serve, so the integration timeline includes an assessment you do not control.

2. ZaloPay AgreementPay — a real pull, in two variants.

ZaloPay's mechanism is AgreementPay, an auto-debit binding with a documented lifecycle — Create Binding, Pay By Token, Unbind — and a max_amount ceiling on the binding, available in both a wallet and a card variant.

ZaloPay's wallet documentation is explicit about the unattended property: "Auto Debit is a payment solution which allows merchants can debit money from user balances, accounts automatically after a user signed up for an agreement." The documented wallet payment flow is server-to-server throughout — QueryBalance, CreateOrder, PayByToken, callback — with no OTP step.

The wallet and card paths do differ, and the difference is worth knowing. A verification_url for OTP entry appears only on the card token documentation, and only on a pending (return_code: 3) response — a conditional step-up, not a mandatory per-charge interruption. The roughly 40-bank ATM-card coverage via NAPAS is likewise a property of the card binding, not of the wallet one.

A related trap: ZaloPay publishes a page titled "Subscription" that is not a merchant subscription API. Its own documentation describes it as an internal notification service driven off AgreementPay data. Do not scope work against it.

3. NAPAS gateway recurring — advertised, unspecified.

NAPAS markets its online payment gateway as supporting tokenisation and "thu tiền tự động định kỳ" — automatic periodic collection — across domestic debit and credit cards from nearly 40 banks plus international schemes.

That is a first-party claim from the switch itself, and it is the closest thing Vietnam has to a rail-level recurring capability. But NAPAS publishes no public technical specification for it: no API documentation, no merchant-initiated-transaction indicator scheme, no reason codes. NAPAS does run a developer portal at developer.napas.com.vn, linked from the footer of the service page itself — it is login-gated and carries no public specification, so the gate is at least locatable. Treat NAPAS recurring as real but unscoped from the outside, and get the specification through your acquiring bank before committing a roadmap to it.

4. VNPAY token — do not classify this as recurring.

This is the correction most likely to save someone a quarter. VNPAY publishes a token API with token_create, pay_and_create, token_pay and token_remove commands, and it is routinely listed alongside the mechanisms above as though it were equivalent. It is not.

VNPAY's own documented token payment flow places a step squarely in the middle of it: "Khách hàng nhập thông tin xác thực OTP Ngân hàng tại VNPAY" — the customer enters a bank OTP at VNPAY. And token_pay is not a server-to-server call at all: it is a GET against an HTML page, token_ui/payment-token.html. A flow that renders a page for a human and asks that human for an OTP is not a mechanism for charging them while they sleep. VNPAY's developer portal lists exactly three products — standard payment, token payment, and installments — and no merchant-facing recurring or auto-debit API appears among them.

VNPAY does publish auto-debit elsewhere, which is worth stating precisely so the distinction is not overdrawn: its e-wallet terms document a standing authority to debit a customer's wallet for bills, explicitly including recurring ones, and its VnPayBill product collects utility bills via a bank ủy nhiệm thu registration — the Circular 15/2024 instrument above, productised. Neither is an API a merchant integrates. Both are biller-registration arrangements.

VNPAY tokenisation is card-on-file checkout convenience — the customer skips re-entering the card number — not merchant-initiated billing. If a subscription model depends on charging without the customer present, this mechanism does not provide it, whatever the word "token" suggests.

VietQR: static versus dynamic

One spec detail worth having, since VietQR's push-only nature makes the QR itself the entire merchant-side surface. NAPAS states that VietQR complies with EMVCo's QR payment standard and with the SBV base standard promulgated under Decision 1928/QĐ-NHNN.

That EMVCo lineage is what defines the static/dynamic distinction, via the Point of Initiation Method data object: value "11" for static QR codes, used "when the same QR Code is shown for more than one transaction," and "12" for dynamic QR codes, used "when a new QR Code is shown for each transaction." All other values are reserved.

Operationally that is the difference between a printed sticker at a counter and a per-order code carrying the amount and reference. Since a static code carries no amount, reconciliation on a static VietQR depends entirely on the payer typing a reference correctly — which is to say it depends on something you cannot control. Dynamic codes are the default choice for any merchant reconciling against orders rather than eyeballing a daily total.

What is still open

Two questions this section cannot close, both worth raising with a provider before committing.

The first is authentication thresholds. Vietnam's biometric-authentication requirements sit in a separate instrument from the card circular, and because such rules typically key off transaction value, they may bear directly on whether an unattended recurring charge clears at a given amount. That instrument was not retrieved here.

The second is likely the real gate, and it is upstream of every mechanism above: whether a foreign merchant can hold a contract with a Vietnamese wallet or acquirer without a local entity. None of the wallet documentation addresses it. Given that every recurring mechanism in Vietnam is contractually gated rather than open, that contracting question determines whether any of this is available to you at all — and it is the first thing to ask, not the last.

What This Means for Operators

Vietnam's payment infrastructure is more capable than most foreign operators expect, and less accessible than the domestic user experience suggests. NAPAS 247 is fast, reliable, and broadly adopted — but every access path for foreign operators runs through an SBV-licensed intermediary, adding cost and counterparty dependency.

The e-wallet fragmentation problem is real but manageable. VietQR is solving the merchant-side problem; the remaining gap is in pull payments and recurring billing, where no unified standard exists yet.

For operators assessing Vietnam entry, the practical question is volume threshold: at what volume does the licensing cost of a direct SBV license become cheaper than aggregator MDR? The crossover point for most payment types is in the $50–100 million annual range. Below that, an aggregator or bank partnership gets you market access faster with predictable economics. Above it, the SBV license pays back quickly.

The SBV has been incrementally liberalizing payment regulations since 2020, and the sandbox regime suggests continued openness to fintech participation. The licensing requirements that exist today are unlikely to become more restrictive — but the data localization requirements under Vietnam's Cybersecurity Law are a long-term infrastructure constraint that operators must build for from the start, not retrofit.

For a side-by-side comparison of NAPAS 247 and VietQR against Pix, UPI, SPEI, PromptPay, PayNow, InstaPay, and DuitNow — MDR model, identifier architecture, cross-border readiness, and licensing path — see the Real-Time Payment Rails Comparison Matrix.