现在有不少测试朋友做的项目中，可能也会涉及到支付相关的功能。比如：做商城的，做游戏的以及其他在线交易的网站、APP等。如果支付出了问题，或者用户拿少的钱通过篡改请求数据购买大金额的商品，如果是实物的话，发货前还有可能被发现。如果是虚拟商品话费、游戏币等就有可能造成损失。
所以，不管是实物也好，虚拟商品也好，涉及到支付功能时，大家在测试的过程中一定要重视，否则，会造成很大损失。之前可能大家也都看到过或者听过一个bug损失4.6亿美金的惨痛教训或者身边也有发生过其他因为支付功能的bug导致直接损失的案例。
给大家举个真实的案例：比如使用支付宝购买虚拟商品，往支付宝跳转时，篡改了小的金额，结果购买虚拟商品成功了。（原本10元的商品，0.01元就搞定了）。多么可怕的一个bug啊，当然这个问题可能对于一个做过支付有过经验的测试朋友来说，可能会想：哎呀，这个问题都发现不了，还做什么测试？是的，问题是很简单，对于一个刚入职场的测试朋友或者没有支付相关经验的测试朋友来说，很有可能会忽略。
那么，问题来了，对于支付模块的相关测试，我们应该如何进行呢？比如，针对游戏来说，使用第三方支付往游戏充值游戏币功能，看起来是不是很简单，大家主要思考下以下内容：
1、支付都是与第三方支付（支付宝、微信、财付通、QQ钱包、短信支付等）进行对接，那么，是否了解了第三方接口有哪些？是否都能清楚我们的产品与第三方是如何交互的？是否能画出流程图？
2、异常场景有哪些？
3、有哪些风险，如何规避？
第三方支付的流程，与商户的对接方式基本相似，大同小异。
先看下流程图，是否对流程图有些了解，不仅仅是做支付功能相关测试才去搞清楚其中的流程，做其他的测试一样也要搞清楚流程，只有搞清楚流程，才能更好的评估其中的风险，才能有利于测试用例的设计。当然流程图中只是提到了商户与第三方是如何交互的，同样商户内部处理的流程也要有所了解及数据怎么存储的，涉及到哪些DB也要清楚。
流程清楚之后，我们再来看看其中会涉及到哪些接口？这个支付流程图里面就涉及到了第三方支付接口：
· 下单接口：商户提交下单请求到第三方支付接口，第三方支付收单成功后返回下单成功结果给到商户系统。（下单接口的最终处理结果分为下单成功和下单失败，若未收到明确结果可调用单笔订单查询接口查询结果。）
· 支付接口：调用该接口时指定支付参数，完成买家账户向商户账户的支付，采用页面跳转交互模式和后台通知交互模式。（结果分为两路返回：一路为前台在return_url页面跳转显示支付结果；一路为后台在notify_url收到支付结果通知后进行响应。）
· 退款接口：调用第三方支付的支付请求接口返回付款成功后，在需要做退款处理时调用退款请求接口发起退款处理。（退款接口的最终处理结果分为退款成功和退款失败，若未收到明确结果可调用退款查询接口查询结果。）
· 单笔订单查询接口：根据订单号查询单笔订单信息和状态。
· 退款订单查询接口：调用第三方支付的退款接口返回后，在需要查询退款请求状态可调用退款订单查询接口查询退款订单的状态和订单信息。
那么针对第三方的接口，我们大致也有所了解了，接下来针对测试过程中涉及到主要的测试点整理如下：
测试过程中需要注意的主要测试点及异常场景：
· 首先要保证接口都能正常调用；
· 生成一笔订单，支付完成后，同步或异步重复回调，只有一次有效；
· 生成一笔订单，复制订单号和金额，再次生成一笔订单，用fiddler设置断点，用第一笔已完成的订单号和订单金额去替换现有的订单号和金额，无法完成支付；
· 生成一笔订单，跳转到第三方时修改金额，无法到账，或者如果是游戏充值游戏币的话，到账为篡改后的金额对应的游戏币；
· 异步通知屏蔽，同步有效，进行支付，同步能够正常到账；
· 同步设置无效，异步有效，进行支付，异步能够正常到账；
· 同步异步都设置无效，在第三方支付完成后，在重发机制时间范围内，设置异步有效，到下次通知时间点时，能够正常通知到账（补单机制的验证，如果商户收到第三方支付成功的通知后，要告知第三方支付收到了成功的通知，如果第三方支付收到商户应答不是ok或超时，第三方支付就会认为通知失败，会在规定的时间内持续调用notify_url，一般有时间或次数的限制）；
· 针对支付订单在数据库中存储是否完整和正确进行校验（比如：第三方订单号--方便与第三方对账和问题排查、订单金额、订单状态等）；
· 如果是用户购买实物商品，用户发起退货，要保证退货流程正常，资金能正常返还，要考虑下并发情况的验证以确保安全性；
· 如果是用户购买虚拟商品，比如话费、油卡之类的商品，只有在发货失败的时候才能发起退货，注意验证；
遇到过的坑：
· 用户购买100元游戏币时，前往第三方支付跳转进行金额的篡改由100元改成0.01元，结果就拿了0.01元充值了100元的游戏币。对订单金额没有做校验导致这样的后果，损失比较大。大家在测试的过程中一定要注意对服务端进行校验，支付时数据的篡改一定要有校验。
· 当同步、异步通知都存在的情况的，异步通知（第三方支付成功后台通知），没有到账，导致部分用户充值不到账，引起客诉。当同步、异步并存的时候，一定要分别对同步和异步进行检验，确保都能正常到账。
我们所做的绝大多少的互联网产品都会涉及到第三方支付，所以支付功能必然是重要的，作为测试互联网产品的一员，我们必须要做好支付的安全性。
那么，如何规避支付风险？
为了进一步的加强支付功能的安全，也可以适当的增加一些监控机制，比如：订单与第三方订单进行对比，可以使用跑批完成，当我们完成支付的订单从数据库中查出来与通过第三方订单查询接口查询出来的同一个订单金额有异常时，进行报警通知能够及时发现处理，甚至当有异常情况进行创建订单的终止，从而把损失降到最低。
当一个支付请求被发送到支付渠道方，支付渠道会很快返回一个结果。但是这个结果，只是告诉你调用成功了，不是扣款成功，这叫同步调用。很多新手会拿这个结果当作支付成功了，那就会被坑死，结果就是支付成功率特别高，伴随着一堆无法解释的坏账率，测试人员尤其要注意测试数据的篡改：金额，同步返回结果，订单号等。
同步请求参数里面会有一个回调地址，这个地址是支付渠道在扣款成功后调用的，这叫异步调用。一般同步接口仅检查参数是否正确，签名是否无误等。异步接口才告诉你扣款结果。一般异步接口有5秒以内的延迟。调用不成功会重试。有时候是这边成功了，但支付渠道侧没收到返回，于是会继续调。当天的支付到第二天还在被异步调用也都是正常的。这也是开发人员需要特别注意的地方，不要当做重复支付。测试人员也要对重复回调进行测试，应只有一次有效。这还不是最坑的，一般支付渠道侧，只有支付成功了才通知你。要是支付失败了，压根儿都不告诉你。 另一方面，如何老收不到异步结果呢？那就得查查了。同步结果不可靠，异步调用不可靠，那怎么确定支付结果？最终的杀招就是查单了，反查，一般支付渠道侧都会提供反查接口，定时获取DB中待支付的订单调用支付渠道侧的反查接口，最终把支付渠道侧扣款成功的订单完成掉。
微信大致流程为：APP端将订单信息提交到后台，后台通过微信统一下单接口到微信去下单，微信端返回相关信息到PHP后台，后台先将订单保存到数据库成功后，返回签名信息给APP端去实现真正的支付
支付宝大致流程为：APP端将订单信息提交到后台，后台通过支付宝规定的签名算法将签名信息返回给APP端，APP端调用支付宝SDK去实现支付
