Webhook验签通过仍会重复扣款：还要补上去重与幂等

当 Webhook 回调会触发扣款时，验签通过仍不能保证只扣一次：同一份合法请求再次到达，原有签名依然可能有效。OWASP 的 Webhook 安全清单将重放防护、事件去重和支付等业务副作用的幂等处理分别列为控制措施。接收端需要把这些控制接成一条流程，而不是在签名相等后立即扣款。

接收顺序是保留原始请求体、按发送方协议恒定时间验签、在协议支持时校验已认证时间戳，再用数据库唯一键原子登记事件并可靠保存待处理任务。确认接收后，由异步工作者执行业务；扣款还须使用稳定的业务操作键。事件去重管住重复投递，业务幂等管住队列重试以及不同事件指向同一扣款操作的情况。

用原始字节验签，再解析业务字段

入口应先限制请求体大小，读取框架尚未解析或重新序列化的原始字节。JSON 字段顺序、空白、换行或字符编码一旦改变，重新计算的签名就可能与合法请求不符。验签失败应直接拒绝请求；不能为了让解析后的数据通过而跳过校验，也不应在日志中留下签名密钥或完整支付载荷。

具体算法、签名头和被签署的字段由发送方协议决定。以 GitHub 为例，GitHub 的投递验签说明规定使用共享密钥对载荷计算 HMAC-SHA256，签名放在 X-Hub-Signature-256 中并以 sha256= 开头，同时建议使用恒定时间比较函数而非普通等号。实现时先检查签名头是否存在、格式和长度是否符合预期，再用相应函数比较收到的签名与本地计算值。

验签之后再解析事件类型、订单标识和业务参数，并核对它们是否符合当前端点的预期。有效签名只说明被签署的内容在传输中未被改动，不能代替订单归属、金额、状态和允许执行的动作等业务校验。如果某个端点只接收特定事件类型，其他已验签事件也不应进入扣款流程。

区分带签名时间戳与仅签正文的协议

若投递时间戳属于签名覆盖的内容，验签成功后可以比较它与服务器时间，并拒绝超出约定容差的请求。容差要考虑正常网络延迟和时钟偏差，服务器时钟也须保持同步。时间窗口只限制旧请求的可接受期限：窗口内的重复请求仍要靠事件去重阻断，窗口结束后仍需保留足以覆盖正常重投周期的处理记录。

如果时间头没有纳入签名，单独检查它不能证明请求新鲜：重放者可以改写时间头，却继续提交原本有效的正文和签名。GitHub 对正文的签名不认证投递时间戳，也不认证 X-GitHub-Delivery。这个投递标识便于识别普通重投，但不能当作具有密码学保证的防重放凭据；接收端仍需让最终业务操作保持幂等。

设计自己的协议时，可以把事件标识、时间戳和原始请求体一起纳入签名。接收端随后才能先确认这些字段确实由发送方提供，再应用时间窗口和事件标识去重。接入现有服务时则必须遵循其实际签名格式，不能把未签署的字段当作已认证字段。

让数据库决定哪次投递创建任务

相同事件键的并发 Webhook 投递只有一次写入成功，并留下一个可恢复的处理任务。

“先查询事件是否存在，再插入”会在并发投递时留下竞态：两个请求都可能查到不存在，然后分别创建任务。应在数据库中为发送方、端点、租户和事件键建立符合业务范围的唯一约束，让插入结果决定哪次投递取得处理资格。事件键优先采用协议提供且经过认证的事件 ID；若只能使用未签署的投递标识，应将它限于普通重投去重，并另设业务幂等键。

语言无关的接收时序可以写成：发送方 → 接收端：提交原始请求；接收端 → 验签器：校验签名与可用的新鲜度；接收端 → 数据库：在同一事务中插入事件记录和待处理任务；数据库 → 接收端：返回新记录或唯一键冲突；接收端 → 发送方：对可靠保存的新事件或已保存的重复事件确认接收；派发器 → 工作者：提交任务；工作者 → 支付服务：以稳定业务键执行扣款。验签或数据库写入失败时，不应沿着成功分支确认投递。

数据库伪代码是：BEGIN；INSERT inbox(provider, endpoint, tenant, event_key, payload, state)，约束 UNIQUE(provider, endpoint, tenant, event_key)；如果发生唯一键冲突，结束事务并确认已保存的重复投递；如果插入成功，在同一事务中 INSERT outbox(event_key, task)；COMMIT；返回成功。outbox 是数据库中的待派发任务记录，由派发器持续读取并送入工作队列。进程即使在提交后、真正入队前退出，已提交的任务仍可恢复。

事件键与扣款键解决的是两种不同的重复。即使两个通知各有不同事件 ID，只要它们要求完成同一笔业务扣款，工作者也应使用同一个操作键，并在本地记录该操作的执行状态。若支付接口支持幂等键，应把这个稳定键传给接口；若调用超时，先按操作键查询结果或对账，再决定是否重试。超时只表示接收端不知道结果，不能据此断定扣款没有发生。

快速确认之后，仍要处理重试与乱序

GitHub 的 Webhook 最佳实践要求接收端在 10 秒内返回 2XX，建议将耗时处理放进异步队列；请求重投会沿用原来的 X-GitHub-Delivery 值。对需要扣款的接收端，HTTP 成功响应应表示事件和任务已经可靠保存，而不是任务刚被放进进程内存，更不必等待支付调用完成。

数据库事务失败时不要返回成功，否则发送方可能认为投递已完成，接收端却没有可恢复的任务。已经可靠保存的重复投递可以直接确认，不必再生成任务。工作者执行失败则由任务重试、失败队列和告警处理；工作队列本身也可能重复交付，所以扣款幂等约束必须在工作者和支付操作处继续生效。

去重也不保证事件按产生顺序到达。若较新的支付状态先到，较旧状态随后到达，按接收顺序直接覆盖记录可能让订单倒退，并影响后续扣款判断。只有发送方明确提供具有排序保证的版本或序列号时才据此比较；否则，在状态会改变扣款决策时查询发送方的当前对象状态，并让本地状态变更遵守业务规则。

测试时看实际扣款结果

接收端测试要同时检查响应、事件记录、待处理任务和最终支付结果。以下场景分别覆盖验签、重放、并发、故障恢复与乱序，避免只看到成功的 HTTP 状态就误判处理正确：

改动原始请求体的一个字节、空白或换行，并分别提交缺失和格式错误的签名；这些请求应在进入业务逻辑前失败。包含 Unicode 字符的载荷也应按收到的原始字节验签。
对签署时间戳的协议，提交过期请求和窗口内的重复请求；前者应被拒绝，后者不应再次产生副作用。对仅签正文的协议，分别检查投递标识去重和业务操作幂等。
并发提交相同事件，确认唯一约束只允许一个事务创建任务；在事务提交后、队列派发前终止进程，确认待派发任务仍可恢复。
让工作者重复执行同一任务，并模拟支付接口在返回结果前超时；核对业务操作键、查询或对账结果，确认重试不会再次扣款。
颠倒相关事件的到达顺序，确认旧状态不会覆盖已确认的新状态，也不会触发当前业务状态不允许的扣款。