完整的聚合支付设计方案,喜欢就拿去用吧!

强烈推介IDEA2020.2破解激活,IntelliJ IDEA 注册码,2020.2 IDEA 激活码
关注我们,设为星标,每天7:30不见不散,架构路上与您共享 

回复"架构师"获取资源

一、项目目标

支付中心架构将各业务的公共交易、支付、财务等沉淀到支付中心,并主要解决了以下三个主要问题:

  1. 建立基础订单、支付、财务统一体系,抽象和封装公共处理逻辑,形成统一的基础服务,降低业务的接入成本 及重复研发成本;
  2. 构建安全、稳定、可扩展的系统,为业务的快速发展和创新需求提供基础支撑,解决业务「快」和支付「稳」之间的矛盾;
  3. 沉淀核心交易数据,同时为应用端、物业公司、用户提供数据支撑。

二、具体调用流程

在目标的指导下,我向集采、o2o、收费易三个项目组的相关开发咨询了业务逻辑,再结合我们自己的业务场景调整了支付中心调用流程和两个注意点

  • 首先我们来看一下支付中心的调用过程。业务系统、支付中心和第三方通道的交互流程图如下:
完整的聚合支付设计方案,喜欢就拿去用吧!

各系统交互流程为:

  1. 物业公司开通第三方支付渠道商户,并获取第三方支付参数
  2. 物业公司将第三方支付参数提供给支付中心,开通商户号,开通支付渠道,获取商户标识和支付标识。
  3. 物业公司将商户标识和支付标识提供给应用端。

至此,物业公司注册流程完毕。接下来是支付流程。

  1. 应用端使用物业公司提供的商户标识和支付标识,以及必备的支付订单号,支付金额,调起方式,上送至支付中心。
  2. 支付中心将获取的标识解析到对应的参数,并整合应用端的请求参数,向第三方支付发起支付,并获取支付发起的结果。
  3. 支付中心将发起结果整合后直接返回给应用端,注意,这里只是这个请求是否发起成功的通知,并不是最终支付结果的通知。
  4. 第三方支付调起用户的支付或者跳转收银台页面、小程序调起用户支付进行支付,第三方支付获取到用户的支付结果之后。回调通知支付中心。
  5. 支付中心处理数据,并回调通知应用端。
  6. 应用端处理订单信息,并开始订单、通知用户。

注意:

  1. 订单号问题,问题起因:有些应用系统,使用订单号上传,有些使用自己系统中的流水号上传并发起支付。所以这里设计如下:
    • (1)应用系统上送的无论是订单号还是流水号,支付中心都不直接使用,而是进行记录,并重新生成一个唯一的流水号,上送第三方支付。
    • (2)第三方支付会在校验参数成功确认支付发起成功后,再返回由第三方支付生成的流水号,用于以后的账单查询,对账,退款等功能。
    • (3)支付中心会保存三个流水、订单号。方便以后调用、查询。
    • (4)在收到第三方支付的调用返回时,支付中心会重组调用返回参数,将应用上送的订单号,支付中心生成的唯一流水号,第三方支付返回的流水号,一并返回应用端,建议应用端都进行保留。
  2. 这里还涉及到退款使用哪个号进行退款的问题,这里设计为:使用支付中心流水号判定使用哪一笔订单退款。上送了支付中心生成的流水号后,根据流水号和商户标识以及支付标识检索出来的结果,进行退款,退款金额不可超过该笔流水号支付的金额。应用端可以根据业务需求自行选择退款方式,支付中心只做和流水号相关的退款。
  3. 有关收银台,现在有些第三方支付存在自己的收银台,有的没有,所以支付中心必须有自己的收银台,但同时如果第三方支付存在已有收银台也没有必要跳转两次。所以这里的逻辑设计为:如果第三方存在必须跳转的收银台,使用第三方收银台,其余情况直接使用支付中心收银台。

三、支付中心架构设计

目前的系统功能整体架构如下:

完整的聚合支付设计方案,喜欢就拿去用吧!

如图所示,从架构上主要分为四个大模块:

  1. 支付中心后台:主要是账号管理相关,物业公司的开户开通支付等提供支持
  2. 支付消息:主要是用于对应用端进行通知
  3. 交易核心:用来支撑整个系统的基础交易核心,参数组装发起,返回数据的处理,异常的处理和通知等。
  4. 渠道网关:解析应用端发送过来的请求,证书白名单的设置和使用,第三方api的调用等

收银台

完整的聚合支付设计方案,喜欢就拿去用吧!

渠道网关

支付账户管理
完整的聚合支付设计方案,喜欢就拿去用吧!

物业公司选择自己所需的支付渠道进行开通,用户选择自己倾向的支付方式最后请求中由支付中心处理,收入对应的收款账户。

request解析器
完整的聚合支付设计方案,喜欢就拿去用吧!

一个请求在进入request解析器之后,首先解析支付标识,决定使用哪个支付插件(alipayPlugin, wechatPlugin, easyPlugin)其次解析调起方式(小程序,PC,APP)获取可用的支付插件(alipaypaymentappexecutor,xxxexecutor)最后选择方法(onpay waponpay refund)。

交易核心

完整的聚合支付设计方案,喜欢就拿去用吧!
交易核心的数据库设计
完整的聚合支付设计方案,喜欢就拿去用吧!
分账资金流向

四、目前预见的可能的问题

  1. 数据监控:出现数据异常,或者报错,及时在钉钉群里通知。
  2. 数据一致性问题:咱们的系统打算暂时只做一个模块,应用端可以到支付中心来同步数据。
  3. 稳定性问题,第三方支付不够稳定:主要是用户可能会用微信支付失败,又用支付宝支付。这个需要应用端进行监控,支付中心对于提供的不同订单号会实时发起支付。同一订单号,连续发起两次之间间隔不超过15秒。

文章来源:https://blog.csdn.net/liuzhirou1/article/details/117649569


完整的聚合支付设计方案,喜欢就拿去用吧!


到此文章就结束了。如果今天的文章对你在进阶架构师的路上有新的启发和进步,欢迎转发给更多人。欢迎加入架构师社区技术交流群,众多大咖带你进阶架构师,在后台回复“加群”即可入群。







这些年小编给你分享过的干货

1.SpringBoot物流管理项目,拿去学习吧(附源码)

2.ERP系统,自带进销存+财务+生产功能,拿来即用(附源码)

3.带工作流的SpringBoot后台管理项目快速开发(附源码)
4.最好的OA系统,拿来即用,非常方便(附源码)

5.SpringBoot+Vue完整的外卖系统,手机端和后台管理,附源码!

6.SpringBoot+Vue 可视化拖拽编辑的大屏项目(附源码)

完整的聚合支付设计方案,喜欢就拿去用吧!

转发在看就是最大的支持❤️

本文原创,作者:架构君,其版权均为Java架构师必看所有。如需转载,请注明出处:https://javajgs.com/archives/24551

发表评论