预付资金预留失败时：自动退款与状态真相

无法完成的预付 hold，必须把资金与状态留在财务可辩护的位置。失败不是「稍后再试」的表演。要么预留回到可用余额，要么对已结算金额做明确退款，要么进入有名称的终态并冻结重试，直到证据齐全。资金卡住或消失却仍显示成功，产品与财务都会不再信任账本。

IOSOR 是 white-label prepaid。同一规则覆盖 messaging、verification、email、voice 以及同一钱包上的 JIT 号码意图。公开最低充值 USD 20 是试点底线，不能证明 fail 路径可用。接近每月 USD 1,000 的 review 只会让失败行更显眼。钱包有钱、通道 live、fail 路径诚实，是三个不同事实。试点流量再小，也要先把失败行导出给财务看一眼。若导出里找不到金额、币种与意图 ID，后续扩容只会放大对账成本。

失败是钱包事件，不是 toast

结账转圈与「pending」横幅不是资金真相。失败之后，钱包要么释放了 hold，要么退回了 debit，要么带着财务可导出的原因冻结了意图。若产品显示成功而预留仍未关闭，账本在说谎。成功路径见 首次扣款前的预付资金预留；本文写的是必须扛住的失败路径。

自动退款与释放必须自动化

「运维稍后处理」不是产品。未使用 hold 的释放与错误 settle 的退款，应由创建预留的同一套规则触发。相同幂等键的重复请求必须复用原资金结果——见 幂等、重试与资金安全。部分批次只结算已完成单位，并在同一导出中退回未用部分。

Release 恢复未用预留。Refund 冲回已结算 debit。客户端需要时间戳、原因与业务意图 ID。没有账本行的静默改余额一律禁止。号码购买失败后的更换体验见 号码下单失败后的退款与更换；本文覆盖所有通道的资金真相。

财务可导出的状态词汇

要求一份能活在 CSV 里的短名单：

• funds held
• completed / settled
• released
• refunded
• needs attention
• cancelled

不要给从未分配资源、从未接受可计费单位的意图发明「Activated」「Delivered」或「Live」。「Needs attention」是工作队列，不是成功的同义词。若状态无法带着金额、币种与 correlation ID 导出，那就是表演。

绝不要伪造 Activated 或 Delivered

虚假成功徽章比空搜索更快烧毁信任。消息失败不得看起来像已送达。从未打开的 verify 会话不得看起来像已验证。从未分配的 JIT 号码不得佩戴 Activated。低余额与超上限拒绝应尽可能发生在 hold 之前——低余额自动停发——避免资金进入死胡同预留。

买家失败诚实清单

1. 每次失败的 hold 是否以 release、refund 或带负责人的 needs-attention 冻结结束？
2. release 与 refund 是否由产品事件自动触发，而非聊天工单？
3. 财务能否在不开工单的情况下把失败行接到原意图 ID？
4. 相同键的重试是否最多只移动一次资金？
5. 客户端错误是否品牌安全且不含上游品牌名？
6. 可用余额过低时 stop-line 是否阻止新 hold？见 生产流量前的钱包止损线。

从 IOSOR 开始

强行让一笔无法完成的预付 hold 失败：上限、拒绝或不足。证明资金回到 available，或出现明确退款行。导出财务守得住的失败状态。用同一把钥匙重放，不可有第二次移动。这是 hold 失败的真相，不是死掉指派后的释放。

Related: 预付费支出控制

IOSOR 要点

失败的 hold 是钱包事件，不是成功戏码。

要做：自动释放或退款，加上具名状态。不要：发明 Activated 或 Delivered。