Travelers using a crypto payment app with VietQR in Vietnam should check the decoded recipient, amount and order context before approving payment. A printed code is not proof of a fixed amount, and an on-screen code is not proof of an automatically updated order. The display format alone cannot establish whether a particular app supports the payment.
Legal boundary and settlement structure
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.
VietQR identifies a local payment instruction; it does not make a merchant a direct recipient of USDT. BKJ describes a supported route in which stablecoin funds pass through service-side conversion and the merchant receives VND. NAPAS’s description of its own network does not confirm BKJ’s authorization or compatibility with every code.
Identify what the code tells the app
A QR code is a way of carrying information, while the payment service determines what can be done with that information. EMVCo’sQR payment overviewdistinguishes payment-code arrangements and standards. Standards help describe the structure; they do not certify that every app can complete every code a traveler encounters.
| Decoded information | Check against the current purchase |
|---|---|
| Recipient | Whether the receiving information appears |
| Amount | Whether an amount is shown or needs manual entry |
| Order | Whether the merchant links the code to this order |
| Missing details | Ask for clarification instead of guessing from the display format |
If the app cannot identify a supported payment, stop at that point. A recognizable VietQR label or a code that another customer scanned successfully is not enough to establish compatibility for a different account or payment route.
Prepare the current bill and merchant context
Keep the bill visible before scanning. Establish the purchase being paid and ask the merchant whether the displayed code is intended for that order or for general collection. This prevents an older screen or an unrelated printed code from being treated as the current payment instruction.
NAPAS’sVietQR transfer service descriptionexplains a bank-transfer use of the standard. That is useful context for understanding why a code may contain receiving information. It does not establish that a stablecoin payment app supports every bank-transfer code or every merchant configuration.
For an eligible user consideringBKJ Scan to Pay, compatibility must be established through the supported payment flow. The public description supports the merchant-payment use case, with local fiat received by the merchant; it does not provide a blanket guarantee for every printed or on-screen VietQR code.
Check amount and validity before approval
When an amount appears automatically, compare it with the current bill. When the app requests manual entry, enter the agreed VND amount and review it before proceeding. Automatic population reduces typing but does not remove the need to confirm that the payment belongs to the right purchase.
- Ask the merchant about a code shown for a specific checkout if the order has changed.
- A revised basket, corrected bill or restarted checkout may require a new instruction.
- Do not assume a saved screenshot remains suitable merely because the code is still readable.
If the merchant or app states an expiry condition, follow that instruction. Use the validity condition shown for the actual merchant order or supported payment flow. Do not apply a remembered expiry period from another checkout to the code in front of you.
Confirm the payment against the same order
BKJ’sVietQR payment guidedescribes reviewing recipient, VND amount and final confirmation for supported transactions. Use those details to match the payment to the bill kept open during checkout. The completion standard is not simply that the phone recognized a QR pattern.
- After approval, review the transaction status and ask the merchant to confirm the corresponding purchase where needed.
- Preserve the app record and the bill together.
- A newly displayed code should not distract from checking whether the previous attempt already paid the order.
If the merchant regenerates a code, make the relationship to the first attempt explicit. Identify whether the earlier payment is confirmed, unresolved or not submitted before starting another payment. A fresh code does not automatically cancel an earlier transaction.
Avoid using appearance as a safety shortcut
Do not infer that printed always means static or that a screen always means dynamic. A screen can display a reused image, and a printed code can relate to a specific document or order. The useful evidence is the information decoded and the merchant’s current instruction.
BKJ’sservice termsset the conditions for using its services. They should not be read as approval of a particular merchant code. Account eligibility and code compatibility must both be satisfied for the intended payment, and neither can be established from a logo alone.
Resolve unclear code details before retrying
- Ask the merchant about the bill, recipient and whether a new code is required.
- Ask the payment provider about an unsupported reading or transaction status.
- Keep the relevant order reference and the information shown by the app; avoid posting an active order code publicly when seeking help.
Use another accepted route if the code cannot be confirmed as suitable for the purchase. Before any later attempt, recheck the current bill and payment status. The reliable distinction is between a verified instruction for the intended order and an unresolved code, not simply between paper and screen.
A useful record after an uncertain scan includes the bill amount, the name displayed by the app and the stage reached before stopping. Keep those details without assuming a scan created a transaction. This allows the merchant and provider to distinguish an unsupported reading from an approved payment whose result still needs checking.