支付漏洞属于逻辑漏洞，一般也只能做黑盒测试。
要挖掘这类漏洞，需要将思维发散，就是不要按常理出牌。这样就有可能找到程序员疏忽的地方。
一般测试的点有下面这些：
- 修改支付的价格
支付三部曲：选购商品，下订单，付款。
三个步骤当中随便一个步骤中进行修改价格测试，如果前面两步有验证机制，那么你可在最后一步付款时进行抓包尝试修改金额，如果没有在最后一步做好检验，那么问题就会存在，其修改的金额值你可以尝试小数目或者尝试负数。
- 修改支付状态
假设 A订单-0001 完成，此时 B订单-0002未完成
付款时尝试把订单B的单号改成订单A
修改订单中商品的数量
修改附属值，比如优惠券
一般用优惠券进行消费是出现在支付三部曲中的第二个步骤中：确认购买信息，在这个步骤页面当中，你可以选择相关优惠劵，然后直接修改金额大于或等于商品的价格就可以，或者直接修改其为负值进行尝试，最后进行支付，如果对这点没有加以验证，那么问题就会产生，直接支付成功
- 越权支付
比如，存在 user=id(123),这种传参时，尝试改改id,尝试用别人的钱包买自己的包包。
- 无限制试用
比如试用的参数为2，正常购买的参数为1，那么我们购买参数2（试用），会发生什么呢？
- 多线程并发
比如提现功能
假设有100块，每次提现10快，可以体现都少次？
按照开发人员的思路来说，100/10=10 就是10次嘛，那么对于程序来说呢？那就不一定了。
当然，多线程也可以在其它功能处进行测试，比如我之前讲到的试用商品问题，就可以通过多线程进行多几次的使用，比如利用积分兑换礼品，一个账户只能进行总换一次，利用这个问题，可以多几次兑换，一些转账功能，提现功能，购买功能等等很多。
另外，在挖掘此类漏洞的时候，就是要找到关键的数据包，因为可能一个支付操作有好几个数据包，该情况下就要对数据包进行筛选。
而且，支付数据包中会包含很多的敏感信息（如账号、金额、余额、优惠等），要尝试对数据包中的各个参数进行分析。
还有，在PC上尝试过后，还可以用手机端访问抓包试试。
下面就来实战一下。
进入靶场，点击某个商品，购买数量输入1，点击购买：
然后填写订单信息并提交：
提示余额不足。
在此可以猜测程序是否是： 余额 = 余额 - 需付金额数。
如果需付金额没有考虑负数的情况的话，那么余额就会变多。因此，可将购买数量改为负数来测试：
结果居然提交成功：
去会员中心查看余额，确实由原来的0元变为了593元。。。
那么，如何防止出现支付漏洞呢？我认为有如下几点：
- 后端要检查数据包中每一项的值，包括支付状态。
- 校验价格、数量参数，比如产品数量只能为整数，并限制购买数量。
- 与第三方支付平台检查，实际支付的金额是否与订单金额一致。
