支付漏洞不是支付一种独立的漏洞类型，它是漏洞攻击者绕过支付逻辑、篡改交易数据或欺骗支付系统校验的什漏一类问题的统称。你可以把它理解为一个筐，洞类里面装着逻辑缺陷、支付参数篡改、漏洞竞态条件、什漏加密缺陷、洞类接口滥用等好几种东西。支付真正危险的漏洞地方在于，这类漏洞往往不依赖什么高深的什漏内存溢出或注入技巧，有时候改一个数字就能白拿东西。洞类

我见过最离谱的支付一个案例，是漏洞一家小电商平台的支付回调接口。用户下单后，什漏前端发起支付，支付平台处理完会异步通知服务器“这笔订单已付款”。问题出在这个通知接口没有校验签名，也没有验证订单金额。攻击者直接构造一个HTTP请求，把订单号填进去，金额写成0.01元，服务器就老老实实把订单标记为已支付。后来这家平台在三个月里被刷走了两百多台手机，直到对账时才发现。

这属于典型的业务逻辑漏洞。支付流程的每一步——下单、计价、优惠、支付、回调、发货——只要有一个环节的校验可以被绕过，整条链路就崩了。逻辑漏洞的可怕之处在于，它跟代码写得好不好看没关系。你用了最安全的框架、最严格的类型检查，业务规则写错了照样出事。

另一类常见的是参数篡改。比如结算页面上商品单价是99元，攻击者用抓包工具把提交订单时的price字段改成0.01。如果服务端不重新从数据库读取价格，而是信任客户端传来的值，那就中招了。有些系统做了签名，但签名算法本身有缺陷——比如把参数按字母排序后拼接再MD5，攻击者可以增加一个不影响业务逻辑的冗余参数来改变签名结果，或者利用长度扩展攻击伪造签名。

竞态条件在支付场景里也特别多。最经典的是优惠券重复使用：用户有两张满100减50的券，正常只能用一张。但攻击者同时发起两个请求，服务端两个线程都查到“券未使用”，都扣减了金额，结果100元的订单只付了0元。这种漏洞在秒杀、提现、积分兑换里反复出现，根子在于“检查”和“扣减”之间没有原子性。

还有越权支付。比如A用户的订单ID是1001，B用户改成1002就能看到别人的订单详情，甚至能对别人的订单发起退款。更隐蔽的是水平越权结合支付回调：攻击者用自己的账号下单，拿到支付链接后把订单号替换成受害者的订单号，支付1分钱，受害者的订单就被标记为已付款。受害者什么都没做，货却发给了攻击者指定的地址。

加密层面的问题也绕不开。有些支付接口用AES加密请求体，但密钥硬编码在客户端APK里。反编译一看就拿到了。还有用ECB模式加密的，相同的明文块产生相同的密文块，攻击者可以拼接密文来篡改明文内容。更粗糙的是把金额用Base64编码就当加密了，这跟裸奔没区别。

我个人的观察是，支付漏洞的根源往往不在技术栈，而在开发者的假设。假设客户端会老老实实传正确的金额，假设回调通知一定来自支付平台，假设用户不会同时发两个请求，假设订单ID不可猜测。每一个假设都是一扇没锁的门。修复方式也因类型而异：逻辑漏洞要靠服务端重新校验所有关键数据，竞态条件要用数据库锁或分布式锁，加密问题要换用安全的密钥管理和加密模式。没有一劳永逸的方案，只有对每一笔交易保持怀疑。