签名与重放窗口网关

未签名或过期的 webhook 不是状态真相，绝对不能动用预付费资金。买家在任何事件更新账本或产品状态之前，都需要一个坚固的网关：进行签名验证并设置有限的重放窗口。本页正是该网关的说明——而非轮换迷信的文章，也不是入站短信重试手册。

相关链接：webhook 签名与重放窗口、入站 webhook 的重试与幂等、产品与财务的共享状态语言、同一账本上的扣款行与送达状态。

IOSOR 是白标预付费系统。充值 USD 20 即可在单个消费者上启动网关试用；当用量接近 USD 1,000/month 时进行温和评估，若跳过验证则会被视为伪造状态风险。客户只会看到白标拒绝宏。

签名验证是资金之门

只有在签名检查通过后，资金和状态真相才会生效。缺失、不匹配或被跳过的签名将直接触发故障关闭 —— 不写账本，也没有 «为试用而送达»。目录上线(Catalog Live)绝不豁免网关。习惯深度阅读：webhook 签名与重放窗口。温和的 USD 1,000/month 标准将«永远在灰度中接受未签名请求»视作生产债务；USD 20 则能证明单个伪造请求体绝不会产生任何扣款。

在状态真相之前设置重放窗口

至少一次投递机制会进行重试。超出窗口的晚到重试绝不是 «可能已送达»。日志中应将窗口拒绝与签名失败分开记录。入站重试深度：入站 webhook 的重试与幂等。

拒绝时执行故障关闭

被拒绝的事件绝不能凭空捏造成功。产品和财务共享同一套拒绝词汇，而不是英雄主义的上游代码：产品与财务的共享状态语言。扣款行仅与被接受的事件保持一致：同一账本上的扣款行与送达状态。副作用只能在确认(ACK)之后触发；如果在网关前进行 CRM 操作，就会制造出双重真相。

产品、财务与运维共享同一份证明

产品：合法的已签名且在窗口内的事件能否更新一次状态？财务：每个影响资金的事件是否都在相同的 UTC 窗口显示网关通过？运维：能否在不翻找 Slack 历史的情况下导出签名失败与窗口拒绝的数据？在窗口内重复事件的冒烟测试显示出单一账本行之前，有关软卷量的讨论一律搁置。

签名重放网关买家检查清单

1. 在处理付费流量之前，每个生产消费者是否都部署了签名中间件？
2. 重放窗口是否已命名、记录并进行限制 —— 而不是 «几周»？
3. 网关拒绝是否从不写入资金或成功状态？
4. 窗口内重复的事件 ID 是否只产生一个最终状态且无二次扣款？
5. 签名失败和窗口拒绝能否在运维层面被分别统计？
6. 在网关关闭的情况下，是否禁止谈论 USD 1,000/month 的软卷量？

任何一个 «否» 都会让网关以及受信任的 webhook 真相停留在草稿阶段。

从 IOSOR 开始

在将生产流量路由至 IOSOR 控制台之前，请在所有入站 Webhook 上启用签名验证中间件。在重放窗口网关上配置严格的时间戳边界，以自动拒绝陈旧或未经身份验证的有效负载。确保网关拒绝能够触发即时的故障关闭处理，从而使未经验证的 Webhook 永远不会触及您的财务账本。

IOSOR 要点

本指南确立了签名验证和带时间限制的重放窗口作为财务与状态真相的强制性网关。对无效签名或过期时间戳采取故障关闭措施，可防止重复状态处理，并在产品、财务和运营之间维护单一的证明来源。

务必在上线前对所有活动的 Webhook 消费者强制执行签名验证和有限的重放窗口。切勿为试点流量绕过签名网关、忽略重复的事件 ID，或为被拒绝的传入有效负载捏造成功状态。