侧边栏壁纸
  • 累计撰写 14 篇文章
  • 累计创建 10 个标签
  • 累计收到 0 条评论

目 录CONTENT

文章目录

简单谈谈支付相关的业务总结

ximu
2024-05-02 / 0 评论 / 0 点赞 / 45 阅读 / 2986 字

前言:

从入测试起也有不短的时间了,期间做过B端业务,也做过C端业务,试着总结一下最近几年的项目上的所得,因最近几年的项目都是以C端为主,所以本次主要说下C端项目并且和支付相关的项目内容,主要从一个测试的角度出发

支付类业务

从现金到线上支付,只要是互联网企业都需要一个收费的入口-线上支付,只不过大家熟悉的扫码支付还没有发展起来的时候,流行的还是使用银行卡刷卡支付,线上支付发展起来后,因为渠道费率的高低,又出现了许许多多非银行的渠道支付,比较常见的支付方式例如国内的微信,支付宝,国际的PayPal,adyen等等

业务分类

银行钱包

顾名思义,银行钱包需要直接与银行直接签订相关支付合同,工商,建行等等国内银行一般公司还真不能做到,主要是接入银行的API,业务更多的以安全为主,关注信息的安全和加解密,与业务的稳定性。B端业务.......

钱包管理

整体流程

绑定流程:钱包开通→验证个人信息并绑定银行卡→钱包开通成功

下单流程:创建订单→拉起收银台→钱包扣款→发货

测试注意点

1、创建订单:商品大部分情况下是托管给银行,传参一般只传id值,注意缓存和商品过期时间

2、钱包扣款:一般要注意扣款处理逻辑,一般来说的扣款逻辑都是从钱包扣款,如果余额不足也会,先从银行卡充值到钱包然后扣款

3、发货逻辑:一般的商品托管都会遇到性能问题,因为银行要监管订单的变动都是银行侧来决定每次查询状态都要先去查询一边银行如果没啥特殊处理,一定会有性能问题

三方支付

顾名思义,接入的是三方渠道,不需要有支付牌照,只需要和接入三方签订业务合同,商谈好结算费率,当然这些都不是我们关注的地方,我们主要关注实际的业务场景,一般来说具有一定规模都是通过统一的渠道管理对接外部第三方,内部使用时直接调用统一的渠道服务即可。

渠道服务管理

渠道服务是支付类的入口主要是对接支付渠道,管理支付渠道秘钥,商户信息等等,简化的整体流程

主动调用三方接口→

类似下单,退款之类接口调用,主要是接口测试关注参数即可

等待三方回调通知→

比如支付成功,支付失败,订单有争议,支付回调不及时等各种异常情况的处理,针对这类测试难点在于如何模拟回调。验证回调信息

第三方内支付→

支付流程基本都是第三方内完成,根据渠道方和地区的不同流程也不一样,一般分为几大类。

一是输入手机号信息扣点比如mycard、xsolla支付还有很多渠道在印尼地区都是采用输入手机号的形式

二是输入卡号信息cvv码等信息,比如wordpay,等等渠道只要是支持信用卡都是这个类型

三是会员扣点提前在账户里面充钱,使用的时候关联扣点就行比如越南的travellet,mycard等都有扣点

支付成功发货通知

内部调用渠道服务时,渠道服务收到第三方支付回调后,给内部调用的回调通知

测试关注点

1、支付主流程:三方支付的沙盒流程和正式环境的流程都不太一样

2、渠道服务传参信息:比如商品名称,商户主体,商品价格等等主体主体可能会传递的参数

3、货币系数:类似人民币系数为2,日元系数为0,不同的系数处理精度不同需要额外关注

4、支付异常场景:包括取消支付,支付pendding,支付失败,3D验证异常,信用卡状态异常等等

5、发货到账和退款:涉及到三方支付的退款链路一般很长,从发卡方到三方渠道到内部渠道等

业务共同点

xxxxxx

总结一下遇见的bug

xxxxx

0

评论区