• 修改支付价格

在支付当中，购买商品一般分为三步骤：订购、确认信息、付款。然后前；两步存在验证机制则在最后一步修改价格。其修改的金额值你可以尝试小数目或者尝试负数。

• 修改支付状态

修改支付状态为已支付状态这样的思路，因为支付状态的值跟实际订单支付状态进行校验，导致点击支付时抓包修改决定支付或未支付的参数为支付状态的值从而达到支付成功。

• 修改购买数量

假如购买的商品为两件，单件价格为300，当修改个数值为负值时，那么金额也会变成负数，从而产生支付漏洞。

• 修改附属值

修改优惠劵金额：通过选择已有优惠券，然后修改金额大于实际商品金额则可以产生零金额付款漏洞，或者将支付金额修改为负值再进行支付，在没有验证的情况下会产生支付成功漏洞

修改优惠劵金额及业务逻辑问题：通过上面案例修改优惠券金额进行支付，可能会存在支付验证失败的情况，这种情况主要是后台数据集对金额进行了校验，但是出现金额验证失败实际已经产生了商品订单，返回订单页面可以看到使用优惠券之后金额为修改为负值金额或最低为一元金额，则可以使用商品页面自带的钱包进行支付，并支付成功

修改积分金额：

当支付中有积分抵扣金额的可以尝试修改积分数值，如果该积分值未进行校验则可能存在积分抵扣金额零支付漏洞

• 修改支付接口

在支付的时候如果api接口未进行验证则可能存在api支付调用的风险，通过已支付api接口对未支付的订单进行调用则会付款成功，还有一种情况是支付api接口未中绑定用户的情况下，可以修改为一个不存在的支付接口，则会发生支付成功漏洞

• 多重替换支付

首先分别下单两个不一样的商品订单，然后通过抓取其中一个商品的uid进行付款，则会产生低价商品价格买高价商品的支付漏洞

• 重复支付

假如某某网站存在试用商品申请或者有试用商品资格的活动可以测试改漏洞，首先在申请的时候进行抓包，保留参数值以及已获得该资格的请求包，对该请求进行重发则重新获得该资格，在无验证次数的情况下可能存在该漏洞。

• 最小面额支付

通过积分充值活动则产生以下支付问题，充值的时候100积分面值200块钱， 实际充值付款你要付款100元，但是如果存在支付漏洞，积分充值系统未进行金额校验则有可能产生付款100元变成零元，但是系统会提示最低付款1元则存在支付漏洞。

• 最大值支付

假如积分值和优惠券的值修改为无上限值则可能触发零元支付漏洞，首先最大值支付参数系统未进行设定，导致业务逻辑代码无法执行对应数值并调用数据库验证机制，从而返回为空参数进行支付。

• 无限试用商品

某些线上店面会搞活动，活动期间可以购买多少件商品，并且时间为一天，第一天我们从试用产品接口出进行抓包，然后获取到试用名额，通过该名额参数第二天重复这样的操作则可以实现活动期内无限享有试用资格

• 越权支付

通过支付提交会显示uid/username/api/路劲等参数，通过另一个账号可访问到该支付路劲，并显示支付信息则会生一个越权支付漏洞，还有一种操作是本账号进行支付操作，然后修改别人的支付参数也可以做到越权支付。