USDT 交易雜湊、支付 App 記錄和商家收據，證明越南消費中的不同環節。應分別保存入金、商家付款及購買內容記錄，再依需求建立關聯。資金成功鏈上轉入 App，不能單獨證明越南商戶已經收到款項。
法律邊界與結算結構
越南不承認USDT等加密資產為合法支付工具。 非現金支付規則禁止使用非法支付工具，相關行為存在行政處罰風險。商家最終收到VND，並不能單獨證明特定服務商或轉換安排已獲准在越南開展業務。
應分別保留用戶穩定幣入金、服務端轉換及商家VND收款三個環節的證據。這是BKJ所描述的支援掃碼結構，不代表某筆交易的每個環節都已完成。入金哈希不能證明服務方已獲授權，也不能證明整項安排的合法性。
使用憑證前先明確記錄性質
交易哈希識別特定區塊鏈上的交易，需要結合網路和交易詳情理解。 Ethereum 的交易文檔說明以太坊內的交易訊息，其他網路則需使用對應記錄。只有哈希、沒有網路背景，仍是不完整的轉帳描述。
App 記錄說明支付服務內某個事件及頁面狀態，例如商家付款。商家收據說明商家所開立文件所記載的購買內容。除非文件本身支持，不應自動稱為稅務發票、交付證明或鏈上結算記錄。
- 應以具體事件命名，不要統一籠統稱為「付款證明」。
- 入金確認、商家付款確認和明細帳單都有用途，但分別回答不同問題。
入金與商家收款分別理解
向接收 App 發送 USDT 屬於入金，之後購買可能會透過另一條路徑完成。使用BKJ 掃碼支付完成支援交易時，用戶使用支援穩定幣資金，商家經服務安排接收當地法幣。
- 這不能證明每筆二維碼消費都有用戶可見的鏈上交易哈希。
- 不要為每筆商家付款編造一一對應的鏈上交易，也不要把先前入金哈希重新當成商店交易編號。
- 應查看購買本身的 App 記錄。
NAPAS 的VietQR 轉帳服務介紹說明銀行轉帳場景，有助於區分當地接收資訊和鏈上入金記錄，但不能證明每個相容加密支付 App 背後的完整結算路徑。
按能回答的問題儲存資料
查詢入金去了哪裡、接收 App 是否已記帳時，使用款項轉入記錄。保留資產、網路、目標位址、金額和可用編號，比只顯示成功狀態的截圖更便於發送方與接收方定位。
查詢消費在支付服務中的金額和狀態時，使用商家付款記錄；識別商品、日期及應付金額時，使用商家帳單或收據。應透過真實購買資料連接記錄，不要只把無關截圖放在同一資料夾，就假定關係已經清楚。
BKJ Card 資訊介紹另一條卡片路徑的交易記錄。不要把卡片購買改稱 VietQR 交易，也不要假定卡片記錄一定包含與掃碼相同的編號。應標記實際採用的路徑。
圍繞具體購買整理憑證
記錄商家、日期、購買內容和當地帳單金額，再加入付款路徑、App 編號或狀態。問題涉及入金時，將轉入記錄作為補充，而不是商家收款的主要證明。
BKJ VietQR 支付指南說明支援流程及最終核對資訊。將對應購買記錄和帳單一起保存。商家可能另有訂單號，應保留兩套可用編號，不要要求它們自動相同。
每項金額都應標明幣種和用途。 USDT 入金數、VND 帳單，以及以其他幣種展示的卡片記錄，無法直接比較裸數字。調查差額前，先先明確各數字代表什麼。
不擴大截圖能證明的範圍
轉帳截圖不能證明後續所有事件。當交易所顯示發出時，接收 App 可能仍需完成記帳；App 付款記錄也無法單獨證明交付了哪些商品，或商家已出具報銷所需文件。
- 不要修改記錄來讓編號看起來一致。
- 資金、App 和商家系統使用不同編號時，應保留原樣並解釋用途。
- 向支援團隊提供副本時，刪除無關個人資料，但保留調查所需資訊。
將正確資料交給對應一方
| 問題 | 聯絡對象與資料 |
|---|---|
| 入金未記帳 | 發送服務及接收 App；提供轉入資料 |
| 付款狀態不明確 | 付款服務方；提供 App 編號 |
| 購買核對 | 商戶；提供帳單或訂單資料 |
| 缺少消費明細 | 實際銷售方；索取相應憑證 |
結束處理前，明確真正確認的是哪個環節。入金解決不代表商店付款已解決，付款確認也不能自動補齊明細收據。清楚的記錄組合，應能分別說明資金如何進入 App、購買如何支付，以及商家出售了什麼。