没有放款日，剩下的那段等待归链

商户问的是「几点之前提交，当天能到」，脑子里那套词是截止时间、工作日、放款日。转出这条路上，这三样一个都没有。

这条路分两段，两段的性质不一样。第一段短到报不出时长：请求落地，转出立刻开始执行，没有批次窗口，没有放款计划，没有审批队列，也没有谁在中间先看一眼。这不是速度纪录，是队列压根不存在。后一种说法比前一种耐用得多。

第二段是链在做链的事，跟着选定的网络走，也跟着那条网络当天的拥堵走。它不是这一侧的时间，所以这些页面上没有到账时长可查。这篇讲的就是为什么没有，以及没有的情况下该看什么。

点下确认的那一刻，钱去了哪

两个数字离开可用余额，一笔交易发出去。转出金额和这条路线的网络费一起挪进冻结，所以余额页把可用余额和冻结中分成两行，而只有可用余额那一行能给下一笔转出出钱。

然后就发了。中间没有东西停留，因为没有截止时间可以错过，也没有人要批。目标网络在创建转出时挑定，可选的只有这种资产当前开着的那几条。某条资产加网络的路线也可能一时走不通。这种时候它从选择器里消失，请求里还写着它，就在创建那一步退回来，余额一分没动，换条路线或者晚点再来。

为什么这里不写「几分钟到账」

因为决定它的那只表，不归这边启动，也不归这边停。

广播出去之后，到账快慢是网络的属性：它出块多快，它的终局规则怎么定，它这会儿扛着多少流量。给这一段写个数字，等于拿别人的基础设施当自己的承诺。

会混起来很自然，因为商户体验到的是一段等待，不是两段。钱离开余额，时间过去，钱出现在钱包里。哪家处理商把「一分钟内到账」印出来，印的就是它并不运营的那一半。它真正担得起的是前一半：自己这边没有任何东西在等。

差别只在忙日子里显形，而商户恰恰是在忙日子里去翻这一页。承诺「没有队列」的平台，那天下午说的还是同一句话。承诺「一分钟」的平台，那天下午要跟客户解释一条链，而客户手里攥着的正是那个数字。

「已确认」在每条链上不是同一件事

每套协议自己定终局，定法之间差得很远。

Tron 数的是人头。现任超级代表一共 27 个，其中至少 19 个各自在这个高度或者更高处出过块，这个块才算固化，而固化的块不会再被分叉替换。

TON 一个块就把这件事结了。一笔交易在单个主链区块确认之后即达成终局，分片链上的交易一旦出现在主链区块里就不可逆。

以太坊算的是另一套单位。时间切成 slot 和 epoch，终局目前落在两个 epoch 之间，而不是在单个 slot 里。

三条链，三样东西共用「已确认」这三个字。把它们换算成分钟，谁都会算。替算出来的那个数字背书是另一回事，而链本身从没做过这种承诺。

一笔转出会停在哪儿

七个状态，三个是终点。

API 返回的状态值是 created、signed、completed、failed、cancelled、pending_review、cancelling。每个负载都带 is_final，只有 completed、failed、cancelled 三个为真。按这个布尔分支，别去维护一份状态名清单。

中间那几个描述的是这一侧的工作，没有一个是进度条。只有 pending_review 值得一眼认出来：它在控制台里显示成未确认，意思是网络还没确认这笔转出，金额仍在冻结中。

真想看进度，链上有一条你自己就能看的。转出交易一出现在链上，tx_hash 就填上了——这早于 completed；同一条记录还给 explorer_url，直接点进 Tronscan 或者 Etherscan。对应的事件是 withdrawal.processing，事件目录给它的说明是「出账交易已在链上观测到，交易哈希可用」。等的那一半不归这边，看着它走的办法倒是现成的。

取消这扇门关得早

窄，而且比交易本身关得早。

转出还是 created 并且没开始执行时可以取消，之后调用会被拒绝。对一笔已经取消的再取消一次，返回 200 和同一笔转出，不报错，重试的客户端不用为它写特例。

取消接口还要带上必填的 reason，最长 500 字符。它存进转出记录，也写进审计日志，却不回传：取消响应和 withdrawal.cancelled 带的都是状态，不是原因。

取消不是召回。已经上链的转账，这边没有把它撤回来的路径；钱要回来，只能由收到它的那一方再发一笔。

没发出去的那笔，钱和消息各走各的

钱整笔回来。消息只走一条道。

以 failed 或者 cancelled 收尾的转出，冻结整笔释放，本金回可用余额，网络费也回可用余额，路上不净掉任何东西。控制台那句话写得很直白：「包含网络费在内的全部金额已返回可用余额」。没发出去的转出不收钱。沙盒里这个问题不存在，因为那边压根不记冻结。

接下来这句最容易栽。转出失败会发 webhook，withdrawal.failed 和 withdrawal.cancelled 都在事件目录里；邮件没有，控制台铃铛里也没有。程序那一侧收得到，盯着收件箱的人永远等不到。

商户看到的那句话短得刻意：这笔转出没有发出、冻结已经释放，两句后面都不跟原因。为什么不给原因，是热钱包那一篇的题目。

一次发五十笔，会不会更慢

那是五十笔交易，不是排到某个钟点的一批。

控制台里有转出批次：一次对话框最多 50 个收款方，一种资产走一条网络，对着白名单一起批。批次是正式环境的功能，沙盒里演练不了，而 Merchant API 的每条转出路由仍然只收一个收款方，所以这个形状属于控制台，不属于 API。

旁边有两条账户限额，发之前就摆在眼前：一笔能走多大，同时能有几笔在途。剩下的在途名额在表单里先显示出来，还没输入就知道，所以它是个数字，不是一次驳回。名额不够的批次整批退回，消息里写着差多少。

不管五十笔还是一笔，都没有窗口。没有东西把它们攒起来，等某个约好的时刻。

选网络，就是选那半段等待

整段等待里，这是商户唯一能挑的部分。路线在创建转出时定下，能挑的范围比收款窄。转出要指定白名单上的目的地，而白名单只收四类地址：EVM、Tron、TON、Solana。所以 13 条收款网络里能转出的是 11 条，NEAR 和 Sui 收得进来，转不出去。一条 EVM 地址只登记一次，八条 EVM 转出网络都跟着开，因为白名单那一行认的是地址加网络族。

费用跟着这个选择走，但不是这篇的题目。转出这一侧没有 Paymos 处理佣金；路线的网络费在确认之前就摆在屏幕上，而且它按代币定死，不是当场的 gas 报价。这个数收的是补贴价，链上跑这一趟真实要多少，商户付的都在那之下。具体数字在价格页。

那你的系统该等什么

等状态，别等秒表。

• 按 is_final 分支。 它在每个负载上，省掉一份要你自己跟着改的状态名清单。
• 把 webhook 当成转出的通知渠道，不是当成锦上添花。失败不会从别的地方来，没有邮件。投递失败会按梯子重试，掉线的接收端回来还能拿到那条事件。
• 给自己的客户看状态和网络，不要给倒计时。 倒计时是拿别人的链做的承诺，而读它的那个人会拿它来找你。

收款那一侧是另一道题。付款方等的是一条跟着网络、也跟着金额走的确认策略，那段等待为什么会变单独讲过。钱在两段之间停在哪儿，归账本那一篇；冻结回滚为什么在账上表现成两条对冲的记录，那边也讲了。

所以老实的答案给的是形状，不是时长。前半段在有东西可以计时之前就结束了。后半段是一条公开的链按自己的节奏落定，没人替它签过到达时间。把下一步挂在确认事件上，这个数字就不再需要了。