稳定币少付、多付或发错网络：如何处理支付不匹配

客户说已经付款，发来交易哈希，而且区块浏览器里确实能看到转账，但你的订单仍停留在 created。这不一定是扫描故障。转账可能真实存在，却没有满足付款指令：金额可能少了或多了，资产或网络可能选错了，也可能在订单过期后才到账。

安全原则很简单：不要靠猜测把一笔“看起来差不多”的转账认定为已付款。订单仍有效时，链、资产、收款地址和金额必须全部精确匹配。其他转账一律留在自动履约路径之外，根据链上证据调查，再按成文的退款、补收或人工入账规则处理。在非托管系统中，到达商户地址的资金仍由商户控制；严格匹配阻止的是含糊履约，并不妨碍商户找回资金。

为什么少付后订单仍未完成

付款指令是一组完整条件，而不是参考建议：

支付订单
  链 + 资产 + 收款地址 + 精确金额 + 过期时间
                              |
                              v
观察到转账 -------- 订单为 created 且精确匹配？--------------- 是
                              |                            |
                              否                           v
                              |                 payment.detected
                              v                            |
                     未匹配链上事件              confirmed -> finalized
                              |
                              v
                    人工核对；订单随后过期

StableOps 会按代币精度把金额换算成最小单位后比较。对于 10.00 的订单，9.99 和 10.01 都不匹配；先后两笔 6.00 和 4.00 也不会自动合并成一次精确付款。共享收款地址尤其需要这条规则：如果允许“差不多”或任意合并转账，系统就可能把一位客户的资金分配给另一位客户的订单。

完整的匹配边界如下：

任意一项不匹配，StableOps 都不会为该订单发送 payment.detected。订单会继续等待精确付款，直到过期。这种严格性是一项保障：它防止一笔含糊的转账擅自改变价格、库存、权益、账务或共享地址的归属。

先确认究竟发生了什么

不要一上来就退款。先建立一份客服、工程和财务都能共同使用的证据记录：

• StableOps 支付订单号和你的 merchantOrderId；
• 客户提供的交易哈希；
• 客户在钱包里实际选择的链，而不只是资产名称；
• 规范链记录里的代币合约或铸币地址、目标地址与最小单位金额；
• 订单金额、接受的 (chain, asset) 组合、已分配地址与 expiresAt；
• 当前回执状态、区块哈希与最终性状态。

请在客户实际使用的链对应的区块浏览器中检查交易。把其中的代币转账日志与原始付款指令比较，不要只看钱包里的“成功”页面。一笔成功交易可能并未包含符合条件的代币转账；同一个 0x… 目标地址也可能同时存在于多条 EVM 链上。

StableOps 会收集可能的错付金额供人工核对

商户不必等到客户提交工单后才发现每一笔错误金额。StableOps 会扫描转入受监控商户收款地址的受支持代币；即使金额不一致导致转账无法匹配订单，对应的规范化链上事件仍会保留。

打开控制台 → 订单 → 对应订单。对于尚未最终完成的订单，如果 StableOps 找到同时满足以下条件的候选事件，页面会显示“可能相关的转账”卡片：

• 事件属于同一组织与环境；
• 事件尚未关联任何支付订单；
• 链、资产与目标地址匹配该订单历史上的某条付款指令；
• StableOps 在订单创建与过期之间检测到该事件；
• 按代币精度换算后，事件金额不同于 order.amount。

卡片会展示交易、资产、金额、确认数与检测时间，方便运营人员打开事件详情并与客户说法核对。候选事件根据当前记录动态计算，而不是复制到订单中；如果某条事件后来关联到任何订单，它会自动从该列表消失。

这项收集能力只是调查线索，不是自动关联。它不会改变订单状态、合并多笔转账、发送 payment.detected 或移动资金。只有精确匹配才能进入自动支付生命周期。

发错网络、发错资产或过期后到账，可能需要搜索更广的链上历史。只有相应的链、资产与地址当时处于扫描范围内，这些事件才会出现在 StableOps 中；最终仍应以规范链记录为准。payment.expired 只表示截止时间前没有精确匹配到账，并不能证明客户什么都没转。

各类不匹配的处理矩阵

可以直接把下表作为一线客服操作手册的起点。

以上六种情况都不应修改自动订单。人工入账应记录在商户自己的业务账本中，并关联原订单、异常原因、审批人及所有相关交易哈希。不要改写原始支付事件，也不要把未匹配的 StableOps 订单人工伪装成 finalized。

少付：补差额不会让原转账自动凑够

最常见的客服错误，是让客户“再补 0.01”，并期待原订单随之完成。精确匹配会分别判断每一笔转账。如果订单要求 10.00，9.99 不匹配，后来补的 0.01 同样不匹配。

应明确选择以下三种规则之一：

1. 退回部分付款。 当自动履约与账务必须保持一笔订单对应一笔转账时，这是最清晰的选择。
2. 人工计入部分付款，再单独补收余额。 为剩余金额创建新支付订单，然后在商户账本中把两笔交易哈希关联到业务订单。原 StableOps 订单仍会过期，最终结清业务义务的是你的人工账务决定。
3. 把短缺金额作为人工调整。 仅适用于财务事先批准且有成文规则的容差。应记录调整，不要放宽平台的精确匹配规则。

如果客户在原订单仍有效时又发送一笔完整的精确金额，第二笔转账可以匹配。第一笔部分付款仍然是需要退款或单独入账的异常，因此这种做法可能暂时收到超出预期的资金。

多付：事先决定退差额还是全额退回

多付款项不是“一笔成功付款加上一笔可以自动退回的余额”，而是一笔金额与指令不符的转账，所以订单不会推进。

你的规则可以把订单要求金额人工入账并退还多余部分，也可以全额退回后让客户重新付款。前一种做法会产生拆分账务：同一笔入账交易同时覆盖销售收入和退款负债。应保存实际到账金额、入账金额、退款金额、退款交易哈希、网络手续费承担方式和审批人。

绝不要不加核对就把资金退到交易的 from 地址。交易平台提币、智能合约钱包和中继服务可能从无法识别客户或无法为客户入账的地址发款。应让客户提供同一网络上的退款地址，验证地址格式，并在发出新链上交易前完成地址归属、制裁筛查与审批。退款是一笔新转账，链上支付无法原地撤销。

发错网络：地址看起来有效，网络仍可能错误

多条 EVM 链之间最容易发错网络，因为同一个 0x… 地址在 Ethereum、Base、Arbitrum、Polygon、Optimism 与 BNB Chain 上都有效。如果客户把 Ethereum USDC 发到 Base USDC 指令展示的地址，资金可能已经到达由商户私钥控制的地址，但它位于 Ethereum 上，不能满足 Base 付款指令。

承诺可以找回之前，应确认以下全部事实：

• 交易确实位于客户所说的网络，并拥有成功的规范链回执；
• 代币转账日志指向准确的商户地址；
• 商户能在实际网络上操作同一个地址；
• 资金钱包备有该网络的燃料代币，并支持收到的代币合约。

在不兼容的地址族之间，钱包通常会在广播前拒绝目标地址。如果交易确实广播成功，应根据实际链上记录与私钥控制关系判断，不能仅凭页面显示的地址做假设。StableOps 从不持有商户私钥，因此无法替商户签署找回资金的交易。

发错资产：估值前先验证合约

钱包显示“USDC”或“USDT”并不足以确认资产。资产身份取决于特定链上的代币合约或铸币地址。仿冒代币、跨链版本、不受支持的合约或完全不同的资产，不能只因符号相同就按订单要求的稳定币估值。

请根据支持资产表和你的资金规则核对合约。如果资产真实且能够找回，再人工决定估值与退款路径。如果资产不受支持、缺乏流动性、带有恶意行为，或资金钱包无法安全转出，应升级处理，不能向客户保证一定可以找回。

过期后到账应进入异常队列

订单截止时间只在订单为 created 时生效。过期任务把订单推进到 expired 后，已分配地址会释放回地址池，并发出 payment.expired。此后到达的转账无法重新激活订单。该地址可能已经出现在另一笔订单的付款指令中，所以迟到转账必须根据交易哈希、时间和地址分配历史对账，不能只看地址。

应让客户停止继续使用旧指令。如果客户仍需付款，应创建一笔具有新有效期的新订单。迟到资金通过退款或人工入账单独处理，原过期订单保持不变，以保留审计记录。订单过期常见问题记录了准确的生命周期。

付款回滚不是退款场景

payment.reverted 与所有未匹配转账不同。订单之前确实匹配到一笔转账，但该交易回执后来失败，或发生链重组后，实时回执的区块哈希不再等于事件入库时保存的哈希。在规范链上，这笔付款已经不再成立。

此时可能根本没有资金可退。只撤销此前的乐观界面、库存预留或其他可逆操作；核对规范链状态后，如果客户仍需付款，再创建新订单。不可逆履约应等待经过验签和去重的 payment.finalized 事件。有关最终性边界，请阅读稳定币支付确认数；有关安全处理重放，请阅读稳定币支付 Webhook。

让异常处理留在自动履约之外

下面这个简短的 TypeScript 判断函数展示了这条边界。它比较已经归一化的事实，不会改动支付订单，也不会假装多笔转账能够组成一次付款。

type PaymentFacts = {
  expected: { chain: string; asset: string; address: string; amountMinor: bigint }
  actual: { chain: string; asset: string; address: string; amountMinor: bigint }
  orderOpen: boolean
}

export function routePayment(facts: PaymentFacts) {
  if (!facts.orderOpen) return { outcome: 'manual_review', reason: 'order_not_open' } as const
  if (facts.actual.chain !== facts.expected.chain)
    return { outcome: 'manual_review', reason: 'wrong_network' } as const
  if (facts.actual.asset !== facts.expected.asset)
    return { outcome: 'manual_review', reason: 'wrong_asset' } as const
  if (facts.actual.address !== facts.expected.address)
    return { outcome: 'manual_review', reason: 'wrong_address' } as const
  if (facts.actual.amountMinor < facts.expected.amountMinor)
    return { outcome: 'manual_review', reason: 'underpaid' } as const
  if (facts.actual.amountMinor > facts.expected.amountMinor)
    return { outcome: 'manual_review', reason: 'overpaid' } as const

  return { outcome: 'continue_confirmation', reason: 'exact_match' } as const
}

在生产环境中，应根据已验证代币的精度换算两边金额，再比较整数；绝不要用 JavaScript 浮点数表示代币金额。在进入这层业务比较前，还要保留组织与环境隔离。StableOps 的实际匹配器会在服务端强制执行这些边界。

预防核对清单

• 原样展示返回的 order.amount。使用自动金额调整时，它可能与最初请求的金额略有不同。
• 从客户所选的 paymentInstructions 项读取链、资产和地址；绝不脱离网络单独展示地址。
• 禁止编辑金额，并用同一组返回值生成钱包请求或二维码。
• 当钱包中可能出现同名资产时，展示代币合约或铸币地址。
• 提醒 EVM 用户在签名前再次核对当前网络。
• 过期窗口要足够等待真人操作或交易平台提币到账，但不要让已放弃订单无限期占用地址。
• 在经过验签和去重的 payment.finalized Webhook 到达前，停止不可逆履约。
• 允许客服只读查看订单详情、可能的错付事件和区块浏览器；退款签名必须经过资金审批。
• 上线前确定少付、多付、发错网络、发错资产、迟到付款以及退款手续费规则。
• 每笔人工入账和退款都应关联 merchantOrderId、支付订单号、入账交易哈希及退款交易哈希。

有关多链 USDT 结账与精确展示付款指令的完整设计，请阅读如何可靠接受 USDT 付款。

常见问题

客户少付、多付或发错链后会怎样？

订单不会推进，因为这笔转账至少缺少一个精确匹配键。到达商户控制地址的资金仍由商户控制，但退款或人工入账发生在自动订单生命周期之外。金额或链错误常见问题给出了产品行为与找回步骤。

订单过期后才收到付款会怎样？

付款不会重新激活订单。地址已经释放，而且可能已被复用，因此应按交易哈希和分配历史对账，再人工退款或入账。客户再次尝试时应使用新订单。详见订单何时过期。

已确认的稳定币付款还会回滚吗？

会。处于 detected 或 confirmed 的付款仍可能因回执失败或链重组变成 reverted。应把 payment.reverted 当作回滚信号，而不是持有可退款资金的未匹配付款；不可逆履约应等到 payment.finalized。付款回滚常见问题解释了两者的区别。

把第一次客服工单变成可复用操作手册

以金额或链错误常见问题为起点，补上订单过期与付款回滚分支，并为上文处理矩阵的每一行指定负责人和审批规则。然后在沙盒环境中分别测试一次少付、多付和订单过期。不匹配付款应该留下证据并进入受控异常流程，而不是导致意外履约。