入站 MO 计费对出站 MT：同一本预付费账 上的双向钱包行

路演只讲出站。上线后租号开始收回复、STOP、偶发语音回拨，钱包多出财务没写进模型的行。入站 MO 不是免费礼貌。双向产品在同一本 prepaid 账上同时走 MT 与 MO。若导出只有「发送条数」，财务会把入站借记当成噪声，直到月用量接近 USD 1,000+ 时才变成商务问题。

IOSOR 是 white-label prepaid：出站与入站同一 ledger，client-safe 错误，没有第三方门户当日常。目录 live 才是双向生产；in setup 不是便宜收件箱。参见 双向消息收件箱指南 与 租用号码上的收件箱事件。先证据，再规模。

财务没规划到的 MO 借记

财务模型若只乘 MT 单价，会漏掉租号上的 MO 行：入站短信、关键词确认、有时语音事件。这些行在回复到达时借记，不在营销日历上。产品说「我们做了双向」，财务问「哪一行是入站」。答不上来就不是控制。console 需展示 MO 借记的 origin，关联到具体租用号码和收件箱配置。预付费钱包的每一笔入站扣款都应有明确的 reason code，例如 `INBOUND_SMS_CHARGE` 或 `KEYWORD_RESPONSE_FEE`。

同一导出里的 MT 与 MO

把 MT 与 MO 放进同一份导出：时间、号码、方向、借记额、correlation ID。财务必须能按方向过滤，而不是把入站揉进出站平均值。STOP/HELP 是合规行，也是可能借记的行。租号生命周期绑在收件箱上：释放号码必须干净停入站事件，否则幽灵行会在下月出现。不要用全球平均数掩盖一条贵的入站走廊。console 导出应包含 `direction` 字段（`MT` 或 `MO`），以及 `cost` 和 `currency`。DLR 状态更新应与原始 MT 消息关联，确保每条出站消息都有最终状态反馈。

自动回复循环抽干钱包

无上限的自动回复会把一次 MO 变成一串 MT，直到钱包空。机器人对机器人、引用原文的 HELP、未幂等的 webhook 重试，都会抽干 prepaid。给每个线程设回复上限，并把 STOP 写成立刻抑制。详见 入站自动回复循环抽钱包。策略说停时钱包必须停，即使产品还想「再确认一次」。循环样本在接近 USD 1,000+ 时应进入商务复盘，而不是凌晨工单。console 应提供 webhook 失败重试次数和状态，以及自动回复的线程计数器。OTP 验证流程中的重复尝试也可能触发意外计费，需设限。

收件箱事件与关联

收件箱是证据，不是聊天玩具。每条入站事件应显示号码、时间、安全脱敏正文，并在有线程时链到出站上下文。运营需要可重放的死信，而不是把上游载荷扔给坐席。关联失败时，财务无法解释 MO 借记，产品无法证明双向「有效」。租号续订按 UTC 自然月；收件箱负责人必须知道号码何时到期。webhook 接收器应能处理异步事件，并记录原始载荷以便审计。quiet hours 配置应能阻止在非工作时间发送自动回复，避免不必要的 MT 计费。

危险信号

• 财务模型只有 MT 单价
• 导出分不出方向
• 自动回复没有线程上限
• STOP 当闲聊，不抑制
• 坐席看见原始上游载荷
• 号码已释放仍有入站借记
• 目录 in setup 却承诺双向生产

开始使用 IOSOR

在同一条已租 DID 上发一条入站 MO、一条出站 MT。导出两行钱包，证明原因码不同。给自动回复加顶，入站不得铸造无限 MT。这是双向预付行诚实，不是账单周的混合报表，也不是媒体存储上限。console 需配置 DLR 状态回调，确保每条出站消息的送达状态都能被追踪。OTP 消息发送应有独立的计费标识，与普通 MT 区分。

IOSOR 要点

MO 与 MT 共用钱包，不共用一行。入站 MO 计费是独立于出站 MT 的，即使在同一张预付费账单上。console 应提供清晰的入站和出站费用明细，允许按号码、按时间段进行分析。webhook 失败重试策略应可配置，以避免因临时性网络问题导致计费异常。quiet hours 是一个重要的成本控制机制，应与自动回复策略结合使用。STOP 关键词应触发即时且永久的抑制，避免后续不必要的计费。OTP 消息的发送频率和重试次数也应纳入成本考量，并设置合理的上限。