一、项目目标
支付中心架构将各业务的公共交易、支付、财务等沉淀到支付中心，并主要解决了以下三个主要问题：
1.建立基础订单、支付、财务统一体系，抽象和封装公共处理逻辑，形成统一的基础服务，降低业务的接入成本及重复研发成本；
2.构建安全、稳定、可扩展的系统，为业务的快速发展和创新需求提供基础支撑，解决业务「快」和支付「稳」之间的矛盾；
3.沉淀核心交易数据，同时为应用端、物业公司、用户提供数据支撑。
二、具体调用流程
在目标的指导下，我向集采、o2o、收费易三个项目组的相关开发咨询了业务逻辑，再结合我们自己的业务场景调整了支付中心调用流程和两个注意点
首先我们来看一下支付中心的调用过程。业务系统、支付中心和第三方通道的交互流程图如下：
各系统交互流程为：
1.物业公司开通第三方支付渠道商户，并获取第三方支付参数
2.物业公司将第三方支付参数提供给支付中心，开通商户号，开通支付渠道，获取商户标识和支付标识。
3.物业公司将商户标识和支付标识提供给应用端。
至此，物业公司注册流程完毕。接下来是支付流程。
4.应用端使用物业公司提供的商户标识和支付标识，以及必备的支付订单号，支付金额，调起方式，上送至支付中心。
5.支付中心将获取的标识解析到对应的参数，并整合应用端的请求参数，向第三方支付发起支付，并获取支付发起的结果。
6.支付中心将发起结果整合后直接返回给应用端，注意，这里只是这个请求是否发起成功的通知，并不是最终支付结果的通知。
7.第三方支付调起用户的支付或者跳转收银台页面、小程序调起用户支付进行支付，第三方支付获取到用户的支付结果之后。回调通知支付中心。
8.支付中心处理数据，并回调通知应用端。
9.应用端处理订单信息，并开始订单、通知用户。
注意：
1.订单号问题，问题起因：有些应用系统，使用订单号上传，有些使用自己系统中的流水号上传并发起支付。所以这里设计如下：
（1）应用系统上送的无论是订单号还是流水号，支付中心都不直接使用，而是进行记录，并重新生成一个唯一的流水号，上送第三方支付。
（2）第三方支付会在校验参数成功确认支付发起成功后，再返回由第三方支付生成的流水号，用于以后的账单查询，对账，退款等功能。
（3）支付中心会保存三个流水、订单号。方便以后调用、查询。
（4）在收到第三方支付的调用返回时，支付中心会重组调用返回参数，将应用上送的订单号，支付中心生成的唯一流水号，第三方支付返回的流水号，一并返回应用端，建议应用端都进行保留。
2.这里还涉及到退款使用哪个号进行退款的问题，这里设计为：使用支付中心流水号判定使用哪一笔订单退款。上送了支付中心生成的流水号后，根据流水号和商户标识以及支付标识检索出来的结果，进行退款，退款金额不可超过该笔流水号支付的金额。应用端可以根据业务需求自行选择退款方式，支付中心只做和流水号相关的退款。
3.有关收银台，现在有些第三方支付存在自己的收银台，有的没有，所以支付中心必须有自己的收银台，但同时如果第三方支付存在已有收银台也没有必要跳转两次。所以这里的逻辑设计为：如果第三方存在必须跳转的收银台，使用第三方收银台，其余情况直接使用支付中心收银台。
三、支付中心架构设计
目前的系统功能整体架构如下：
如图所示，从架构上主要分为四个大模块：
1.支付中心后台：主要是账号管理相关，物业公司的开户开通支付等提供支持
2.支付消息：主要是用于对应用端进行通知
3.交易核心：用来支撑整个系统的基础交易核心，参数组装发起，返回数据的处理，异常的处理和通知等。
4.渠道网关：解析应用端发送过来的请求，证书白名单的设置和使用，第三方api的调用等
支付中心后台：
收银台：
渠道网关
（1）支付账户管理
物业公司选择自己所需的支付渠道进行开通
用户选择自己倾向的支付方式
最后请求中由支付中心处理，收入对应的收款账户。
（2）request解析器
一个请求在进入request解析器之后，
首先解析支付标识，决定使用哪个支付插件（alipayPlugin， wechatPlugin， easyPlugin）
其次解析调起方式（小程序，PC，APP）
获取可用的支付插件（alipaypaymentappexecutor，xxxexecutor）
最后选择方法（onpay waponpay refund）
交易核心：
交易核心的数据库设计：
分账资金流向：
四、目前预见的可能的问题
1，数据监控
出现数据异常，或者报错，及时在钉钉群里通知。
2，数据一致性问题
咱们的系统打算暂时只做一个模块，应用端可以到支付中心来同步数据。
3，稳定性问题，第三方支付不够稳定
主要是用户可能会用微信支付失败，又用支付宝支付。
这个需要应用端进行监控，支付中心对于提供的不同订单号会实时发起支付。同一订单号，连续发起两次之间间隔不超过15秒。
