链重组之后，商户余额不动

链重组是网络换了一条历史。原分支上的区块被丢弃，只写在这些区块里的交易，也就不再属于这条链。对商户来说，链上就这一种故障能让「货已经发出去」和「钱真的收到了」对不上，值得花十分钟看明白。

下面只讲这件事引出的决定。链为什么会分叉、一次确认到底证明了什么，在确认与终局性说明里；要等到多强的确信才够，在按金额分档的确认策略里。

重组到底拿走了什么？

拿走的是记录，不是钱。

这是重组最容易被误会的地方。没有人退款，也没有人撤销。客户钱包签了一笔交易，交易进了某个区块，然后网络选中了一条不含这个区块的历史。在链上，这笔付款等于没发生过。币在赢的那条分支上该在哪儿就在哪儿，多数情况下还在客户钱包里。

同一笔交易通常很快又被打包进后面的区块，事情自己就结了——交易本身有效，网络没有理由拒绝它。危险的只有一种情况：付款被剔除了，而处理商此前已经告诉你「已确认」，你也照着办了。

已确认的付款还会消失吗？

确认会消失，入账不会。

Paymos 在协议终局之前确认，深度按所选网络和付款金额来定。 这是拿风险换来的速度：每笔付款都等到绝对终局，一部分网络上的收银台会慢到没法用。代价是有极小的概率——一笔已确认的付款，它所在的区块后来被丢弃。

代价没有转嫁给商户。区块被判定消失时，商户那笔入账原样保留，差额记进平台自己的账户，科目是重组损失。账本代码里这条规则就写在过账语句旁边：商户不动，那笔入账活了下来，既不能冲销，也不能记第二遍。

少掉的钱记在谁头上？

记在 Paymos 自己的账上，这句话值得说准。

处理商做过一次判断：这条网络、这个金额段、确认到这个深度——为的是让付方快点走完收银台。判断错了，币确实不在，缺口总得有个账户吃下来。让商户吃，等于让商户为一个自己没做过、也看不见的风险决定担责。

所以损失记在平台。这是一条政策，不是自然规律，同一个问题值得对着任何一家处理商直接问：你提前确认，链不认账，动的是谁的余额？没想过的答不上来，想过的能报出账户名。

这条转账记录为什么不删？

删掉正是重复入账的来源。

区块被丢弃时，第一反应是把记录去掉：付款没发生，那就删行。Paymos 反着来——这条转账记录只标不删，重组路径把它标成链上已不存在，记录本身留着。

理由要等交易回来才看得出来。原记录要是没了，重新打包会以一笔全新付款的身份到达，同一笔转账商户被记两次账。保住同一个转账身份，重新打包才会被认成同一笔付款回来了，而不是又来了一笔。一笔付款拆成两条记录是明令禁止的，禁的就是这个。

支付通道那边看得更直白：一笔付款从头到尾只有一条充值记录，pcd_ 标识全程不变，具体见充值状态说明。

凭什么判定一个区块真的没了？

只认协议终局性。

链头切换是常事。节点先看到一个区块在头上，一秒后换成另一个，什么都没坏，也没有交易丢失。把每次链头切换都当成重组，标成「不存在」的转账会多到没边，告警不出一周就没人看了。

所以只有终局性确认该区块不在已终局的链里，这条转账才被标成链上已不存在。 Ethereum 这类权益证明网络给的是协议级信号：区块一旦终局，除非质押方大规模被罚没，否则改不动。

还有一种情况不走自动处理：重组打到了已终局高度以下。那是协议层面的破坏，这条网络的扫描游标当场停住，不做自动对账。

交易又回到链上会怎样？

损失冲回，商户这个方向也不动。

重新打包的转账带着原来的身份回来，平台那笔重组损失，冲回到当初吃下它的那批账户——币回来了，损失轧平，手续费重新确认。商户余额不动，因为它一开始就没动过。入账一次，穿过剔除和回归还是那一次，这就是整套设计要的结果。

收到重组通知之后该做什么？

按运营告警处理，别当成记账事件。

支付通道会发 webhook：payment_channel.deposit.reorged 是三个充值事件之一，另外两个是 confirming 和 confirmed，同属一个订阅类目。账单事件里没有对应的重组事件。

余额没变，账上没有要做的事。事件告诉你的是另一件事：某笔订单是凭一份后来消失的证据结掉的。这笔订单要是还没出库的实物，你拦得住；要是一个下载链接，那就没什么可拦的。

订单系统本身不用为重组加一个状态。链上付款在你这边的形状已经够了：未付款、已确认、已履约。余额不变，就没有东西要对账。值得加的只有一样——货贵、又是实物发运，就在确认和出库之间留一个短窗口，让告警有地方落。

卖数字商品、或者单价不高，正确的工程动作是什么都不做。给卖下载包的收银台写一套重组处理，回本遥遥无期，而它挡的那笔损失本来也不记在你头上。

怎么在出事之前先测一遍？

用沙箱模拟。充值模拟的 stage 取 confirming、reorged、confirmed 三个值之一，选 reorged，webhook 就先发 confirming、再发 reorged。

值得跑一次，理由和重组本身关系不大：这是最便宜的一种办法，看看你的 webhook 处理器碰上一个没预料到的事件还活不活得下来。多数集成照着顺利路径写，第一次遇到异常事件是在正式环境。这一个可以挑个周二下午遇到，什么代价都没有。

有一处别搞错：模拟器不做重新打包，每次调用都是一条新的充值。要演练同一笔付款先被剔除、再回来，得走接近正式环境的流程。调用参数见模拟通道充值。