【业务】支付总结和GP支付功能测试
背景
我个人支付相关内容测试很少（不是你想接什么业务就能接到，都是各方利益博弈以后结果），有些内容也是听听技术会议，看看其他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遍
