转错网络、付错代币，买家那笔钱最后落在哪

在 Paymos，买家 USDT 转错网络或者付错代币，这笔钱不会就此消失，结局只有三种。同一种代币从账单也收的另一个网络转来，自己就会一比一付清账单。Paymos 在那个网络上收的另一种代币，会自己计入你的余额，只扣正常服务费，不用提工单，也没有找回费；账单则等付款窗口走完，然后过期。只有账单不收的代币或网络，以及低于网络最低额的转账，不会自己到账。

碰上的是哪一种，决定了你怎么回复买家，也决定了订单系统下一步做什么。金额对不上时 Paymos 怎么处理，写在多付和少付那篇里。这篇讲另一类钱：它到了账单地址，却没有付清账单。Paymos 怎么处理它，怎么通知你，你的服务器又会收到什么。

买家从另一个网络付款，Paymos 怎么处理？

一比一算进账单。Paymos 收这种代币的网络，几乎都是这样。

转错网络这件事，要从地址说起。以 0x 开头的地址，在所有跑以太坊虚拟机（EVM）的网络上都是同一串字符。MetaMask 帮助中心说得很直接：助记词「generates the same address across all EVM-compatible networks」。 收银台显示的是 Polygon 上的地址，买家在交易所的提币页面却选了 BNB Smart Chain，这笔转账照样到了同一个地址，只是换了条链。

Paymos 把这笔转账算进账单，就当买家选对了网络。账单关闭，你的端点收到的事件和选对网络时一样，订单照常发出，你和买家都不用做什么。几个网络之间到底差在哪，另有一篇对比。

如果 Paymos 在那个网络上收这种代币，付款却没有算进账单，钱会记在账单外、进你的余额（前提是不低于网络最低额），账单到期照常过期。这笔转账单独或连同之前付的部分凑够账单金额时，你的端点随后会收到 invoice.paid_late。账单状态不变，paid_late_at 记下凑够金额的时间，订单发不发由你决定。

Tron、TON 和 Solana 各有自己的地址格式，别的网络的钱包不接受它做收款地址。所以真正打到账单上的转错网络，都发生在 EVM 链之间。

买家付错了代币，钱去了哪？

进了你的余额，前提是 Paymos 在这笔钱来的那个网络上收这种代币。不用提工单，也没有找回费。唯一扣掉的是正常服务费，和任何结算完的付款一样，费率在价格页。

按 USDT 开的账单收到 USDC，入账的就是 USDC，金额是转来的数减去这道服务费。不兑换成别的币，也不套汇率把它凑成账单金额。 这笔钱没有付清账单，以后也不会算进账单金额，所以也不会有 invoice.paid_late。这条入账标为付错了代币，背后的订单等你拍板。

算数的是组合：这种代币，在这个网络上。同一种代币在每个网络上都是单独的合约，发行方也各自列着支持的网络，USDC 看 Circle 的清单，USDT 看 Tether 的。 Paymos 收哪些组合，见 USDT 页面和 USDC 页面。生意上为什么会偏向某一种美元代币，是另一篇对比的话题。

钱在余额里，订单怎么被取消了？

因为账单过期了，你的服务器照着过期处理了订单。集成要改，只改这一处。

账单外的入账没有自己的 webhook：事件目录里账单的九个事件，没有一个讲入账。 可钱没付上的那张账单，付款窗口照样会走完，Paymos 也照样给它发 invoice.expired，文档里的说明是「账单过期，没有合格付款」。 这句话没错，只是它一个字也没提已经躺在你余额里的那笔钱。

所以今天该回头看的，是处理过期的那段代码。回库存、释放座位、取消订单、发邮件告诉买家没收到付款，这些动作现在都可能落在有人付过钱的订单上。

// invoice.expired 说的是账单没付清，
// 不是没人往它的地址转过钱。
if ($event['event_type'] === 'invoice.expired') {
    holdForReview($event['data']['invoice_id']); // 不取消，不回库存
}

过期的订单先挂起，等人看过再动，放在普通的过期上也是更稳的默认做法。这和幂等那篇讲的是同一个道理，只是从另一头走过来。

挂起的订单之后可能等来第二个信号。账单那种代币的钱，不管是过了期限才转来，还是从别的网络转来，只要最后凑够金额，同一张账单就会收到 invoice.paid_late。状态仍是 expired，这个事件本身什么都不改：把它记成挂起订单上的一条备注，提醒审单的人再看一眼。别的代币不会触发它。

Paymos 怎么通知你这笔入账？

通知跟入账一起发出：邮件，控制台铃铛，绑定了 Telegram 联系人的再加一条 Telegram 消息，走的和转出通知是同一个收件箱。里面有实际进余额的净额，服务费单独一行，还有代币、网络、原因，以及进入控制台的链接。

在余额页，这类入账和你的转出排在「收支明细」的同一张表里，按类型筛选就能分开。每一行都写明这笔钱是按账单来的还是没有账单，以及属于哪种情况：付错代币、转错网络、过了期限才付、账单已经关闭，或者地址没有对应的账单。金额前带 +，是实际进了余额的数。点开一行，会展开「转账金额」「服务费」「入账金额」，地址所属的「账单」或者「无账单」，「发送方」「交易」，还有简短的说明。背后那笔原始转账没观测到时，这里写的是「发送方未知」和「交易哈希未知」，之后查到的信息会补到同一行上。

入账本身没有 webhook，也没有 API 接口，集成只能从控制台和邮件里得知。这类钱能引出的事件只有一个，就是上面说的 invoice.paid_late。

订单和这笔钱，接下来怎么处理？

由你决定，做决定要用的东西 Paymos 已经摆在你面前。不管选哪条路，账单都停在 expired，收到过 invoice.paid_late 也一样；你选的是订单的去向。

发货，就是在你自己的系统里手动关掉订单。付款凭证是那条入账记录，不是账单状态。把这一行的信息抄到订单上，放在团队下次对账会看的地方。

退款，是从你余额发出的转账，金额、代币和网络由你定。没有什么会自动退回去，产品也没有向付款人承诺过退款。这一行给了你要用的材料：到账多少，扣了多少服务费，已知的话还有发送方地址和交易哈希。

答应买家之前，先想清楚两件事。余额里的是到账金额减去服务费，想按原数退回，差额得你自己出。发送方未知的话，就没有地址可退。

什么情况下钱不会自己到账？

三种情况，哪一种都不会自动入账。

Paymos 在那个网络上不收的代币，比如 Tron 或 TON 上的 USDC、Base 上的 USDT。这样的转账不会入账。能收哪些组合，见 USDT、USDC 和网络列表。

账单不收的网络。 对 0x 开头的地址，真正容易出的错就在这里：同一个地址在每条 EVM 链上都存在。ERC-7828 是以太坊自家提案流程里的标准草案，它描述的前景是「hundreds, and eventually thousands, of L2s that share the same address format as Ethereum mainnet」。 这比 Paymos 收的网络多得多。在这样的链上转出的钱，就留在那条链上的那个地址里。

低于网络最低额的金额。 某个代币和网络的最低额高过账单金额时，Paymos 收银台一开始就不让选，所以在页面给出的网络上全额付款，碰不到这条线。 碰得到的是小额的部分转账，还有绕到最低额更高的网络上的转账。低于最低额的金额不入账，由客服接手。

已经转错的买家，该怎么做？

联系卖家，带上四样东西：订单号、代币、网络和交易哈希。已经确认的转账，买家这边没有办法撤回。区块链付款没有可以申请的撤销，发出这笔钱的钱包也拉不回来。

该找的是卖家，因为每一种结局最后都落到卖家那里。付款付清了账单，订单本来怎么发就怎么发。钱记在了账单外，它就在卖家的余额里，怎么办由卖家定。钱没有自己到账，客服第一个要的就是交易哈希。买家也可以在付款页联系 Paymos 客服，客服那边能把卖家拉进来，需要的还是这四样。

四样里最要紧的是交易哈希。有了它，一步就能找到这笔付款，不用靠金额和时间去对。

这和多付、少付有什么不一样？

区别在于背后有没有账单。

多付和少付，在 Paymos 里都是账单的状态。每一种都有集成读得到的状态，也有能订阅的事件：invoice.paid_over、invoice.underpaid、invoice.underpaid_waiting。它们背后都有一张确实存在的订单，还在等着什么。 这两种情况在多付和少付里讲过，账单本身怎么开，见账单全流程。

账单外的入账，背后没有账单。没有状态，没有自己的事件；它看上去对应的那张订单，可能已经过期，可能几周前就关了，也可能从来没有过。

两者混在一起，出的错总是同一个样子。操作员看到这笔入账，当成账单的部分付款，照着账单发了货。账单永远不会完成，下次对账时，手里是一笔入账和一张订单，中间没人把它们连起来。分清它们只要问一句：哪张账单在等这笔钱？少付答得上来，账单外的入账答不上来。