首次扣款前的预付费资金预留

在第一笔可计费业务发生之前，团队就应能解释资金会怎样移动。预付费 hold 只是为一个已确认的意图锁定金额，并不等于服务已经完成或费用已经结算。其他任务只能使用扣除预留后的余额。直到发送请求被接受、号码成功分配或另一项事先定义的结果出现，账本才记录真正的 debit。这样，产品、运营和财务在成功、失败与超时场景下看到的是同一条事实链。

IOSOR 采用 white-label JIT 流程：先报价，再创建 prepaid hold，完成操作并分配结果，最后按实际结果结算。公开最低充值 USD 20 是小规模试点的钱包底线，不是入场费，也不是 production 许可。接近每月 USD 1,000 时可进行柔性的使用复盘，但它不改变第一笔资金必须可解释的原则。

预付费预留究竟是什么

Hold 把一笔钱围绕某个待处理 intent 暂时隔离。它回答“钱包能否承担这个请求”，却不会假装服务已经交付。每条预留记录至少要包含金额、币种、intent ID、创建时间、到期时间和当前状态。客户端状态应使用清晰含义：已预留、已完成、已释放，而不是暴露内部流程。

状态转换必须原子化。创建失败不能留下幽灵预留，释放也不能在另一个重试仍在结算时重复发生。到期时间不是装饰：它决定未知请求何时进入调查，何时可以安全归还资金，并为客户提供可预期的等待边界。

预留之后怎样计算可用余额

只显示一个“余额”数字会隐藏并发风险。界面与导出都应分别展示 总额、已预留 和 可用。钱包共有 USD 50，其中 USD 12 已被 hold 时，新请求最多只能动用 USD 38。两个并发操作不能承诺同一笔资金。预留和后续 debit 共享同一个 correlation ID，财务才能把它们认作一条业务，而不是两次独立支出。

不同服务可使用不同的预留计算。消息批次可以锁定一个有上限的发送预算，并把 retry 纳入同一资金身份；JIT 号码请求可以预留报价中的首次费用，直到购买与分配完成。无论公式如何，活动中的 hold 都必须从 available balance 中扣除。余额检查与写入预留还要在同一事务边界内完成，否则高并发会让多个请求同时通过旧余额。

监控应同时展示预留数量、最老预留的年龄和即将到期金额。单纯看总余额无法发现卡住的工作流。若某一 intent 长时间没有产品状态，运营要先冻结新的自动 retry，再依据明确证据释放或升级处理。

第一次扣款必须忠于结果

结算依据是可以观察和核对的业务结果，不是点击按钮或请求进入队列。被接受的 send intent、已分配的号码，或者预先写入规则的其他 billable event，才可以触发 debit。最终费用低于 hold 时，只结算实际金额并立即释放差额；系统不得悄悄超过已授权的预留。如果金额可能变化，就应在报价阶段说明上限，并在超过时重新取得授权。

账本行应保存产品事件的 intent ID、服务、金额、币种、时间和最终状态。事件处理器收到重复通知时，必须返回原来的资金结果。由此可见，幂等、重试与资金安全 本来就是钱包设计的一部分，而不是 API 上线后的补丁。

对账要能从产品状态正向找到扣款，也能从扣款反向找到完成证据。若两边无法互相追溯，财务就不能判断这是合法结算、重复处理还是缺少事件。批次中只完成一部分时，按完成单位结算，其余金额释放，并在同一导出中说明差异。

扣款前失败时如何处理

完成前的失败应以释放预留或清楚的 refund 流程结束，不能让余额在没有解释的情况下消失。JIT 请求超时且没有完成证据时可以释放 hold；若外部动作已经完成但结果无法分配，则需要一个可见的运营状态和受控解决路径。号码场景可参考 号码下单失败后的退款与更换。

• 工作开始前 validation 被拒绝：不创建 debit
• 相同幂等键的重复请求：返回已有 intent
• 资金已预留但执行失败：完整释放预留
• 批次部分成功：只结算完成单位并释放未用部分
• 结果未知：暂停 retry、调查证据，避免第二次扣款

Release 与 refund 不是同一个动作。前者把尚未结算的预留恢复为可用，后者则逆转一笔已经结算的资金事件。客户端应能看到两者的时间、原因和关联业务。内部人员不能通过修改最终余额掩盖差错，任何修正都要留下独立、可追溯的账本记录。

买方应核对的资金清单

1. 财务能否区分 reserved、available 与 settled 金额？
2. 每个 hold 是否有到期时间和唯一业务 intent ID？
3. 每个通道的 completion 证据是否被明确命名？
4. 客户无需提交支持工单就能看到 release 与 refund 吗？
5. 重复请求是否复用原来的资金结果，而不产生第二次移动？
6. 低余额能否在多个预留冲突前阻止新工作？请配合 低余额自动停发 验证。

还要检查权限和审计。谁可以延长 hold、手动释放或批准 refund？每个例外是否包含原因、操作者和时间？告警是否在到期之前到达明确负责人？如果答案只存在于聊天记录中，这条资金路径还不具备 production 质量。

从 IOSOR 开始

在大规模发送计费请求前，请先在 IOSOR 控制台中配置预付费冻结过期限制以及授权状态 Webhook。请务必核实您的集成系统是否在统一的关联 ID 下追踪总余额、已冻结余额和可用余额。运行一次模拟的失败意图，以确认未完成的请求会自动触发资金立即释放回可用资金池中。

IOSOR 要点

预付费冻结机制可为待处理的业务意图划定资金范围，从而防止出现竞态条件和双重扣款，同时不会将未计费的活动误传为已完成的收入。将已预留金额与可用余额隔离开来，可让您的系统网关和财务团队实时获得准确且可用于审计的账户偿付能力视图。

请务必将每个授权冻结绑定到一个唯一的业务意图 ID，并在交付或分配失败时自动释放未花费的预留资金。在最终结算时，切勿悄悄超出预留余额，也切勿在没有可观测的完成证据的情况下进行扣款提交。