入站试点周：在租用 DID 上进行 MO 实时检查

入站试点周：在租用 DID 上进行 MO 实时检查。

新 DID 的关键移动主叫(MO)冒烟测试

在刚开通的虚拟号码上启动试点项目时，执行系统的移动主叫(MO)实时检查是防止消息投递失败的第一道防线。我们的平台利用及时(JIT)开通并配合临时预付费冻结，消除了静态号码池，确保了极佳的线路信誉。在第一天测试期间，您应当从不同的移动运营商网络向新号码发送真实测试短信，以验证上行路由的畅通性与延迟表现。请确保测试消息包含可识别的载荷，以便在控制台的事件日志中进行精确追踪和分析，并注意记录消息的 DLR（Delivery Report）状态，即使是 MO 消息，其状态也可能影响后续的路由决策。

Webhook 载荷验证与收件箱事件流

入站消息会向您指定的应用程序 URL 发送即时的 HTTP POST 请求。您必须验证监听器是否正确解析了诸如主叫号码、目标 DID、消息正文和时间戳等参数。有关完整的架构详情，请查阅我们的租用号码上的收件箱事件指南。此外，确保服务器具备适当的签名验证机制，以防止伪造请求，并保证在高峰期能快速响应 HTTP 200 OK 确认。在控制台的 webhook 调试器中，您可以实时查看发送的载荷以及收到的响应，这对于快速定位问题至关重要。请特别留意 webhook 中的 `message_id` 和 `sender_id` 字段，它们是关联消息的关键。

强制性的 STOP 和 HELP 关键词处理检查

监管合规性要求对标准退订指令进行即时且自动的处理。发送包含 STOP、QUIT、UNSUBSCRIBE 或 HELP 的入站测试消息，有助于确认在全量生产之前，账户级的屏蔽规则是否按预期运行。查阅STOP 与 HELP 关键词政策以了解具体的消息拦截机制与退订状态的自动同步逻辑，从而彻底避免潜在的合规处罚风险。在控制台中，您可以配置自定义的关键词及其响应，并监控这些关键词触发的事件。确保这些关键词的处理逻辑与您的业务流程无缝集成，并且不会干扰正常的 OTP（One-Time Password）发送流程。

避免自动回复循环风险与余额耗尽

入站试点周期间的一个重大错误是在没有严格保障措施的情况下配置自动回复。如果传入消息源自另一个自动化系统或自动回复程序，循环条件可能会触发持续计费。参阅我们的入站自动回复循环抽钱包指南，以配置消息去重、速率限制以及智能检测规则，防止异常流量瞬间耗尽您的预付费账户余额。在控制台的“流量监控”部分，您可以设置告警阈值，当入站流量异常激增时及时通知您。同时，配置“静默时段”（Quiet Hours）可以避免在非工作时间处理大量自动回复，从而降低误触发的风险。

试点周运营阈值与预付费限制

为了在早期试点测试期间维护网络质量并保护您的账户免受意外超支，平台运营遵循可预测的计费机制。账户以 USD 20 的预付费底线开始，以涵盖初始的 JIT 号码预留和入站消息处理费用。随着您的试点不断扩大且入站量接近 USD 1,000/月，将进行软审核，以帮您平滑提升通道额度并解锁更高的并发容量与更低的使用成本。您的预付费钱包余额可以在控制台的“账单”部分实时查看。当余额低于预设阈值时，系统将自动发送通知。请注意，某些高风险的路由（corridor）可能会有更高的初始预付费要求，以确保服务质量。

从 IOSOR 开始

第一周在已租 DID 上，用手持机发一条真实 MO。在任何放量前证明收件事件、带签 webhook 以及 STOP/HELP。导出实查表。这是试点证明，不是事故周的洪水节流。在控制台的“测试工具”中，您可以模拟 MO 消息的发送，并观察其在系统中的处理流程，包括 webhook 的触发和 DLR 的生成。务必在部署前完成所有必要的配置，例如设置正确的 webhook 端点和 API 密钥。

IOSOR 要点

已租 DID 在 MO 回来之前不算 live。要验证 MO 的成功接收，需要检查控制台的事件日志和 webhook 的响应。在发送测试消息时，请确保使用不同的运营商和设备，以覆盖更广泛的测试场景。对于 STOP/HELP 等关键词，请验证其处理是否符合预期，并检查账户的屏蔽状态是否正确更新。请注意，在“静默时段”内发送的消息可能不会立即处理，这需要根据您的业务需求进行配置。最终，所有试点阶段的测试结果都应记录在案，作为成功部署的依据。