完整的聚合支付中心设计方案

短命女 2022-09-02 00:56 181阅读 0赞

*  [一、项目目标][Link 1]
 *  [二、具体调用流程][Link 1]
 *  [三、支付中心架构设计][Link 1]
    
     *  [收银台][Link 1]
     *  [渠道网关][Link 1]
     *  [交易核心][Link 1]
 *  [四、目前预见的可能的问题][Link 1]

--------------------

## [一、项目目标][Link 2] ##

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

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

## [二、具体调用流程][Link 2] ##

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

*  首先我们来看一下支付中心的调用过程。业务系统、支付中心和第三方通道的交互流程图如下：

[![图片][49c71b5cc45fbdebe69b5f0d0fd32b9b.png]][Link 1]

各系统交互流程为：

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

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

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

**注意：**

1.  订单号问题，问题起因：有些应用系统，使用订单号上传，有些使用自己系统中的流水号上传并发起支付。所以这里设计如下：
2.   *  （1）应用系统上送的无论是订单号还是流水号，支付中心都不直接使用，而是进行记录，并重新生成一个唯一的流水号，上送第三方支付。

*   *  （2）第三方支付会在校验参数成功确认支付发起成功后，再返回由第三方支付生成的流水号，用于以后的账单查询，对账，退款等功能。
     *  （3）支付中心会保存三个流水、订单号。方便以后调用、查询。
     *  （4）在收到第三方支付的调用返回时，支付中心会重组调用返回参数，将应用上送的订单号，支付中心生成的唯一流水号，第三方支付返回的流水号，一并返回应用端，建议应用端都进行保留。

1.  这里还涉及到退款使用哪个号进行退款的问题，这里设计为：使用支付中心流水号判定使用哪一笔订单退款。上送了支付中心生成的流水号后，根据流水号和商户标识以及支付标识检索出来的结果，进行退款，退款金额不可超过该笔流水号支付的金额。应用端可以根据业务需求自行选择退款方式，支付中心只做和流水号相关的退款。
2.  有关收银台，现在有些第三方支付存在自己的收银台，有的没有，所以支付中心必须有自己的收银台，但同时如果第三方支付存在已有收银台也没有必要跳转两次。所以这里的逻辑设计为：如果第三方存在必须跳转的收银台，使用第三方收银台，其余情况直接使用支付中心收银台。

## [三、支付中心架构设计][Link 2] ##

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

[![图片][b85299ca2f56de3fe2d151783abbcc15.png]][Link 1]

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

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

### [收银台][Link 2] ###

[![图片][b794f314b6d08a3a5e16f05a753dcd1b.png]][Link 1]

### [渠道网关][Link 2] ###

[支付账户管理][Link 2]

[![图片][90536ff50f619009c30d92a812a2d3af.png]][Link 1]

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

[request解析器][Link 2]

[![图片][e64ec084370d528d49c10bb0490762fb.png]][Link 1]

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

### [交易核心][Link 2] ###

[![图片][c370e6cd7b78f7e958ccdb572df6abd8.png]][Link 1]交易核心的数据库设计

[![图片][5d07aaace69742eb691b4c2fe72e6359.png]][Link 1]分账资金流向

## [四、目前预见的可能的问题][Link 2] ##

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

\- END -

[Link 1]: /images/20220829/f70f888c514948c4881df03b7639d4b4.png
[Link 2]: https://mp.weixin.qq.com/s?__biz=MzUzMTA2NTU2Ng==&mid=2247487551&idx=1&sn=18f64ba49f3f0f9d8be9d1fdef8857d9&scene=21#wechat_redirect
[49c71b5cc45fbdebe69b5f0d0fd32b9b.png]: https://img-blog.csdnimg.cn/img_convert/49c71b5cc45fbdebe69b5f0d0fd32b9b.png
[b85299ca2f56de3fe2d151783abbcc15.png]: https://img-blog.csdnimg.cn/img_convert/b85299ca2f56de3fe2d151783abbcc15.png
[b794f314b6d08a3a5e16f05a753dcd1b.png]: https://img-blog.csdnimg.cn/img_convert/b794f314b6d08a3a5e16f05a753dcd1b.png
[90536ff50f619009c30d92a812a2d3af.png]: https://img-blog.csdnimg.cn/img_convert/90536ff50f619009c30d92a812a2d3af.png
[e64ec084370d528d49c10bb0490762fb.png]: https://img-blog.csdnimg.cn/img_convert/e64ec084370d528d49c10bb0490762fb.png
[c370e6cd7b78f7e958ccdb572df6abd8.png]: https://img-blog.csdnimg.cn/img_convert/c370e6cd7b78f7e958ccdb572df6abd8.png
[5d07aaace69742eb691b4c2fe72e6359.png]: https://img-blog.csdnimg.cn/img_convert/5d07aaace69742eb691b4c2fe72e6359.png