支付全流程的测试

聚合支付与微信和支付宝区别与联系？？

聚合支付：

支付宝和微信扫同一个二维码都可以支付（支持多种支付方式），聚合支付是与多方合作的平台（支付宝、微信、京东）有合作关系

支付宝、微信、京东。。。。为第三方持牌照（支付牌照）机构

为什么要使用聚合支付方式？

统一入口支持多种支付方式，支付更加方便，用户体验会更好

清分：就是商家和第三方和银联的分钱

对账：就是聚合支付平台和第三方和银联的账目对比

结算：银行结账给聚合支付平台或者结账给第三方，然后第三方再给聚合支付平台

提现：聚合支付平台提现到商户

支付系统常见流程：

商户落网--对商户进行配置（支付方式、支付渠道）--商户激活收款码--发起支付--清分--对账--结算

支付后环节：商户提现（渠道提现，地推提现）--退款（商户）

商户入网流程：

商户入网测试点：

内部接口：

1、接口参数（必填项，字符类型，字符长度、银行卡，支付限额配置）

2、幂等性测试（并发测试（fiddler，charles，jmeter），重复发送同样的请求）

3、安全性：传输加密（敏感信息--四要素（姓名、身份证、手机号、商户号））

4、服务器日志（还原用户行为），日志对敏感信息脱敏处理

5、数据存储（加密处理）

6、状态转换（审核中、审核通过、审核拒绝）

7、异步接口（同步接口）、回调（根据第三方生产接口文档自己模拟、Mock服务）、查询

外包接口（抓包）

其他测试点同内部接口

商户配置测试：

测试点：

1、接口参数（必填项，字符类型，字符长度、各个字段）

2、配置多种/单种支付方式（同一个上游渠道而言）

3、渠道优先级（支付渠道的优先顺序）

4、支付方式商户配置完成之后，检验配置生效（支付一笔，抓包校验）

5、内部接口参数校验，外部接口参数校验

支付测试：

资金流和信息流：

橙色为资金流，黑色为信息流

管理平台：订单详情

测试点：

1、内部接口，外部接口

2、接口参数

3、安全（加密、日志脱敏）

4、订单号的唯一性（大数据量的接口并发）、订单号的生成规则（5万多单，问开发uuid，uuid一般来说都是唯一性，但是需要校验大数据并发情况下是否会爆出异常）

5、数据库连接池（内存泄漏），数据校验

6、请求频次（同一个ip，一般来说一秒钟不会超过10次，多线程并发）

7、接口回调（各种场景）、查询（异步当中的主动查询结果）

8、重复支付（同一笔订单，订单号相同，只能成功一笔），可能出现在开发尚未做防抖操作

9、弱网支付（wifi 、5G4G3G，网络切换），考虑参数和丢包，接口重连

10、接口幂等性（支付两笔，所有的数据都一样）

11、支付金额边界值（限额，当天最大支付金额，单笔最大支付金额，最小支付金额，小数位（精度）、小数位的取舍）

12、手续费（定制化，根据公司的需求）

13、性能

14、支付方式枚举（微信、支付宝、京东、美团、、、、）

15、支付渠道切换、组合支付

清分测试：

清分：就是一个分钱的过程

测试点：

1、清分时间（一般来说都是实时清分，数据库订单状态，清分明细）

2、清分明细表（记录各个角色分的账目明细）

3、通过定时任务（固定时间清分一次，批处理）

4、同一笔订单号只能清分一次（订单号）

5、精度问题（清分计算规则，小数取舍）

会计：资产=负债+所有者权益

1、四舍五入（账目对不齐）

2、银行家算法（四舍六入五考虑，五钱为基就进一，五钱为偶就舍去，比四舍五入误差小，但是任然账目对不齐）

3、兜底算法（目前行业的金额算法，一般是大头兜底，比如上图的地推、支付宝/微信、聚合平台当中一般就是支付宝/微信兜底[支付宝/微信=利润-地推-聚合平台支付金额]）但是退款就有平台来兜底

6、计算取值，计算过程是否有误

7、计算技巧：通过excel精准设置公式，直接填写数据即可

对账的逻辑：

1、以自己平台的订单和上游平台的订单进行对账（支付时间、订单号、支付状态（支付成功），金额）

2、以上游平台的订单为准，和自己平台的订单进行对账

3、支付对账，退款对账

4、对账执行时间：凌晨执行对账任务，设定定时任务的（批处理）

5、开始对账--是否有挂账（7天内去找掉单的数据进行对账）--是否掉单（在7天内去找掉单的数据进行对账）--对账完成

测试点：

1、支付结果：对平、挂账（自己平台有订单，上游无订单）、调单（我们平台没有上游有销账，平台未存储订单信息）

2、日切场景：在我们平台23:59:59，到上游第二天，数据构造（修改数据库、修改服务器时间）

3、销账

4、重复对账（平台支付），先删除（逻辑删除）当天的所有对账数据，重新对账

5、定时任务（校验正确触发）

6、对账性能（10万条账单，10分钟内完成对账）服务器资源考虑

7、对账单的解析：上游订单一般通过文件形式放到一个服务器上面，解析正常/解析异常逻辑

8、管理平台的数据统计

结算测试：

流程：

商户落网--对商户进行配置（支付方式、支付渠道）--商户激活收款码--发起支付--清分--对账--结算

支付后环节：商户提现（渠道提现，地推提现）--退款（商户）

结算讲解：

结算：平台做垫资（垫付资金）结算（信息流来进行垫资），为了垫资而做的结算，提升用户体验。

结算维度：机构(微信、支付宝、京东、美团)、渠道（进件商户公司，公司对公司）、商户（大商户）比如中石化

好处：控制资金流

结算发起的：2次审核（运营审核/财务审核登录上游平台）--发起结算

结算逻辑：结算服务根据你的结算维度获取对账结果，根据对账结果（对账对平的订单）进行结算

结算测试点：

1、运营平台进行操作结算（防抖问题，前端要做防抖）点一次发一个http请求，网络卡出发结算按钮（弱网测试，狂点）

2、后端接口：幂等校验（脚本并发）

后端实现：触发接口，提前请求一个接口，生成一个唯一的uuid给前端，然后前端再带着uuid去发起结算请求

3、重新结算（一般情况都支持）

4、非待结算的订单进行结算（未审核的订单进行结算）

5、未对账平的订单进行结算（不支持）

6、批量结算（支持）

7、性能结算（时间不能过长，一般不超过5分钟）

8、各种维度都要进行结算测试（不支持混合维度）

9、金额精度（小数处理，负数，0）

10、结算一定要稳定，容错性强（服务器原因挂了），恢复数据，数据库事务触发结算之前先备份结算相关的表数据

清分--对账--结算之间的关系

测试点：

1、清分：做告警处理，清分异常了

2、对账：对清分数据进行校验（对比支付笔数，如果笔数差距太大，就没必要对账，触发告警机制（没对平的超过多少比、未对平金融超过多少））、钉钉消息通知、微信消息通知、邮件、对账报错日志

3、结算：容错处理，对账结果混乱了(只要发现对账金额有问题的，马上停止结算，回滚已经结算的数据)

4、整个平台

1、页面数据校验，准确性、一致性

2、财务报表

商户提现测试：

角色：地推（销售、线下推广人员）、商户、代理渠道（机构）

提现流程：

客户端（web、app、小程序）--支付平台后端--发送提现请求到合作银行

测试点：

1、各个角色的提现，角色的状态

2、内部接口(异步)：客户端--支付平台后端（核对请求接口参数、测试场景）

3、外部接口(异步)：支付平台后端--合作银行（测试桩自测（mock测试）、联调测试：测试环境、线上环境（真实金额））

4、回调接口测试：外部回调（1、银行主动掉你；2、主动查询银行（1秒钟6次））

5、具体场景：

1、黑白名单(四要素（姓名、身份证、手机号、商户号），mac地址)

2、提现额度(每天提现额度（渠道）、单笔限额、用户余额（平台--银行(子账户)）)

3、提现额度锁定(余额=1000，提1000，（页面尚未扣除）二次发起提现不能成功，余额不足)

4、提现并发（2笔一起提现，消息队列(顺序)，锁额度的时间）

5、同一笔订单体现多次(后端做两个接口，A接口（返回uuid）和B接口(提现接口))，实现方式:jmeter或编写脚本

6、提现失败后的处理：(解冻额度、短信提现、支持重新发起提现)

7、运营：支持后端重新提现(运营操作)

8、提现手续费:查询用户配置的手续费与他提现的扣款的手续费是否一致

内扣：提现金额等于到账金额，扣余额的钱

外扣：提现金额大于到账金额，扣到账的钱

9、账户种类：余额、垫资账户、冻结账户、可提现额度（可提现额度=余额+垫资-冻结）

10、虚拟账户之间的关系要梳理清楚

11、通过脚本去校验

12、提现流水、出款渠道信息(出款路由逻辑)

退款测试：

测试点：

1、提现失败的退款：

1、对应银行接口文档各种失败的场景

2、退款各个账户计算是否正确

3、提现流水，数据逻辑删除（有效性）、失败原因

2、商家发起的退款：

1、全额退款

2、部分退款

3、退款清分(将支付订单利润退还，逆向清分)，平台承担银行支付产生的手续费（地推、渠道、商户），退款对账

4、退款金额原路返回

5、冻结商户的可提现金额，退多少冻结多少

6、单笔交易限制退款次数(避免退多次，垫付过多的手续费)

7、边界值(动了账户系统，提现金额边界值一定要测)平台余额，银行的余额

网关服务：

网关的作用：

1、服务转发

2、拦截攻击，无效请求（https加密CA证书和RSA非对称加密）

3、减少服务器压力

加密服务：信息加密，解密

交易服务：发起服务（金额、商户号、微信号、）

商户服务：检验商家信息

风控服务：非法请求拦截、黑名单（老赖、被执行人员、前科）

清分服务：就是商家和第三方和银联的分钱

对账服务：对账目对比

结算服务：结算服务根据你的结算维度获取对账结果，根据对账结果（对账对平的订单）进行结算

渠道服务：上游（出款渠道、支付渠道）、下游（合作商、合作机构）

支付合规：

国家严重把控：用户信息安全、资金安全

反洗钱：

1、洗钱：将非法所得合法化的行为

2、反洗钱：为杜绝洗钱行为，我国陆续出台了多部法律法规，对金融机构反洗钱工作进行指引，这些法律法规就是反洗钱系统建立的一句

3、相关文件

《金融机构反洗钱规定》

《金融机构大额交易和可疑交易报告管理办法》

《金融机构洗钱和恐怖融资风险评估及客户分类管理指引》

《金融机构客户身份识别和客户身份资料及交易记录保存管理办法》

反洗钱主要手段：

1、客户身份识别与客户风险评级

反洗钱评级模型根据人行的要求建立,综合考虑你的行业、所在地区、公司主营业务等等，对每一个客户进行风险评级

2、监控大额交易，对大额交易进行上报

1、当日单笔或者累计交易人民币5万元以上(含5万元)、外币等值1万美元以上(含1万美元)的现金收支

2、非自然人客户银行账户与其他的银行账户发生当日单笔或者累计交易人民币200万元以上(含200万元)、外币等值20万美元以上(含20万美元)的款项划转

3、自然人客户银行账户与其他的银行账户发生当日单笔或者累计交易人民币50万元以上(含50万元)、外币等值10万美元以上(含10万美元)的境内款项划转

4、自然人客户银行账户与其他的银行账户发生当日单笔或者累计交易人民币20万元以上(含20万元)、 外币等值1万美元以上(含1万美元)的跨境款项划转

支付二清（支付二次清分）：

二清定义：

1、二清就是二次清结算，本质是没有清结算资质的机构，却提供清结算的服务

2、比如有清结算资质的机构将资金结算给入网的商户后，该商户再将资金清结算给下游的子商户，若该商户没有清结算资质的话，就属于二清

二清分类

1、资金二清：

从资产安全的角度来说，资金二清危害大，二清公司能控制商户资金,存在卷走资金的风险，所以资金二清是需要严厉打击:

2、信息二清：

1、信息二清，二清公司只涉及到了信息的清算，而不接触资金,资金仍由持卡人清算协会直接支付给商户，二清公司为了获取交易信息，只就交易信息进行上传下达，这种情况是没有资金安全问题，但是这种行为也属于违规

2、金融安全不仅包括资金安全,包括金融信息安全。

《银行卡收单业务管理办法》:明确收单机构不得以任何形式存储银行卡磁道信息或芯片信息、卡片验证码、 卡片有效期、个人标识码等敏感信息

《关于加强银行卡安全管理预防和打击银行卡犯罪的通知》:明确"对于涉及客户信息和交易信息处理的外包服务机构,收单机构不得允许外包服务机构存储银行卡卡号以外的信息”

最后

以上就是自觉小伙为你收集整理的支付全流程的测试的全部内容，希望文章能够帮你解决支付全流程的测试所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。