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