erlang_pay 系列第二篇。这篇不限于 Erlang——不管你用什么语言接支付回调验签的原理是同一套。第一篇erlang_pay为 Erlang 补上支付这块拼图想象一个场景。你的服务器收到一条 HTTP 请求内容大意是“你好我是支付宝。订单 R123用户已付款 1000 元请发货。”问题来了你怎么知道这条消息真的来自支付宝发送方可能是支付宝的通知服务器也可能是我——一台笔记本、一条curl命令就够了。如果你的服务器看到支付成功四个字就发货那你的商品等于免费送任何人只要知道你的回调地址和订单号格式就能伪造回调。防这个的机制就叫验签。用公文打个比方支付宝发来的每条通知都盖了一个防伪章你的服务器收件后第一件事不是拆包裹而是验章。章是假的包裹直接扔掉。erlang_pay 的铁律先验章再拆包这个库把先验签、后解析写成了不可绕过的规矩验签失败报文一个字节都不解析。不是解析的时候小心一点而是根本不碰。为什么顺序这么重要因为解析报文本身就有风险——恶意构造的数据可能在解析阶段触发各种意想不到的路径。章都没验凭什么拆人家的包裹三家机构的防伪章做法各不相同erlang_pay 三种都实现了机构章你验章用的钥匙支付宝RSA2 签名支付宝公钥微信 v3平台私钥签名 AES-256-GCM 加密的敏感字段微信平台公钥StripeHMAC-SHA256webhook secret开通 webhook 时给的那串前两种是非对称签名支付宝/微信用它们自己保管的私钥盖章你用公开的公钥验章。私钥不离手所以别人盖不出同样的章——这就是防伪的原理。Stripe 更轻量双方共享同一个 secret各自对报文算一遍 HMAC对得上就是真件。三个容易漏掉的防伪细节章的机制各家文档都写了但下面三个细节不做也不会立刻出事——出事的时候你甚至查不到被攻击了。erlang_pay 把它们做进了代码里。细节一防重放——门票当日有效攻击者拿到一条真实的回调报文比如从某处日志、网络截获自己不动手伪造直接原样重发 100 遍呢签名是真的验签全过——你的服务器就把同一个订单发货100 次。防法很朴素真通知里带时间戳过期不认。微信的回调带Wechatpay-Timestamp头erlang_pay 只接受与服务器时间相差±300 秒以内的通知源码里epay_wechat.erl的?NOTIFY_TOLERANCE 300。五分钟前的真件尚且拒收昨天捡来的票自然进不了场。细节二常量时间比较——对暗号不能露表情验签的最后一步是比较两个字符串算出来的签名和对方带来的签名。直觉写法是逐字符比第一个字符不同就返回假。问题出在返回得快上。逐字符比较遇到第一位不同立刻结束遇到完全相同才比到最后——耗时不一样。攻击者可以掐着秒表一位一位试以a开头的签名响应是不是快一点点这就叫计时攻击不用破解密码学靠表情猜出答案。erlang_pay 里验 HMAC 用的是自己实现的常量时间比较epay_crypto:constant_time_equal/2核心就一行循环ct_equal(A,RA/binary,B,RB/binary,Acc)-ct_equal(RA,RB,Accbor(AbxorB)).不管哪一位不同都把全部字符比完才给答案——比较过程没有表情。顺带说明两个串不等长时直接返回 false、不用逐字节比——用源码注释的原话说“长度本身非秘密”。细节三章是真的还要核对收件人假设验签通过——这确实是支付宝发的通知。还有一步是发给你的吗一个支付宝开放平台可以挂多个应用每家商户有自己的app_id。一条发给别人的支付成功通知别人的订单签名同样是真的。所以 erlang_pay 验完签还要核对通知里的app_id和你Cfg里的是否一致不一致返回app_id_mismatch。门卫验了工牌是真工牌还得对一下名单这位今天约的是不是你这间办公室。最重要的一条验签通过 ≠ 可以发货这是本篇最想纠正的误区。很多教程的代码长这样验签 → 拿到订单号 → 标记已支付 → 发货。中间缺了两步钱就漏了。erlang_pay 的 README 里写明了阶段语义值得每个做支付的人都抄下来verify_notify 通过 只证明一件事AUTHENTICATED —— 这条通知确实来自支付机构没被篡改 它不证明 ORDER_MATCHED —— 通知里的金额、订单和你数据库里的对得上 IDEMPOTENT —— 这条通知你没处理过重发的通知会来很多次 POSTABLE —— 这笔账现在该不该入订单状态可能不对验签只回答章是真的。名单要你自己对账要你自己记。回调可能来多次微信明确说通知可能重复同一单可能有多条金额不同的通知这些去重和匹配逻辑是你的业务责任库替你做不了也不该替你做。附一个宁可功能少的工程决策0.2 版本里 erlang_pay 有个模块epay_cert_mgr负责微信平台证书的自动下载、轮换和序列号管理。0.3.0 把它删了。原因写在 CHANGELOG 里证书生命周期的首次信任→轮换→serial 消费没有做成闭环留着它就有看起来生产可用的嫌疑。改成调用方自己注入平台公钥platform_public_key库只管验不管证书从哪来。做出删功能的决定比堆功能难。一个支付库里每个看起来自动化的环节都对应一份出了问题算谁的的责任——没把握闭环的宁可摆到明面上让你自己管。验签失败长什么样所有拒绝都有明确的错误码方便你排查为什么回调没生效错误码人话bad_signature章是假的或报文被改过missing_signature没带章serial_mismatch章是真的但用的钥匙版本对不上微信证书/公钥序列号不符timestamp_expired通知太旧疑似重放app_id_mismatch章真但收件人不是你每一条都对应上面讲的一个防伪环节。仓库信息GitHub: https://github.com/imboy-pub/erlang_payGitee: https://gitee.com/imboy-pub/erlang_payGitcode: https://gitcode.com/imboy/erlang_pay协议Apache-2.0版本0.3.02026-09-2321 个提交从 2026-06-14 到 2026-09-23自检命令rebar3 eunit213 用例、rebar3 dialyzer零警告、bash scripts/gate.sh清洁编译单测类型打包全门本文涉及代码均可复核src/epay_wechat.erl?NOTIFY_TOLERANCE 300、src/epay_crypto.erl:136constant_time_equal/2、src/erlang_pay.erl门面与错误合同、README「安全要点 / 错误码」。IMBoy一个开源可私有化的 IM 平台Erlang/OTP 后端要收钱就有了这个库。erlang_pay 从 IMBoy 项目里长出来然后独立成仓回馈社区——它不绑定 IMBoy任何需要接支付渠道的 Erlang/OTP 项目都可以直接拿去用。系列第三篇日元没有分退款要带流水号支付代码里两条要命的规矩 erlang_pay 先验章，再拆包：支付回调的验签到底在防什么
erlang_pay 系列第二篇。这篇不限于 Erlang——不管你用什么语言接支付回调验签的原理是同一套。第一篇erlang_pay为 Erlang 补上支付这块拼图想象一个场景。你的服务器收到一条 HTTP 请求内容大意是“你好我是支付宝。订单 R123用户已付款 1000 元请发货。”问题来了你怎么知道这条消息真的来自支付宝发送方可能是支付宝的通知服务器也可能是我——一台笔记本、一条curl命令就够了。如果你的服务器看到支付成功四个字就发货那你的商品等于免费送任何人只要知道你的回调地址和订单号格式就能伪造回调。防这个的机制就叫验签。用公文打个比方支付宝发来的每条通知都盖了一个防伪章你的服务器收件后第一件事不是拆包裹而是验章。章是假的包裹直接扔掉。erlang_pay 的铁律先验章再拆包这个库把先验签、后解析写成了不可绕过的规矩验签失败报文一个字节都不解析。不是解析的时候小心一点而是根本不碰。为什么顺序这么重要因为解析报文本身就有风险——恶意构造的数据可能在解析阶段触发各种意想不到的路径。章都没验凭什么拆人家的包裹三家机构的防伪章做法各不相同erlang_pay 三种都实现了机构章你验章用的钥匙支付宝RSA2 签名支付宝公钥微信 v3平台私钥签名 AES-256-GCM 加密的敏感字段微信平台公钥StripeHMAC-SHA256webhook secret开通 webhook 时给的那串前两种是非对称签名支付宝/微信用它们自己保管的私钥盖章你用公开的公钥验章。私钥不离手所以别人盖不出同样的章——这就是防伪的原理。Stripe 更轻量双方共享同一个 secret各自对报文算一遍 HMAC对得上就是真件。三个容易漏掉的防伪细节章的机制各家文档都写了但下面三个细节不做也不会立刻出事——出事的时候你甚至查不到被攻击了。erlang_pay 把它们做进了代码里。细节一防重放——门票当日有效攻击者拿到一条真实的回调报文比如从某处日志、网络截获自己不动手伪造直接原样重发 100 遍呢签名是真的验签全过——你的服务器就把同一个订单发货100 次。防法很朴素真通知里带时间戳过期不认。微信的回调带Wechatpay-Timestamp头erlang_pay 只接受与服务器时间相差±300 秒以内的通知源码里epay_wechat.erl的?NOTIFY_TOLERANCE 300。五分钟前的真件尚且拒收昨天捡来的票自然进不了场。细节二常量时间比较——对暗号不能露表情验签的最后一步是比较两个字符串算出来的签名和对方带来的签名。直觉写法是逐字符比第一个字符不同就返回假。问题出在返回得快上。逐字符比较遇到第一位不同立刻结束遇到完全相同才比到最后——耗时不一样。攻击者可以掐着秒表一位一位试以a开头的签名响应是不是快一点点这就叫计时攻击不用破解密码学靠表情猜出答案。erlang_pay 里验 HMAC 用的是自己实现的常量时间比较epay_crypto:constant_time_equal/2核心就一行循环ct_equal(A,RA/binary,B,RB/binary,Acc)-ct_equal(RA,RB,Accbor(AbxorB)).不管哪一位不同都把全部字符比完才给答案——比较过程没有表情。顺带说明两个串不等长时直接返回 false、不用逐字节比——用源码注释的原话说“长度本身非秘密”。细节三章是真的还要核对收件人假设验签通过——这确实是支付宝发的通知。还有一步是发给你的吗一个支付宝开放平台可以挂多个应用每家商户有自己的app_id。一条发给别人的支付成功通知别人的订单签名同样是真的。所以 erlang_pay 验完签还要核对通知里的app_id和你Cfg里的是否一致不一致返回app_id_mismatch。门卫验了工牌是真工牌还得对一下名单这位今天约的是不是你这间办公室。最重要的一条验签通过 ≠ 可以发货这是本篇最想纠正的误区。很多教程的代码长这样验签 → 拿到订单号 → 标记已支付 → 发货。中间缺了两步钱就漏了。erlang_pay 的 README 里写明了阶段语义值得每个做支付的人都抄下来verify_notify 通过 只证明一件事AUTHENTICATED —— 这条通知确实来自支付机构没被篡改 它不证明 ORDER_MATCHED —— 通知里的金额、订单和你数据库里的对得上 IDEMPOTENT —— 这条通知你没处理过重发的通知会来很多次 POSTABLE —— 这笔账现在该不该入订单状态可能不对验签只回答章是真的。名单要你自己对账要你自己记。回调可能来多次微信明确说通知可能重复同一单可能有多条金额不同的通知这些去重和匹配逻辑是你的业务责任库替你做不了也不该替你做。附一个宁可功能少的工程决策0.2 版本里 erlang_pay 有个模块epay_cert_mgr负责微信平台证书的自动下载、轮换和序列号管理。0.3.0 把它删了。原因写在 CHANGELOG 里证书生命周期的首次信任→轮换→serial 消费没有做成闭环留着它就有看起来生产可用的嫌疑。改成调用方自己注入平台公钥platform_public_key库只管验不管证书从哪来。做出删功能的决定比堆功能难。一个支付库里每个看起来自动化的环节都对应一份出了问题算谁的的责任——没把握闭环的宁可摆到明面上让你自己管。验签失败长什么样所有拒绝都有明确的错误码方便你排查为什么回调没生效错误码人话bad_signature章是假的或报文被改过missing_signature没带章serial_mismatch章是真的但用的钥匙版本对不上微信证书/公钥序列号不符timestamp_expired通知太旧疑似重放app_id_mismatch章真但收件人不是你每一条都对应上面讲的一个防伪环节。仓库信息GitHub: https://github.com/imboy-pub/erlang_payGitee: https://gitee.com/imboy-pub/erlang_payGitcode: https://gitcode.com/imboy/erlang_pay协议Apache-2.0版本0.3.02026-09-2321 个提交从 2026-06-14 到 2026-09-23自检命令rebar3 eunit213 用例、rebar3 dialyzer零警告、bash scripts/gate.sh清洁编译单测类型打包全门本文涉及代码均可复核src/epay_wechat.erl?NOTIFY_TOLERANCE 300、src/epay_crypto.erl:136constant_time_equal/2、src/erlang_pay.erl门面与错误合同、README「安全要点 / 错误码」。IMBoy一个开源可私有化的 IM 平台Erlang/OTP 后端要收钱就有了这个库。erlang_pay 从 IMBoy 项目里长出来然后独立成仓回馈社区——它不绑定 IMBoy任何需要接支付渠道的 Erlang/OTP 项目都可以直接拿去用。系列第三篇日元没有分退款要带流水号支付代码里两条要命的规矩