来源 | ////

01. 1. 项目目标

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

1、建立统一的基础订单、支付、财务系统，抽象封装公共处理逻辑，形成统一的基础服务，降低业务接入成本和重复研发成本；

2、构建安全、稳定、可扩展的系统，为业务快速发展和创新需求提供基础支撑，解决业务“快”与支付“稳”的矛盾；

3、沉淀核心交易数据，为应用、物业企业、用户提供数据支撑。

02. 2.具体调用流程

在目标的指导下，我咨询了集中采购、O2O、收费三个项目组的相关开发人员的业务逻辑，然后结合我们自己的业务场景调整了支付中心的调用流程和两个注意点。 首先我们来看看。 支付中心的调用流程。 业务系统、支付中心、第三方渠道交互流程图如下：

各系统的交互过程为：

1、物业公司开通第三方支付通道商户，获取第三方支付参数

2、物业公司向支付中心提供第三方支付参数，开立商户账户，开通支付通道，获取商户ID和支付ID。

3、物业公司向应用提供商户标识和支付标识。 至此，物业公司注册流程就完成了。 接下来是付款流程。

4、应用程序使用物业公司提供的商户标识和支付标识，以及必要的支付订单号、支付金额、转账方式，发送至支付中心。

5、支付中心将获取到的标识解析为对应的参数，整合应用的请求参数，向第三方支付发起支付，并获取支付发起的结果。

6、支付中心将整合发起结果直接返回给应用程序。 请注意，这只是请求是否成功发起的通知，而不是最终支付结果的通知。

7、第三方支付激活用户支付或跳转到收银页面，或者小程序激活用户支付进行支付。 第三方支付获取用户的支付结果后。 向支付中心回拨通知。

8. 支付中心处理数据并回调通知应用程序。

9.应用程序处理订单信息，启动订单，并通知用户。

注意：1.订单号问题。 问题原因：有的应用系统使用订单号上传，有的使用自己系统中的序列号上传发起支付。 所以这里的设计如下：

（1）无论是订单号还是应用系统发送的序列号，支付中心都不会直接使用。 相反，它会记录下来，重新生成一个唯一的序列号，并将其发送给第三方支付。

（2）第三方支付成功验证参数并确认发起支付成功后，将返回第三方支付生成的序列号，可用于以后的账单查询、对账、退款等功能。

（3）支付中心会保存三个交易号和订单号。 以后打电话查询也方便。

（4）支付中心收到第三方支付的调用返回时，会重新整理调用返回参数，返回应用发送的订单号、支付中心生成的唯一序列号、支付中心返回的序列号。第三方支付给应用程序。 端，建议保留应用端。

2、这还涉及到用哪个号码退款的问题。 这里的设计是：通过支付中心序列号来确定使用哪个订单进行退款。 支付中心生成的序列号提交后，将根据序列号、商户ID、支付ID检索结果进行退款。 退款金额不能超过使用序列号支付的金额。 应用方可根据业务需求选择退款方式，支付中心仅办理与流水号相关的退款。

3、关于收银员，现在有的第三方支付有自己的收银员，有的没有，所以支付中心必须有自己的收银员，但同时如果已经有第三方支付的收银员，无需跳两次。 所以这里的逻辑设计是：如果有必须跳转的第三方收银员，就使用第三方收银员。 其他情况，直接使用支付中心收银台。

03. 3.支付中心架构设计

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

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

1、支付中心后台：主要与账户管理相关，为物业公司开户、支付等提供支持。

2.支付消息：主要用于通知应用方

3、事务核心：基本事务核心，用于支持整个系统，参数组装和发起、返回数据处理、异常处理和通知等。

4、通道网关：解析应用程序发送的请求、设置和使用证书白名单、调用第三方API等。

支付中心后台：

收银台：

通道网关（一）支付账户管理

物业公司选择自己需要的支付渠道开通。 用户选择他喜欢的付款方式。 最终请求由支付中心处理，收入归入相应收款账户。

(2) 解析器

请求进入解析器后，首先解析支付标识，决定使用哪个支付插件（, , ），然后解析调用方式（小程序、PC、APP），获取可用的支付插件（utor ,)最后选择方法( )

Core： Core的数据库设计：

子账户资金流向：

04. 4.目前预计可能出现的问题

1、如数据监测出现数据异常或错误，请及时通知钉钉群。

2、数据一致性问题我们的系统计划暂时只有一个模块，应用端可以去支付中心同步数据。

3.稳定性问题。 第三方支付不够稳定。 主要原因是用户可能无法使用微信支付，然后使用支付宝支付。 这就需要应用端进行监控，支付中心会针对提供的不同订单号实时发起支付。 对于同一订单号，连续两次启动的时间间隔不得超过15秒。