背景

我个人支付相关内容测试很少（不是你想接什么业务就能接到，都是各方利益博弈以后结果），有些内容也是听听技术会议，看看其他qa的xmind通过只言片语里面做个总结。

支付类型

直连支付

概述：提供支付接口的渠道提供的支付方式归类为直连支付，支付页面由我方完成设计和开发；我方可以管理用户的账单地址和历史卡，用户在付款的时候可以点击历史卡和历史账单地址完成付款，灵活性高体验好；上报风控可以提供用户卡信息。

渠道：ingenico，stripe。

ingenico直连支付页面：

跳转支付

概述：不提供支付接口的渠道提供的支付方式归类为跳转支付，支付页面由渠道方完成设计和开发，灵活性低体验相对较差。上报风控无法提供用户卡信息。

渠道：钱海，coda等

点卡支付（代金劵）

概述：支持点卡或者代金劵付款的渠道提供的支付方式归类为点卡支付。渠道方不提供支付接口，点卡支付类似于跳转支付，支付页面由渠道方提供，不同之处在于点卡支付在下单的时候，不确定金额和金币，用户在渠道方页面选择点数或者输入代金劵序列号，验单的时候校正金额和金币。

渠道：mintroute等

mintroute代金劵支付：

app支付

概述：应用内支付，由商店提供的支付方式，通过用户商店账户里绑定的银行卡完成扣款，渠道方不提供支付接口。上报风控无法提供用户卡信息。

渠道：Apple支付，谷歌支付，华为支付，三星支付。

表业务设计

对于功能测试和业务设计来说都是重点，也方便我们理解支付流程。

业务表：

cl_orderxxes：业务订单表，uid/code/money/gmoney/product_id/gold等

cl_orderxx_payloads：业务订单扩展表，存储与各微服务的交互数据，币种/档位信息/优惠卷信息等

cl_order_refund：业务退款表，记录退款以及退款追回的数据

底层微服务表：

cl_sorder_20xx（无金币数据，掉单验单依赖）

cl_pay_20xx（支付流水，状态只能到0）

cl_refund（退款记录，状态<0）

cl_sorder_notice_20xx（异步通知业务端，掉单通知依赖）

cl_channel_webhook_20xx（渠道方异步通知我们）

支付配置表：

把各渠道档位固定信息存储在数据库中，不硬编码。

cl_gear（档位信息）

cl_gear_group（档位组）

cl_gear_rate（汇率）

cl_payment_channel（渠道）

服务功能

payment（支付中心）

支付服务主要负责与渠道方的交互，包括金额/币种的校验，支付/订阅掉单修复，订阅续订，异步通知管理，用户常用渠道管理，卡信息管理等。

paycontroller（支付控制中心）

支付控制中心主要负责权限控制/请求转化/操作日志，业务端的所有请求都需要经过paycontroller才能到达payment。

finance

金融微服务在支付流程中扮演的角色是增加和扣减用户的金币。

seller

售货台微服务主要负责管理渠道/档位/汇率等数据，为用户提供档位列表。

risk（风控服务）

风控服务接收业务端上报的支付事件，对用户的支付行为进行拦截和控制。

PHP服务端

业务端主要负责协调各个微服务，控制并完成支付流程。

支付掉单修复

概述：扫描cl_sorder_20xx表获取指定时间内的未完成订单，根据payment_id调用相应渠道的验单方法，完成验单后，给业务端发送支付通知，触发业务端验单流程和支付完成事件；掉单修复根据订单状态划分两个任务：30分钟任务（status=1）和10分钟任务（status>1）。

支付退款

概述：用户向银行或者渠道方发起拒付申请（退款）申请，通过后渠道方会向payment发送支付拒付（退款）通知，payment在cl_refund表生成退款记录后，向PHP业务端发出退款通知，业务端追回金币并上报风控。

支付对账

概述：支付对账可以在支付流程之外发现掉单和汇率亏损情况。日对账获取双方最近一天内的账单数据，月对账获取双方最近一个月的账单数据，对比双方的账单差异，生成对账报告和对账柱状图，来反映掉单情况和汇率亏损情况。

支付报警

概述：通过分析不同渠道的支付数据，总结分布规律，通过支付转化率曲线图和支付阀值报警，定位支付故障，评估支付渠道方的服务质量。

ps:这个主要考验阈值设定，太高发现不了问题，太低报警太多就不跟进了。

接入一个三方支付渠道流程

花钱和时间总结经验流程

1.了解一下要接入的渠道，如果对方是刚起步，或者未完全开发完毕，建议停止接入。

2.拿到对方的技术文档后，研究一下对方的接入流程是否存在刷单风险（比如支付的参数能否篡改，跳转链接的数据修改后会不会错发金币，支付凭证是否可以多次付款等）。

3.对方的数据与我们的订单能否关联，没有的话怎么防止被刷单。

4.对方的webhook有没有签名，没有的话要尽量做防刷处理。

5.验单的时候，金额/币种/档位ID有的话都要验证，没有的话可以考虑不接了。

6.验单上锁，阻塞锁+乐观锁。

7.掉单修复。

8.如果对方提供服务端对账服务，要接入对账服务。

GooglePlay支付功能测试

我测试客户端逻辑重不多，直接xmind吧测试点，重点还是跟业务交叉点上。支付只是手段，业务才是核心。

GP支付流程

拉取档位->下单->支付成功 ->验单->加金币-> 退款

在进行支付之前， 会判断是否有未消耗订单，如果有未消耗的订单， 点击同一个档位， 需要先修复未消耗的订单， 如果是不同的档位， 则会走正常支付流程； 点击客户端地步的修复， 客户端会把GP sdk 中未消耗的订单，挨个执行1遍