接入方问你：订单状态变了你们怎么通知我？你说轮询查吧。接入方转身就走了。轮询浪费资源、延迟高、体验差，事件通知的正确解法是Webhook。

一、Webhook的基本机制

原理很简单：接入方在后台配置一个回调URL，当事件发生时，平台主动向这个URL发POST请求，把事件数据推过去。接入方收到后处理业务，返回200表示接收成功。

和轮询比，Webhook的优势明显：实时性好，省带宽，接入方不需要维护轮询服务。但代价是平台要承担推送的可靠性责任——发出去对方没收到怎么办？

二、签名验证：别让伪造请求钻空子

Webhook最大的安全风险是伪造请求。攻击者猜到回调URL格式，直接构造请求发过去，接入方以为是真的事件就处理了。

必须做签名验证。方案：平台用接入方的API Secret对请求体做HMAC-SHA256签名，签名值放在X-Signature请求头里。接入方收到后用同样的算法验证签名，不匹配直接拒绝。

落地建议：签名内容不只包含请求体，还要加上时间戳。验证时检查时间戳和当前时间差不超过5分钟，防止重放攻击。时间戳放在X-Timestamp头里，一起参与签名计算。

三、重试策略：推不成功怎么办

接入方服务器偶尔宕机正常，平台不能因为一次推送失败就放弃。重试机制必须设计好。

重试间隔用指数退避：第一次失败后30秒重试，第二次2分钟，第三次10分钟，第四次1小时，第五次6小时。最多重试5次，超过后标记为推送失败，在开发者控制台显示告警。

重试时要保证幂等性。同一个事件可能被推送多次，接入方必须能正确处理重复消息。方案：每个事件带唯一event_id，接入方收到后先查本地是否处理过这个event_id，处理过直接返回200跳过。

判断重试策略是否合理：接入方服务恢复后，积压的事件能在1小时内全部补发完成。

四、回调URL管理

接入方配置回调URL时要验证所有权——平台发一个challenge token到URL，接入方原样返回才算验证通过。防止配置别人的URL导致信息泄露。

回调URL支持按事件类型分别配置。订单事件发给URL-A，退款事件发给URL-B，接入方内部系统解耦。

响应规范：接入方收到请求后应在5秒内返回200状态码。处理慢了平台会超时重试，导致重复推送。如果业务逻辑耗时，先返回200，异步处理后再更新状态。

做好这套机制，接入方对接成本能降低一半以上。