三方支付与 Webhook 回调安全：防重放、加签验签与数据幂等设计

1. 业务险情：一次重复扣款带来的资金风险#

在电商、SaaS 订阅与游戏充值业务中，支付回调（如微信支付、支付宝、Stripe）是整个交易闭环最核心的生命线。 然而，由于公网环境的网络不可靠性，三方支付平台均会采用超时重试策略（例如在未收到 HTTP 200 响应时，分别在 15s、30s、3m、10m 之后连续推送相同的支付成功事件通知）。

如果开发者的回调接口没有做严格的安全与幂等设计，就会引发：

重复给用户发放权益 / 重复充值代币；

黑客抓包伪造支付成功请求，非法篡改订单状态。

---

2. 支付回调三层安全立体防线#

第一道防线：非对称公私钥加签与验签（防篡改）#

商户必须严守“私钥加签、公钥验签”的密码学铁律：

微信/支付宝在发送通知时，会使用其官方私钥对请求的 Body、时间戳与随机字符串计算数字签名（通常为 RSA-SHA256）；

我们的接收端必须使用三方平台官方下发的根公钥进行签名核验；

绝对不要仅凭请求里的 status=SUCCESS 就推进业务逻辑！ 任何未经公钥验签通过的请求一律按非法入侵处理。

第二道防线：Nonce + Timestamp 时间戳校验（防重放攻击）#

即使黑客无法篡改带签名的报文，他们也可以在公网中截获一段完全合法的支付成功报文，并在 1 小时后重新向你的回调地址发起 POST 请求。 防范方案：

检查报文头里的时间戳与当前服务器系统时间，若时间差超过 5 分钟直接丢弃；

检查随机字符串（Nonce），结合 Redis 的 SETNX 记录最近处理过的 Nonce，防止重复截获重放。

可借助站内的 [哈希散列计算器](/tools/crypto) 与 [Unix 时间戳转换器](/tools/timestamp) 协助日常本地签名与有效期的模拟自测。

---

3. 消费端终极防护：接口严格幂等性设计（Idempotence）#

即使网络完全合规，面对三方支付平台不可避免的重试机制，接口必须具备执行 1 次与执行 100 次结果完全相同的幂等性。

go
// Go 语言实战示例：利用 Redis 分布式锁 + 数据库唯一索引保证原子幂等
func HandlePaymentCallback(orderNo string, notifyData []byte) error {
    // 1. 获取分布式锁，防止高并发下毫秒级重复请求同时穿透
    lockKey := fmt.Sprintf("lock:pay_notify:%s", orderNo)
    locked, err := redisClient.SetNX(ctx, lockKey, "1", 10*time.Second).Result()
    if err != nil || !locked {
        return errors.New("concurrent callback in progress, retry later")
    }
    defer redisClient.Del(ctx, lockKey)

    // 2. 开启本地数据库事务，行级锁查询订单当前状态
    tx := db.Begin()
    var order Order
    if err := tx.Clauses(clause.Locking{Strength: "UPDATE"}).Where("order_no = ?", orderNo).First(&order).Error; err != nil {
        tx.Rollback()
        return err
    }

    // 3. 幂等关键：如果订单已是支付完成状态，直接返回成功，绝不重复发货
    if order.Status == "PAID" {
        tx.Rollback()
        return nil // 告知三方平台已经成功处理，无需再次重发
    }

    // 4. 更新订单状态并记录交易流水（流水表建有唯一索引 uk_order_no）
    order.Status = "PAID"
    tx.Save(&order)
    tx.Create(&PaymentRecord{OrderNo: orderNo, Payload: string(notifyData)})

    return tx.Commit().Error
}