发票付款后，支付服务商发来一条 Webhook。你的自动化收到后更新订单，并给客户发邮件。随后服务商又发了一遍同样的 Webhook，因为你的服务器回复得太慢。结果客户收到两封邮件，订单记录里出现了两笔付款。

Webhook 是某个系统在发生变化时发给另一个系统的消息，比如收到付款、有人提交表单、合同完成签署。它往往是连接各个工具最快的方式。但它按发送方的节奏到达，有时晚到，有时重复，偶尔还会有人冒充发送方。

先核实是不是真的来自发送方

大多数服务会用一个只有你和对方知道的密钥给每条 Webhook 签名。处理任何内容之前，先验证签名，不通过就拒绝。时间戳过旧的消息也要拒绝，防止有人截获消息后重放。

签名密钥和其他凭据一样，放在密码管理器或密钥管理服务里。存放位置和负责人怎么定，可参考服务账号与权限过期指南。

先快速回复，再处理业务

发送方通常只等几秒钟。如果你的自动化要先更新三个系统才回复，对方可能以为失败了，于是再发一遍。

正确的顺序是：

  1. 验证签名。
  2. 连同唯一编号保存这条消息。
  3. 回复已收到。
  4. 在后台处理。

让重复送达不产生影响

默认每条 Webhook 都可能不止到达一次。处理前先检查这个消息编号，或这件业务事件（例如“1042 号发票已付款”）是否已经处理过。如果处理过，回复已收到，其他什么也不做。具体做法可参考自动化重试不重复执行指南。

也要预料到消息可能乱序到达。“已退款”可能比“已付款”先到。顺序重要时，去源系统查询当前状态，而不是只相信消息本身。

留意 Webhook 突然停了

最隐蔽的故障是一条消息都没有：地址改了、密钥过期了，或者发送方在多次报错后停用了你的接收地址。记录最后一条 Webhook 的到达时间，如果在本该有消息的时段一直没有，就通知负责人。很多发送方还会提供近期事件列表，可以和实际收到的消息核对，做法和批次对账类似。

保留一份简短日志

每条消息记录到达时间、编号、事件类型和处理结果：已处理、作为重复忽略，或处理失败。不要保存超出需要的个人信息。出问题时，正是靠这份日志查清漏掉了哪些事件。

如需检查自动化背后的 Webhook，欢迎联系 Storm Nova Labs。