支付中心架构将各业务的公共交易、支付、财务等沉淀到支付中心,并主要解决了以下三个主要问题:
在目标的指导下,我向集采、o2o、收费易三个项目组的相关开发咨询了业务逻辑,再结合我们自己的业务场景调整了支付中心调用流程和两个注意点
首先我们来看一下支付中心的调用过程。业务系统、支付中心和第三方通道的交互流程图如下:
各系统交互流程为:
注意:
1.订单号问题,问题起因:有些应用系统,使用订单号上传,有些使用自己系统中的流水号上传并发起支付。所以这里设计如下:
2.这里还涉及到退款使用哪个号进行退款的问题,这里设计为:使用支付中心流水号判定使用哪一笔订单退款。上送了支付中心生成的流水号后,根据流水号和商户标识以及支付标识检索出来的结果,进行退款,退款金额不可超过该笔流水号支付的金额。应用端可以根据业务需求自行选择退款方式,支付中心只做和流水号相关的退款。
3.有关收银台,现在有些第三方支付存在自己的收银台,有的没有,所以支付中心必须有自己的收银台,但同时如果第三方支付存在已有收银台也没有必要跳转两次。所以这里的逻辑设计为:如果第三方存在必须跳转的收银台,使用第三方收银台,其余情况直接使用支付中心收银台。
目前的系统功能整体架构如下:
如图所示,从架构上主要分为四个大模块:
(1)支付账户管理
物业公司选择自己所需的支付渠道进行开通
用户选择自己倾向的支付方式
最后请求中由支付中心处理,收入对应的收款账户。
(2)request解析器
一个请求在进入request解析器之后,首先解析支付标识,决定使用哪个支付插件(alipayPlugin, wechatPlugin, easyPlugin)
其次解析调起方式(小程序,PC,APP)获取可用的支付插件(alipaypaymentappexecutor,xxxexecutor)
最后选择方法(onpay waponpay refund)
交易核心的数据库设计:
分账资金流向:
1,数据监控
出现数据异常,或者报错,及时在钉钉群里通知。
2,数据一致性问题
咱们的系统打算暂时只做一个模块,应用端可以到支付中心来同步数据。
3,稳定性问题,第三方支付不够稳定
主要是用户可能会用微信支付失败,又用支付宝支付。
这个需要应用端进行监控,支付中心对于提供的不同订单号会实时发起支付。同一订单号,连续发起两次之间间隔不超过15秒。
想要高效学习,指路微信公众号——【python编程学习圈】每日分享学习干货,关注即可免费领取整套Python零基础到入门资料及学习教程,走过路过,千万不要错过!!快行动起来!!
如果觉得我的文章对您有用,请随意打赏。你的支持将鼓励我继续创作!