Paying in Vietnam

Checking the Recipient Name Before a VietQR Payment

Verify the payee, amount, and order details before completing a VietQR payment.

Reading time5 min
Updated16 October 2026
TopicPaying in Vietnam

Before approving a VietQR payment in Vietnam, compare the displayed recipient, the agreed VND amount and the merchant’s instruction for the current bill. If a name is unfamiliar or differs from the storefront name, ask the merchant to explain the connection. A match or mismatch alone does not establish legitimacy.

Vietnam does not recognize cryptoassets such as USDT as lawful payment instruments. Thenon-cash payment rulesprohibit unlawful payment instruments; their use can attractadministrative penalties. Merchant receipt of VND does not itself establish that a particular provider or conversion arrangement is authorized in Vietnam.

The recipient check concerns the VND collection instruction, not a request to send USDT to the shop. BKJ’s described supported route separates user stablecoin funds, service-side conversion and the merchant’s VND receipt. Verify the actual recipient and the permitted service arrangement; a familiar name cannot replace either check.

Recognize the risk of an unverified recipient

The practical risk is sending money to a destination that has not been confirmed for the purchase. A familiar business sign does not establish that every code nearby belongs to that business. Equally, a recipient name unfamiliar to the traveler may require an explanation rather than an accusation.

Keep the decision narrow: the traveler needs enough information to establish that the merchant is requesting payment to the displayed recipient for this bill. If that connection cannot be confirmed, pause the payment and use another accepted arrangement.

Identify what kind of name is being shown

Displayed labelWhat to clarify
RecipientWho is designated to receive the payment
Account holderWhose account the displayed name identifies
Payment serviceWhether the name identifies a service in the route
Storefront nameDo not assume every displayed entity uses the trading name

NAPAS’sVietQR transfer service informationdescribes account-based receiving information within that service. This helps explain why a payment display can contain account details. It does not establish the legitimacy of an individual code or prove a relationship between a named account and the merchant standing in front of the traveler.

  • Do not invent a corporate explanation for a mismatch.
  • If the merchant says the name belongs to its operating entity or authorized collection arrangement, ask the merchant to confirm that the displayed destination is the one intended for the current purchase.
  • Record the explanation when the amount or context makes that useful.

Understand why a name alone is insufficient

A matching name is only one part of the check. The amount, order and payment route must also fit. A traveler can recognize a recipient while still looking at a code for the wrong order or a total that has not been agreed. Verify the instruction as a whole rather than treating a single familiar field as approval.

EMVCo’sQR payment standards overviewexplains the role of standardized code arrangements. Standardization is not an endorsement of every recipient shown in a payment app. A valid-looking format does not prove that the transaction belongs to the intended merchant purchase.

For a supported payment throughBKJ Scan to Pay, the merchant receives local fiat through the payment route. That description does not let a traveler infer the identity behind an unfamiliar name without checking the actual confirmation screen and merchant instruction.

Compare the screen with the merchant’s instruction

  • Keep the current bill visible and show the merchant the non-sensitive recipient information that needs explaining.
  • Ask for confirmation of the exact destination and amount.
  • Do not hand over a logged-in phone or reveal approval credentials just to resolve a question about a displayed name.

BKJ’sVietQR payment guidedescribes reviewing the recipient and VND amount before confirming a supported transaction. Use that step to compare the app’s information with the merchant’s request. The presence of a confirmation button is not a reason to skip a mismatch.

If staff provide a replacement code, scan it as a new instruction and review the details again. Check the status of any earlier attempt before paying. A different code may solve a merchant instruction problem, but it does not establish that an earlier transaction has been canceled or reversed.

Limit information sharing while resolving the mismatch

Share only the information needed to identify the transaction and the question. A recipient-name check ordinarily does not require giving a merchant access to the traveler’s passport file, complete account history or security settings. Keep the inquiry focused on who should receive payment for the bill.

BKJ’sprivacy policydescribes handling of account and transaction information. Use official support channels if the app’s display needs explanation from the provider. A privacy policy is not a substitute for checking the recipient, but it helps identify the formal route for questions involving account data.

  • Preserve the bill and relevant payment details if the disagreement continues.
  • Avoid posting full transaction screenshots publicly without removing unrelated personal information.
  • A clear description of the mismatch is more useful than circulating sensitive material that does not help establish the merchant connection.

Pause when the connection remains unconfirmed

Ask the merchant to confirm its collection instruction and ask the payment provider to explain the fields or status shown by the app. These are different responsibilities. The merchant can identify the bill it wants paid; the provider can explain its own payment record, without necessarily verifying the commercial relationship behind every code.

If the recipient cannot be connected to the purchase with a satisfactory explanation, do not approve simply to end an awkward conversation. Agree another accepted method. The goal is a payment record that matches an understood merchant instruction, with the correct amount and a clear connection to what the traveler bought.

For a shared purchase, choose one person to coordinate this check with the cashier. Several companions scanning different codes at the same time can create conflicting explanations and payment attempts. Keep the current bill with the person handling approval, then share the final purchase record after the merchant instruction and payment status are clear.

Continue reading

Next: USDT Transaction Hashes, App Receipts and Purchase Records

Read next