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、购买如何支付，以及商户出售了什么。