支付回调必须验签,否则支付结果可被第三方伪造;微信用MD5验XML签名,支付宝用RSA2+SHA256验表单签名,均需按规则排序参数并忽略特定字段,且须幂等处理重试。
不验签的回调接口等于把支付结果完全交给第三方随意伪造。微信、支付宝等平台在回调请求中都会附带 sign 或 signature 字段,配合约定的密钥和参数排序规则生成,这是唯一能确认“这确实是平台发来的通知”的手段。
常见错误:直接信任 return_code=SUCCESS 和 result_code=SUCCESS 就更新订单状态——攻击者可伪造这两个字段和任意金额。
sign 字段,支付宝要求忽略 sign 和 sign_type)key1=value1&key2=value2&key3=value3&key=YOUR_KEY 格式后,用对应算法(微信是 MD5,支付宝是 RSA2 + SHA256)计算摘要crypto/md5 或 crypto/rsa + crypto/sha256,避免第三方包引入签名逻辑黑盒微信支付回调是 POST 请求,原始 body 是 XML 格式(不是 JSON),且要求响应必须是纯字符串 success(无空格、无换行、无 XML/JSON 包裹),否则会持续重试。
容易踩的坑:
r.ParseForm() 或 r.FormValue() 读取 —— 这会失败,因为微信不发表单数据,而是 raw XMLjson.Unmarshal() 解析 —— 类型错配,panicfmt.Fprint(w, "success") 但前面有日志或中间件输出了其他内容 —— 导致响应体含 HTTP header 外的杂字符,微信判定失败正确做法:
body, _ := io.ReadAll(r.Body)
var wxNotify struct {
ReturnCode string `xml:"return_code"`
ResultCode string `xml:"result_code"`
Sign string `xml:"sign"`
OutTradeNo string `xml:"out_trade_no"`
TotalFee int `xml:"total_fee"`
// 其他字段...
}
xml.Unmarshal(body, &wxNotify)
// ✅ 验签通过后再处理业务
fmt.Fprint(w, "success") // 必须是这一行,且仅此一行
支付宝用的是 GET 风格的表单编码(application/x-www-form-urlencoded),但实际是 POST 请求携带该格式 body;签名字段叫 sign,算法标识是 sign_type(常见 RSA2),且公钥验签需提前加载 PEM 格式公钥。
关键区别:
sign 和 sign_type)按参数名升序拼接,值不做 URL decode —— Go 的 url.Values.Encode() 会自动 encode,不能直接用crypto/x509 解析 PEM 中的 
-----BEGIN PUBLIC KEY----- 块out_trade_no 做数据库唯一约束或 Redis setnx)支付平台为保证通知到达,会在失败时重试(微信最长 4 小时,支付宝最多 6 次),而你的服务可能正在扩容、重启或网络抖动,导致同一笔订单的回调被多个 goroutine 同时处理。
简单但有效的方案:
UNIQUE KEY(out_trade_no),插入成功即代表首次处理,失败则跳过SET order_123456789 "processing" EX 300 NX,设置 5 分钟过期,防止死锁最常被忽略的一点:回调验签通过后,必须立即查一次商户系统内该订单当前状态。如果已是“已支付”,直接返回 success,不重复更新 —— 这比锁更轻量,也更可靠。