支付中心架构将各业务的公共交易、支付、财务等沉淀到支付中心,并主要解决了以下三个主要问题:
建立基础订单、支付、财务统一体系,抽象和封装公共处理逻辑,形成统一的基础服务,降低业务的接入成本 及重复研发成本;
构建安全、稳定、可扩展的系统,为业务的快速发展和创新需求提供基础支撑,解决业务「快」和支付「稳」之间的矛盾;
沉淀核心交易数据,同时为应用端、物业公司、用户提供数据支撑。
订单号问题,问题起因:有些应用系统,使用订单号上传,有些使用自己系统中的流水号上传并发起支付。所以这里设计如下:
(1)应用系统上送的无论是订单号还是流水号,支付中心都不直接使用,而是进行记录,并重新生成一个唯一的流水号,上送第三方支付。
(2)第三方支付会在校验参数成功确认支付发起成功后,再返回由第三方支付生成的流水号,用于以后的账单查询,对账,退款等功能。
(3)支付中心会保存三个流水、订单号。方便以后调用、查询。
(4)在收到第三方支付的调用返回时,支付中心会重组调用返回参数,将应用上送的订单号,支付中心生成的唯一流水号,第三方支付返回的流水号,一并返回应用端,建议应用端都进行保留。
这里还涉及到退款使用哪个号进行退款的问题,这里设计为:使用支付中心流水号判定使用哪一笔订单退款。上送了支付中心生成的流水号后,根据流水号和商户标识以及支付标识检索出来的结果,进行退款,退款金额不可超过该笔流水号支付的金额。应用端可以根据业务需求自行选择退款方式,支付中心只做和流水号相关的退款。
有关收银台,现在有些第三方支付存在自己的收银台,有的没有,所以支付中心必须有自己的收银台,但同时如果第三方支付存在已有收银台也没有必要跳转两次。所以这里的逻辑设计为:如果第三方存在必须跳转的收银台,使用第三方收银台,其余情况直接使用支付中心收银台。
注意:
售前咨询专员
