区分接收与处理完成
保证取决于提供方。Stripe明确说明可能重复且不保证顺序。成功HTTP响应应对应持久接收或预定处理，而不只是请求进入内存。
| 情况 | 预期行为 | 有用证据 |
|---|---|---|
| 同一事件收到两次 | 防止重复业务效果。 | 已处理ID与持久结果。 |
| 旧事件稍后到达 | 不要盲目覆盖新状态。 | 权威状态与转换规则。 |
| 繁重处理 | 持久接收后延迟执行。 | 队列状态与工作进程结果。 |
| 投递缺失 | 按提供方规则对账与恢复。 | 已识别缺口和已验证修正。 |
构建可验证的接收过程
- 根据提供方协议检查HTTPS、签名与重放防护。Stripe使用原始正文验证签名；先转换JSON可能导致验证失效。
- 在适当确认前持久保存事件或处理记录。区分投递ID、事件ID与业务操作的幂等键。
- 测试重复、乱序、工作进程中断与重启。旧事件不足以支持安全决策时，读取对象的权威状态。
安排恢复与对账
记录尝试、时限、未处理事件及与提供方的对账流程。快速确认可能掩盖后续处理失败，因此也要监控最终业务操作，限制日志中的秘密与个人信息。
一手资料
安全地处理重复的 Webhook。
超时或响应丢失后，通知可能会重复发送。可靠性取决于来源验证、事件标识符以及区分新消息和重复消息的处理。
- 使用提供商的机制验证每个请求。
- 测试重试、重复请求和到达顺序变更。
- 在处理或持久排队后，始终发出确认。
一手资料：IETF RFC 9457 — Problem Details for HTTP APIs. 相关方法：阅读实用指南.