终端用户发送操作仍扣减单一预付费总账

在 SaaS 用户界面中，终端发信体验看似毫无成本：用户只需在界面内点击'发送'，即可立即看到绿色勾号成功提示。然而在表层代码之下，每一次成功的消息提交都必须精准落地并扣减由 ISV 负责注资的单一预付费总账。仅仅因为产品嵌入了 API 接口，并不会凭空产生第二个资金池。如果 ISV 的钱包未预先注入足够资金以完成预扣(Hold)，系统必须抛出真实的产品级错误——绝不能用虚假成功或欺诈性的'已送达'状态进行伪装。

虚假记账是嵌入式架构中最典型的故障模式：例如在应用内展示未与 IOSOR 钱包关联的'虚拟积分'，或是在预付费总账持续消耗的同时向 SaaS 客户进行退款，亦或是在缺乏幂等性保障的情况下盲目重试，导致一条 OTP 验证码被重复扣款。嵌入式集成隐藏了底层管理控制台，但 ISV 作为资金注入主体的责任始终未变。

系统架构文档的核心准则只有一条：终端用户的发送行为等同于 ISV 预付费钱包的扣款动作。所有设计评审都应以此为基点展开。

即使 UI 显示产品积分，也只对应一个总账

向租户销售的'消息套餐'或'积分包'仅属于 ISV 商业层面的逻辑包装。在底层实现上，它们必须严格映射到 ISV 资金账户在 IOSOR 预付费钱包上的预留冻结与实际扣款。如果租户额度无法与账本流水按行对账，该架构必然会在日后引发严重的客服与财务债务危机。建议每周定期导出租户的使用量明细，并与钱包流水行进行比对，确保产品部门看到的数据与财务部门看到的消耗完全一致。

除非与合作伙伴明确签订了独立隔离合同，否则切勿为每一个租户单独开立 IOSOR 账户。在绝大多数嵌入式试点项目中，所有租户均共享同一个 ISV 账户，并通过内部配额限制与公平使用策略(Fair-Share Caps)来进行风险控制。

预留冻结与幂等性在嵌入路径中依然约束调用

服务端发信必须使用全局唯一的幂等性密钥(Idempotency Key)，尤其是针对 OTP 验证码和交易类短信。当用户在 SaaS 界面中误操作双击时，绝对不能因为单次用户意图而产生两次预付费扣款。在请求超时后的重试逻辑中，必须沿用同一个幂等密钥，直到收到终态状态报告(DLR)或系统返回明确的映射错误。

当钱包余额不足以完成预扣时，系统应直接返回产品原生的'余额不足'或'暂停发送'状态。在预扣动作失败的情况下，绝不能向客户端返回带有'已送达'语义的 HTTP 200 响应。

将产品错误精确映射到总账真实状态

客服团队必须深刻理解产品状态与账本真实记录之间的映射关系。针对界面信号与底层流水的映射标准如下：

请务必对支持和运维团队进行中间列机制的专项培训。如果工单系统中频繁出现'UI 界面显示绿色成功但账本中无扣款记录'的异常现象，这将会白白浪费试运行阶段宝贵的时间与信任成本。

跨通道切换仍共享同一个钱包

如果产品后续规划在短信业务之外扩展电子邮件或语音通道，所有通道的资金消耗依然会统一归集到同一个预付费总账中，除非财务部门明确签署了多通道资金交接与隔离协议。嵌入式集成绝不意味着可以创建一个免费的旁路通道。在 SaaS 设置界面中开启新的实时通道前，请先仔细阅读钱包邻近性与多通道交接的相关规范。

相关运维路径

• 钱包上的第二个通道：支出交接
• 幂等、重试与资金安全
• 安全地跨多租户账户执行速率限制

从 IOSOR 开始

打开 IOSOR 控制台，将您的租户信用系统直接映射到主预付费钱包分类账。确保所有服务器端嵌入请求在对主钱包进行冻结之前，都通过确定性的幂等键。配置您的 webhook 端点以处理传入的发送状态报告，以便未结冻结能够清晰地解析为最终的分类账借记或释放。

IOSOR 要点

嵌入式 SaaS 界面可以向最终用户展示自定义消息额度，但每次真实分发都绑定到由独立软件开发商资助的单一预付费分类账。重试、渠道扩展和用户状态信号必须直接与钱包冻结进行对账，而不是依赖无支撑的用户界面抽象。

请务必强制执行严格的服务器端幂等键，并将每个租户界面状态映射到真实的分类账发送状态响应。切勿发明无支撑的二级钱包，也不要允许租户界面在没有具体分类账冻结的情况下进行重试。