如何防止加密货币付款选错网络：商家事故处理手册

一笔交易即使已在区块链上确认，也不一定符合商家要求的付款条件。客户可能通过错误的网络发送了金额和币种均正确的代币，也可能向预期地址发送了另一种代币、少付了金额，或将资金转到了无关地址。客服团队必须区分确实发生了转账的证据与订单已正确付款的证据。

这是一份面向商家的运营处理手册，并非钱包资金找回教程。内容涵盖事故预防、证据收集、区块浏览器核查、事故分类、补付请求、防止重复付款以及客户沟通。面向付款人的简版转错网络常见问题仍可供客户参考；本文则说明商家在回复客服消息后还需要完成哪些工作。

交易已确认不等于付款已获认可

区块链会按照该网络的规则确认交易。只有当实际发生的转账与付款请求相符，并达到商家规定的接受状态时，付款流程才会认可这笔付款。

对于正常付款，请核对以下所有字段：

Circle 的区块链确认参考资料说明，交易最初会处于待处理状态，不同区块链的确认机制各异，而且近期区块可能受到链重组影响。因此，交易哈希、钱包截图或“成功”页面只能作为调查线索，不能单独作为交付依据。

区分主要事故类型

客户常把所有不匹配情况都称为“选错网络”。请先根据事实分类，再选择处理方式。

不要因为代币代码看起来熟悉，就认定资产正确。Circle 将 USDC 称为在多条区块链上发行的数字美元，Tether 则发布了最新的支持 Tether 代币的协议列表。这些发行方的列表并不能说明 Yolfi、你的钱包或你的企业支持哪些组合。只提供 Yolfi 实际配置中显示的资产与网络组合。

在客户签名之前预防事故

防止选错网络，最有效的流程始于支付环节，而不是客服环节。

将资产与网络视为一种完整的付款方式

不要只把选项标为“USDC”或“USDT”。应在所有环节使用“[所选网络]上的 USDC”这类组合标签，包括选项选择、确认页面、二维码说明、跳转钱包、收据、客服记录和对账导出数据。

USDC 收款指南和 USDT 收款指南解释了为什么网络选择是付款方式的一部分。公开说明只应列出付款流程中当前可用的组合，而不是发行方提供该代币的全部网络。

在作出决定的环节重复关键信息

在钱包签名前，应显示：

• 准确的资产名称和代码；
• 准确的网络名称；
• 准确的金额；
• 收款地址，并提供复制功能；
• 订单或付款编号；
• 到期时间或时限规则（如适用）；
• 明确警告客户，不要因为地址看起来相似就选择其他网络；
• 提醒客户发送后返回付款状态页面。

不要告诉用户切换网络就能转移代币。更改钱包中选定的网络，只会改变钱包显示并交互的区块链，不会把已有余额从一条链转移到另一条链。通过跨链桥或交易所提现属于另一项独立操作，有其自身风险和客服责任边界。

减少不必要的选择

只启用客户确实会用且团队有能力支持的选项。每增加一个组合，就会多出一个结算地址、代币标识、区块浏览器、确认规则和异常处理路径。请在 Yolfi 实际配置中检查可用选项，并通过区块链目录查看 Yolfi 针对各网络的页面。

对每个已启用的组合进行一次真实的小额测试。确认支付标签、收款地址、钱包提示、区块浏览器记录、状态变化、通知或 Webhook、对账记录和交付行为均符合预期。

建立事故证据包

一次性索取足够的信息。反复要求客户补充资料会拖延处理，也可能促使客户尝试未经批准的解决办法。

客户必须提供的证据

• 付款链接网址或付款编号；
• 订单、发票或账户编号；
• 交易哈希，以及区块浏览器链接（如有）；
• 客户认为自己发送的资产和金额；
• 客户实际选择的网络；
• 付款钱包地址；
• 大致转账时间。

商家端证据

• 原付款请求显示的资产、网络、金额和收款地址；
• 请求创建、过期、检测和状态变化的时间戳；
• 为所请求组合配置的结算地址；
• 相关付款通知、Webhook ID 和处理结果；
• 独立核查所得的实际使用网络的区块浏览器结果；
• 客户消息以及团队发出的说明；
• 与同一订单关联的原付款编号和补付编号；
• 已执行的交付、入账、退款或访问权限操作。

截图可能被篡改、已经过时，或截自错误的网络。可以用截图定位交易，但随后必须独立核查这笔交易。

在正确的区块浏览器上核查转账

先从客户声称使用的网络入手，但要根据区块浏览器数据确认实际网络。MetaMask 的转错目标地址指南也建议先检查交易状态和区块浏览器，再判断实际发生了什么。

1. 打开实际使用网络上可信的区块浏览器。
2. 搜索完整的交易哈希。不要相信链接显示的文字；请根据内部流程核实区块浏览器域名。
3. 检查交易状态是待处理、成功、失败、已丢弃还是已被替代。
4. 逐字核对发送地址和收款地址。
5. 核对转入资产。如果是代币转账，应核对合约或铸币地址，而不能只看代币代码。
6. 核对转账事件中记录的代币原始数量。小数精度应另行通过官方合约或铸币地址，或可信区块浏览器的元数据确认。
7. 记录区块、时间戳、当前确认数或最终确定状态，以及所有相关日志。
8. 将每个字段与原付款请求逐一对照。
9. 在同一网络上检查结算钱包或钱包监控记录。
10. 搜索内部记录，确保该哈希尚未在其他位置被识别或使用。

Circle 的 EVM USDC 转账快速入门展示了选择区块链、提交转账、获取哈希和查看区块浏览器这些相互独立的步骤。该指南还指出，发送方需要用该网络的原生代币支付网络费用。请只将其视为转账机制的示例，不要把它当作 Yolfi 账户中可用组合的清单。

使用决策树，不要承诺找回资金

请按顺序判断以下分支。

1. 客户声称使用的网络上是否存在有效交易？

• **不存在或仍在待处理：**不要交付订单。在持续监控期间，或等待客户的钱包服务商处理待处理交易期间，请客户不要再次付款。
• **失败或已回滚：**这笔交易没有成功完成付款。发起补付请求前，应先确认客户钱包和区块浏览器中的状态。
• **成功：**继续核对各字段。

2. 网络、资产、收款地址、金额和确认政策是否全部匹配？

• **是：**通过正常的付款识别流程和幂等交付控制处理。
• **否：**转入异常审核。不要仅因为有价值发生了转移就手动标记为已付款。

3. 商家是否控制实际使用网络上的收款地址？

• **尚未确认：**不要声称已收到资金或能够找回资金。将问题升级给负责该地址的钱包所有者或托管方。
• **是：**确认该地址确实持有相应资产，并能按照商家的钱包、安全、会计及合规流程安全处理。控制该地址并不代表原订单已被正确支付。
• **否：**向客户说明，商家无法转移不受自己控制的地址中的资金。Ethereum.org 的客服常见问题指出，以太坊交易无法由中心化运营方撤销；如果收款地址由已知服务机构控制，该机构的客服团队可能才是合适的联系对象。

4. 是否已批准补救方案？

可能的处理结果包括：手动认可转账、要求客户正确补付、通过一笔新交易退回可动用的资金、给予有据可查的余额抵扣，或拒绝找回。正确做法取决于网络、地址控制权、代币、托管安排、技术能力、成本、风险审查和业务政策。

切勿声称资金“一定丢失”或“一定能找回”。MetaMask 记录过一种常见的 EVM 情况，即同一钱包地址或许可以在另一个兼容 EVM 的网络上访问，但也说明有些情况无法保证能够找回。这类指南不能证明商家、交易所、智能合约、多重签名钱包或支付系统一定能够访问或退回某笔具体转账。

安全发出补付链接

如果原付款请求无法获得认可，而政策允许客户再次尝试，请创建新的 Yolfi 付款链接。不要修改历史记录，也不要只告诉客户“再试一次”。

补付请求应做到：

1. 沿用同一订单号或发票号；
2. 使用全新的唯一付款编号；
3. 写明实际付款流程中显示的准确资产、网络、金额和收款地址；
4. 将之前的请求标记为已被取代或正在审核；
5. 说明原交易仍作为独立事故处理；
6. 告知客户不要同时支付两个链接；
7. 保留所有到期规则；
8. 交付前，将两个请求都纳入重复付款检测。

不要让客户补付无法追踪的差额，不要让客户向聊天消息中复制的地址重新付款，也不要把发送后切换网络描述成能转移原资金。

防止重复付款和重复交付

补付请求创建后，延迟的原交易仍可能获得确认。客户也可能在等待客服处理期间连续付款两次。流程设计必须能应对这两种情况。

使用同一个业务层面的订单号关联多次不可更改的付款尝试，并执行以下控制：

• 每个交易哈希最多只能识别一次；
• 一次付款尝试不能用于多个订单；
• 一个订单只能触发一次交付或访问权限开通；
• 原付款请求与补付请求始终保持关联；
• 交付前立即检查所有未结付款尝试；
• 延迟确认和多收款项进入审核；
• Webhook 和通知处理必须具备幂等性；
• 退款必须另行审批，并核实收款地址、保留交易记录。

如果两笔转账均成功，不要删除其中一笔，不要悄悄将其用于另一笔购买，也不要自动向客户在新客服消息中提供的地址转账。应冻结重复交付，并遵循有据可查的余额抵扣或退款政策。

制定商家客服与安全规则

为一线客服提供标准话术并明确升级处理边界。

客服可以索取公开的交易数据、付款编号、订单详情，以及不会暴露秘密信息的截图。客服绝不能索要助记词、恢复短语、私钥、钱包密码、一次性验证码，也不能要求远程控制客户设备。任何人获得助记词或私钥后，都可能控制该钱包。

可以采用以下措辞：

我们看到一笔交易已在[网络]上提交，目前正在核查其资产、收款地址、金额和确认状态是否与付款请求[编号]相符。在我们提供新的获准付款链接或确认下一步操作前，请勿再次付款。我们不会索要您的助记词或私钥。

为确认受理、证据审核、升级处理、审批和客户进度通知设定时限。在确认能够访问资金且交易具备可行性之前，不要承诺找回日期。

Yolfi 是一项非托管服务：付款会直接进入商家配置的钱包，而非由 Yolfi 保管。因此，正确配置钱包、明确访问控制权并制定商家端事故处理政策至关重要。

商家事故处理清单

开始收款之前

• 在每一步同时显示资产和网络。
• 只启用 Yolfi 实际配置中可用的组合。
• 核实每个结算地址和代币标识。
• 对每条已启用的支付路径进行端到端测试。
• 制定确认、不匹配、重复付款、退款和升级处理规则。
• 培训客服人员，禁止索取钱包秘密信息。

收到事故报告时

• 暂停交付，并劝阻客户重复付款。
• 保留原付款请求和客户报告。
• 建立证据包。
• 在实际使用的网络上核查交易。
• 对比网络、资产、收款地址、金额、状态和确认情况。
• 核查地址控制权，但不要假定资金可找回。
• 搜索以往的识别记录和关联付款尝试。
• 记录获批的处理决定及发给客户的消息。

常见问题

交易已经确认，付款仍有可能处于未支付状态吗？

是的。确认只能证明某个网络处理了这笔交易。付款要获得认可，还必须与要求的网络、资产、收款地址、金额和编号相匹配，并符合商家的确认政策。

切换钱包网络能找回或转移资金吗？

不能。切换选定网络只会改变钱包显示并交互的区块链，不会在网络之间转移代币。在某些 EVM 情况下，同一地址的所有者或许能在实际使用的网络上看到资产，但之后进行转账或跨链是另一项独立操作，并不保证可用或适宜。

应该要求客户立即再次付款吗？

不应该。首先要确定原交易是待处理、失败、成功还是存在字段不匹配。如果获准再次尝试，应发出新的关联付款请求，并针对两次尝试启用重复付款检测。

Yolfi 能找回转错网络的付款吗？

不能想当然。在非托管流程中，资金会进入商家配置的钱包。可采用的补救方法取决于实际收款地址、网络、资产、钱包控制权、技术能力和商家政策。

如果客户使用了正确的网络，但转错了代币，该怎么办？

应作为币种错误事故处理。核对代币合约或铸币地址、金额、收款地址及钱包到账记录，然后按照规定的异常处理流程操作，不要直接将订单标记为已付款。

如果交易仍在待处理，该怎么办？

保持订单待处理状态，不要交付。按照确认政策监控区块浏览器和付款状态。在待处理交易产生结果或受控补付方案获得批准前，劝阻客户再次转账。

仅凭截图足以批准交付吗？

不足以。使用哈希定位交易，并在正确的区块浏览器上独立核查。随后将交易与付款请求进行匹配，并确认它尚未被使用。

结语

防止选错网络，需要明确无歧义地标示资产、网络、收款地址、金额和确认状态。处理事故则需要经过核实的交易数据，谨慎检查钱包控制权，不承诺找回资金，并防止重复付款。

先从 Yolfi 实际配置中显示的组合着手，逐一测试，并为客服提供统一的决策树。确需客户再次付款时，应创建关联的补付请求，而不是通过聊天临时给出做法。目标是准确识别正确付款、只交付一次，并保留每项异常处理决定。