客户表示已经付款，但订单仍显示未付款。钱包可能显示交易已发送，而商户却无法在预期的付款记录中找到它。在要求客户再次付款或认定资金已经丢失之前，企业需要进行结构化调查。本指南说明如何从原始订单和交易 ID 开始，追踪一笔缺失的加密货币付款，并核对区块链、支付网关和最终商户记录。
“缺失的加密货币付款”到底是什么意思？
加密货币付款缺失并不一定意味着交易消失了。
在实际情况中，这个说法可能指多种不同情况：
- 客户创建了交易，但交易尚未到达网络；
- 交易存在，但仍处于待处理状态；
- 客户在错误的区块链网络上发送了付款；
- 目标地址或代币不正确；
- 客户发送的金额少于要求金额；
- 客户完成付款之前，发票已经过期；
- OxaPay 已检测到付款，但商户系统没有更新订单；
- 付款存在，但商户无法将其与正确的客户或订单匹配。
这些情况需要采取不同的处理方式。因此，第一个目标并不是简单地“找到钱”，而是确定付款在哪个环节开始偏离预期流程。
更完整的 加密货币支付生命周期 说明了交易检测、付款接受、订单履约和运营完成是彼此独立的阶段。付款可能已经在链上可见，但尚未产生预期的业务结果。
开始之前：不要让客户再次付款
第二次付款可能会把一个简单的调查变成重复付款和退款问题。
在第一笔交易被找到并完成分类之前，客服不应要求客户重新发送资金。客服也绝不能向客户索要：
- 私钥；
- Seed 或恢复短语；
- 钱包密码；
- 身份验证代码。
调查只需要付款参考信息和可以公开验证的交易信息。
缺失加密货币付款调查：分步流程
第 1 步：收集付款参考信息
先查看商户自己的记录，而不是立即搜索区块链。
请求或检索以下信息：
| 所需信息 | 用途 |
|---|---|
| 订单或发票 ID | 用于识别商业请求 |
| OxaPay track ID | 用于识别 OxaPay 付款会话 |
| 交易 ID 或 TXID | 用于识别区块链交易 |
| 加密货币 | 确认发送了哪种资产 |
| 区块链网络 | 确定应在哪个网络中搜索交易 |
| 已发送金额 | 识别少付或金额不匹配 |
| 大致付款时间 | 缩小调查范围 |
| 预期结果 | 显示客户是在等待交付、账户入账、续订还是其他结果 |
商户创建 OxaPay 发票时，可以加入自己的 order_id。OxaPay 还会提供 track_id，商户之后可使用它检索对应的 Payment Information 记录。
Order ID、track ID 和 TXID 结合起来可提供三个不同视角：
- Order ID：客户原本要购买什么；
- Track ID：支付网关如何表示这笔付款；
- TXID：区块链上实际发生了什么。
OxaPay 文章 加密货币交易 ID 详解 以便于客户理解的方式介绍如何找到并使用 TXID 来追踪转账。
第 2 步：确认 TXID 有效
钱包截图显示“已发送”并不能证明钱包已经成功将交易广播到网络。
直接复制 TXID，并使用客户声称使用的网络对应的区块浏览器进行搜索。
检查以下情况：
- 区块浏览器能够识别该 TXID；
- 交易属于预期的区块链；
- 交易状态为 待处理、已确认、失败或仍未解决；
- 发送时间与付款尝试时间一致。
Ethereum 等网络会在用户提交交易时生成交易哈希。随后，网络会广播交易并等待其被打包进区块。Bitcoin 交易同样会在矿工将其打包进区块后获得确认。
如果找不到 TXID
可能的原因包括：
- TXID 复制错误；
- 客户正在错误的网络中搜索；
- 钱包在本地创建了交易，但没有广播；
- 钱包显示的是内部参考编号，而不是区块链 TXID；
- 交易从未成功提交。
请客户打开钱包中的交易详情，并确认准确的网络和 TXID。
如果找不到可验证的交易，不要将订单标记为已付款。
第 3 步：核对网络、资产、地址和金额
找到交易只是开始。交易必须与付款请求相匹配。
比较以下四项信息。
网络
确认付款是在结账时选择的网络上发送的。
对于 USDT 和 USDC 等可存在于多个网络上的资产，这一点尤其重要。在一个网络上发生的交易不会在另一个网络中搜索到。
资产
确认客户发送的是预期的加密货币或代币合约。
相同的地址格式有时可能存在于多个兼容网络中，但这并不意味着所有代币或网络路径都受支持。
目标地址
将区块链交易中的收款地址与付款请求中显示的地址进行比较。
发送到其他地址的已确认交易并不是从区块链上“丢失”了，而是通过了不同的路径。
金额
将实际收到的金额与要求的金额进行比较。
客户可能：
- 输入了错误的金额；
- 只支付了部分发票金额；
- 误解了哪些费用不包含在付款金额中；
- 发送了多笔较小交易，而不是一次完整付款。
专业支付网关在将一笔转账判定为有效付款之前，会评估网络、目标地址、代币、金额、时间和确认依据。
第 4 步：确定区块链状态
如果交易存在且付款详情正确，请确认其是否已达到可以接受的状态。
待处理或未确认
网络已经看到这笔交易，但它尚未达到所需的确认或最终性状态。
在这种情况下：
- 不要要求客户重新发送；
- 说明已经找到该交易；
- 为客户提供明确的下一次检查时间点；
- 按照商户的付款政策继续检查。
确认时间会因网络和当前状况而异。交易可见性和付款最终性不应被视为同一个事件。
已确认
已确认交易证明网络已经处理了该转账，但这并不能自动证明付款已经满足商户发票的要求。
地址、资产、金额、网络、发票时间以及相关付款记录仍必须相互匹配。
失败或未成功
如果区块浏览器显示交易失败，则付款没有按预期完成。
客服应解释已验证的结果，并让客户在再次尝试付款前检查钱包。商户不应仅根据一次转账尝试就把订单标记为已付款。
第 5 步：检查 OxaPay 付款记录
了解区块链证据后，使用 track ID 检查 OxaPay 记录。
在 OxaPay 中， Payment Information endpoint 可检索特定付款的详细信息。 Payment History 还可以按 track ID、状态、付款类型、资产、网络、金额、地址和日期范围进行筛选。
比较以下信息：
- OxaPay 状态；
- 预期金额和收到金额；
- 付款货币；
- 网络；
- 交易信息；
- 发票时间；
- 商户订单参考编号。
OxaPay 文档列出了 付款状态 ，包括：
- new；
- waiting；
- paying；
- paid；
- manual_accept；
- underpaid；
- refunding；
- refunded；
- expired。
状态可能表示什么
| OxaPay 状态 | 调查含义 |
|---|---|
| New 或 waiting | 尚未有符合条件的付款与该发票关联 |
| paying | 已经存在付款活动，但付款尚未被完全接受 |
| paid | OxaPay 已将发票接受为全额付款 |
| underpaid | 已经收到付款，但所需金额尚未补足 |
| expired | 发票未在有效付款时间内完成 |
| Manual accept | 商户手动接受了该付款 |
| Refunding 或 refunded | 付款正在退款流程中，或退款已经完成 |
如果 OxaPay 显示 paid，而客户订单仍显示未付款，那么调查重点已经不再是区块链。此时更可能是商户的订单更新、集成或履约流程出现问题。
第 6 步：将付款与商户订单进行比较
检查 OxaPay 付款记录是否关联到正确的内部订单。
核对：
- 已保存的 order ID；
- 已保存的 track ID；
- 预期金额；
- 客户或账户；
- 订单状态；
- 履约或账户入账状态；
- 任何手动修改或之前的客服操作。
这一步通常会得到三种结果之一。
付款正确，但订单没有更新
这笔付款并不是真的缺失。商户系统未能把付款状态转化为预期的业务操作。
如果集成依赖 callback，请检查 OxaPay Webhook 设置 和投递路径，再判断是否属于区块链问题。
将完整的标识符和当前状态一起升级给 Payment Operations 或 Engineering 团队。
付款关联到了错误的订单
不要在没有记录决定的情况下悄悄移动付款。
确认正确的客户和订单，通过批准的流程修正关联，并保留审计记录。
无法可靠匹配任何订单
将付款放入异常队列。使用金额、时间、地址、客户信息和 TXID 作为辅助证据；如果现有数据可能匹配多个订单，不要猜测。
详细的匹配流程将在 How to Match Orders, Track IDs, and Blockchain Transactions 中介绍。
第 7 步：分类根本原因
调查结束时，该案例应具有明确分类。
| 调查结果 | 可能原因 | 下一步操作 |
|---|---|---|
| 没有有效 TXID | 交易未广播，或参考编号不正确 | 让客户返回钱包核实 |
| TXID 存在，但交易仍待处理 | 网络处理尚未完成 | 继续监控并设置后续检查时间 |
| 网络、代币或地址错误 | 付款路径与请求不匹配 | 升级处理，但不要承诺可以追回 |
| 金额过低 | 少付 | 应用商户的少付处理政策 |
| 付款在过期后到账 | 延迟或过期付款 | 按照发票政策进行审核 |
| OxaPay 显示 paid，但订单显示 unpaid | 商户端同步或履约问题 | 内部升级处理 |
| 付款存在，但没有订单匹配 | 缺少参考编号或关联关系出现问题 | 创建一个对账异常 |
| 退款正在进行 | 原始付款已进入冲正流程 | 跟踪退款，而不是继续按付款接受处理 |
对于少付和过期发票，OxaPay 会根据具体情形和当前产品行为提供商户审核、接受、延期或退款等选项。 OxaPay 如何处理少付和过期发票 对这些情况进行了更详细的说明。
什么时候应该把案例升级给 OxaPay？
在以下情况下，应升级为服务商侧调查：
- 区块链交易与预期的地址、网络、资产、金额和时间一致，但没有对应的 OxaPay 付款记录；
- Payment Information 和 Payment History 显示相互冲突的结果；
- 付款状态与现有交易证据不一致；
- 退款或手动付款操作长期未解决；
- 商户无法根据现有文档解释服务商侧记录。
提交完整案例，包括：
- 在适用情况下提供 Merchant API 或账户参考信息；
- track ID；
- order ID；
- TXID；
- 资产和网络；
- 预期金额和收到金额；
- 付款时间；
- 当前 OxaPay 状态；
- 区块浏览器证据；
- 商户订单状态；
- 对不匹配情况的简要说明。
完整的升级信息可以减少反复沟通，并帮助区分服务商侧调查与客户、钱包或商户集成问题。
如何减少付款缺失案例
很多付款缺失调查都源于参考信息不足或客户指引不清晰。
商户可以通过以下方式减少未来的案例：
- 创建付款时保存 order ID 和 track ID；
- 清楚显示资产、网络、金额和付款截止时间；
- 结账后保留付款记录；
- 使用有意义的付款状态向客户提供更新；
- 监控已 paid 但仍未履约的订单；
- 维护一个共享异常队列；
- 测试延迟、少付、过期和付款失败等场景；
- 培训客服索取正确的证据。
在 OxaPay 中， Generate Invoice endpoint 支持内部 order_id，而 Payment Information 和 Payment History 可帮助商户检索并审核付款记录。这些参考信息共同形成更完整的调查链路。
OxaPay 如何支持付款缺失调查
OxaPay 提供多层付款可见性：
- order_id：商户内部参考编号；
- track_id：OxaPay 付款会话标识；
- Payment Information：特定付款的信息；
- Payment History：更广泛的账户级搜索；
- 已记录的付款状态；
- 针对少付和过期情况的发票处理功能。
这些工具可以帮助商户判断报告的付款是缺失、待处理、少付、过期、无法匹配，还是已经被接受。
商户仍负责将付款与自己的订单、客户、履约和客服记录关联起来。
先调查付款，再决定处理结果
应把付款缺失视为证据问题，而不是基于假设判断。
正确的调查顺序是：
- 收集 order ID、track ID 和 TXID；
- 确认交易存在于预期网络；
- 比较资产、地址、金额和时间；
- 确定交易是待处理还是已确认；
- 查看 OxaPay 付款记录；
- 将其与商户订单和履约状态进行比较；
- 分类根本原因并分配正确的下一步操作。
这一流程可避免重复付款、错误履约、不受支持的追回承诺以及长期未解决的客户案例。
OxaPay 加密货币支付网关 为商户提供追踪付款活动所需的付款参考信息、状态记录和历史数据。将这些能力接入一致的调查流程，让客户获得清晰答复，并确保每笔付款最终都有可记录的处理结果。
