【业务】opaytap支付测试文档
概述
背景:我在这家公司首次接触三方支付的记录文档,因为利益博弈的原因,专门测试支付业务qa回故意不提供测试点来提高所谓的门槛,这种行为非常low,主要集中女性为主(非性别歧视,客观陈述)花费不少时间去弄的,做个测试文档留给后面需要接入的人。
测试支付难点2方面:
①研发支付都是工厂模式,你首次接手不知道具体逻辑,花费不少时间去理解。
②异常的测试点,需要发散所以难点核心。
业务:这个两个都是三方支付走的302跳转到对应支付页面,并且后端逻辑都是一致的,所以归纳一个文档。相同流程tap不在单独书写了。
OPAY后台账号(主要三方支付后台)
OpayThe opay merchant dashboard is an international merchant dashboard that currently supports Egyptian and Nigerian merchantshttps://dashboard.opaycheckout.com/get-started
支付流程
H5下单页->302跳转到opay的账号页面->验单->增加资产。
1.获取档位
(/seller/gear/groups):
作用:支付渠道位置,对应渠道档位。
入参:country,tuid
测试点:接口返回支付渠道位置和档位。
因为研发这个是根据不同国家分辨配置例如KA,OM等单独走的,所以每个要核对。
{支付渠道位置(位置决定了点击概率->产品很敏感),
ps:这个是配置有可能出现配置错误的问题,一定主要注意跟文档对应。
2.下单
/payx/v2/create
数据流转:调用seller验证档位->写入cl_orderxxes表->payment微服务->写入cl_order_2021->cl_pay_2021表。
2.1 校验档位
测试点:这个点校验入参product_id要存在,和非type对应product_id
cl_orderxxes表:
select * from fina.cl_orderxxes a where a.code="ORDEDB20210924032100987559979A";
核心字段:type->1 待支付状态--->0 支付成功
2.2 PHP下单逻辑:
V2controller->
createBlock设置opay
Payment(微服务)
日志路径:/data/dockerdata/payment/20210924/06e78d72b623
PS:最后加密串是每次部署docker容器id,所以需要申请root权限
docker ps |grep payment
测试点
1.下单所有档位都要走一遍
这个我刚开始是不太理解,这个链路一个通了为啥都要走,我遇到一次,原因在于三方对于下单金额最大值或者最小值可能会有拦截。
payment->opay支付
https://doc.opaycheckout.com/api-signature
下单接口payment调用入参有签名校验的,所以下单失败你要看下日志,很简单,测试环境242机器上。
3.验单
3.1 页面调用
数据流转:H5->PHP->payment->opay
验证订单id是否支付成功。
测试点
1.是否可以302跳转到并调用/payx/orderInfo->验单->增加资产
2.订单id未支付时,是否可以增加验单成功
3.订单id已支付&&已经增加财产,是否会再次增加资产。(是否有去重校验)
4.接口并发(是否有锁)
3.2 opay回调payment服务(服务层面调用)
支付完成opay服务端发起调用payment接口告知支付状态。
测试点
1.第三方回调是否成功
原因:这里面开发重点签名,因为这是接入方(payment服务)是否正确
测试方法:查看payment服务 是否有新增payment_opay_notice.log 文件
支付完成会根据订单id查询到日志。
2.回调多次是否去重不会增加多次金币
原因:这个主要验证是否去重,而不是每次回调接口了会增加金币
测试方法:成功回调之后,你把日志payload字段值粘贴出来,在doc页面 再次调用/opay/pay_notice接口,看下是否会再次增加。
页面:
调用日志:
Tap 服务端回调
方法:正常走一单查看对应支付notice日志把入参copy出来->curl 调用通知接口->是否会再次增加金币
curl -X POST -d '{"amount":7.77,"api_version":"V2","card":{"fi"currency":"SAR","customer":{"email":"1429998907018059777@XXXX.com","first_name":"1429998907018059777"},"description":"","id":"chg_TS043920211052Oi032810663","live_mode":false,"merchant":{"id":"9230393"},"merchant_id":"","method":"POST","object":"charge","post":{"status":"PENDING","url":"http:/qa/notice/tap/pay_notice?x_token=1696e59b9900f809faab071b1ecd3e18&x_project=liveme&code=ORDBCD20211028075236551515199A"},"product":"","receipt":{"email":false,"sms":false},"redirect":{"status":"PENDING","url":"http://qa/notice/tap/redirect?code=ORDBCD20211028075236551515199A&project=liveme&payment_id=451"},"reference":{"transaction":"PAYBCD20211028075236580285320A","order":"ORDBCD20211028075236551515199A"},"response":{"code":"000","message":"Captured"},"save_card":false,"source":{"id":"src_bh.benefit","object":"source"},"status":"CAPTURED","threeDSecure":true,"transaction":{"amount":2.99,"asynchronous":false,"created":"1635339818599","currency":"SAR","expiry":{"period":30,"type":"MINUTE"},"timezone":"UTC+03:00","url":""}}' 'http://qa/notice/tap/pay_notice?x_token=1696e59b9900f809faab071b1ecd3e18&x_project=liveme&code=ORDBCD20211028075236551515199A'
调用截图:
同时你在查看243机器上notice的日志,会有新增。你在看余额是否增加。
验单异常逻辑
场景1:code对应订单未支付,调用 /payx/orderInfo接口
不会增加金币
场景2:验单接口并发(/payx/process)
选择原因:
场景上:这个接口暴露给客户单容易被抓取并发
code:实现逻辑有一个获取锁的逻辑,排除并发造成的增加资产多次的问题
实现方法:下单获取code,使用charles修改入参code这样返回失败结果。再次书写并发接口->只能增加一次财产。
风控:
因为支付类似工厂模式,都是一个个步骤,所以风控都是固定的,所以测试重点是否可以查询到。
灰度测试:
流程:微服务payment直接上线,PHP上线到灰度,H5会给到单独url地址,所以H5也要上灰度。
指向后端灰度:
这个我搞了好久,有点坑。
1.charles 给到映射到34.230.169.88
2.使用ios扫描 H5二维码 可以走完闭环。安卓和浏览器都不行
前端H5:
1.后端都上线后,虽然H5没有做逻辑处理,opay那边会有类似refer来源的校验,主要用户判断之前和之后来源方是否一致。无法直接把url拿来去填写信息。