从零打造聚合支付系统 系列文章链接如下

从零打造聚合支付系统：一、浅谈聚合支付的核心价值
从零打造聚合支付系统：二、建立领域模型
从零打造聚合支付系统：三、应用微服务架构

上一篇分析了聚合支付为什么能做，本篇开始讲讲聚合支付系统怎么入手。

前言

在针对特定业务进行分析设计时，首要的事情便是建立业务模型（又称领域模型）。

领域模型，通常是业务人员与软件工程师沟通的桥梁。

为了避免陷入专业名词的泥沼中，我并不打算运用严格的领域模型语言来描述聚合支付系统的分析设计。尽管如此，但建模的思路的做法依然重要。

关于领域建模的重要性及基本原则，Eric Evans大神在《领域驱动设计——软件核心复杂性应对之道》一书中有详细阐述，有兴趣的小伙伴可以阅读的第一部分。

系统功能

上一篇中介绍过，聚合支付是为商户提供支付“一站式”的服务。

聚合支付系统位于商户与支付机构或银行之间，收敛商户与支付机构及银行间的一切交互。

一个聚合支付系统，首先要具备支付、查询、退款三个基本功能，对应用户使用支付的三种基本操作；其次，为了确保各方交易记录一致，通常要以天为单位对账，实现业务闭环；最后，根据对账结果，定期完成资金结算。

模块划分

建立一个最小的聚合支付系统，至少应具备以下三个模块（或子系统）：

• 核心支付模块：完成支付、查询、退款三个基本功能，此三个功能属于实时调用，需要立即返回结果。每次调用传递的信息包含一个订单。
• 对账结算模块：对账是每天定时执行，需要将前一天的交易批量下载或上传，并进行比对；清分结算则是汇总对账结果，并将结果提交给会计系统或银行。
• 商户管理模块：商户需要在聚合支付系统注册，需要申请接入，需要查询交易，需要下载配置信息等必要功能。因此，需要此模块实现与商户间的交互，传递一些必要的信息，这是三个模块中唯一一个需要用户界面的模块。

核心支付模型

接口信息

由上面图可以看出，支付和退款是由商户主动发起的。商户调用接口时，实际上发送的是订单信息（涉及支付的信息），聚合支付系统为其生成相应的支付信息和退款信息。

• 订单信息：商户ID，订单号，商品名称，商品描述，订单金额，支付方式，回调地址；
• 支付信息：支付流水号，支付金额，支付结果，结算日期；

• 退款信息：退款流水号，退款金额，退款结果，结算日期；

  
  
  

退款信息中包含退款金额，是由于实际支付中存在部分退款的需求（比如购买两件东西有一件退款）

支付流程

上一篇中介绍过，聚合支付首要解决是支付的“碎片化”的市场痛点。

为了吸引更多的商户接入，努力让商户接入变得更简单。做一个产品历来有Less Is More的设计原则。所以在设计支付流程时，应尽可能让流程看起来简单易懂。

比如Ping++主页上标语的，“七行代码接入聚合支付”。 这看起来非常有吸引力。

通过仔细研究，市面上常用的支付手段，其背后的流程，只有两种。

• 第一种我称之为授权支付：用户首先需要通过商户后台到支付机构申请支付授权，然后使用授权码（通常是一个类似于Token的串）调起支付功能，最后在输入密码完成支付。这种支付方式流程如下，常见的APP支付、PC网页支付、手机扫码支付等支付方式都适用此流程。

需要先授权再支付，主要是因为商品订购的界面（由商户提供）与支付操作界面（由支付机构提供）不属于同个界面，或者不在同个APP中，甚至不在同一台设备上。

• 另一种我称之为直接支付：用户将带有自己身份信息的一个信息串，通过商户发送到支付机构，商户在发送过程中加上订单和支付信息，直接完成支付。常见的线下购物刷卡支付，扫码枪扫条码支付都适用此流程。

与需要授权的原因相反，无需授权操作，是因为不需要在不同界面上来回跳转。线下购物通常是如此。

查询与退款流程

查询与退款由于完全是后台请求，因此流程相对来说则简单些。

通常来说退款并不能立即确定成功或失败，因此大部分机构都是采用异步通知的方式告知退款结果。

对账结算模型

对账模式

对账模块会每天定时将前一天的多方交易记录下载，并进行比对，以确保各方记录一致。

聚合支付系统对账有两种模式，一种是由商户主动上传记录的，另一种是商户不上传交易记录。其差别如下。

结算账户模型

根据监管部门要求，聚合支付通常要避免“二清”问题。即不允许聚合支付机构在没有相应资质的前提下，先代商户收钱，再将分给各个商户。

资金结算要交给有相应资质的机构来完成，一般会委托给银行来完成。

为了保证在银行系统中各个账户中的结算金额可靠，遇到不一致时可追溯错误，因此，需要在对账结算模块内建立一套虚拟账户体系，与银行系统中的账户一一对应（做同步）。

关于如何建阙金融账户体系，可以参考此篇文章《金融结算系统的基础业务之账户体系结构分析》

由于聚合支付系统并不是真的要建立一套完整的账户体系，其目的只是与外部系统的账户保持同步而己，因此，可将账户体系精简如下。

图中有如下要点：

• 由于可能存在分润，一笔交易可能按规则记入多个账户，因此，交易记录（相当于凭证）与账户明细（收支）是一对多的关系。
• 余额由于有期初与期末的概念，如果每期做一条记录，则一个账户根据时间不同可能有多条余额记录，因此账户与余额也是一对多的关系。

总结

至此，搭建一个最小聚合支付系统的领域模型已经基本完成，以上的知识己经足够一个从未涉足支付领域的开发人员进行设计和开发了。

领域建模的精髓在于，模型本身是发展的，随着对业务理解的深入和业务需求的变化， 模型也会随之进行变更，逐渐变的完善。

与此同时，还要注意输出模型要可落地。例如，以上的分析夹杂了一些面向对向分析的手法，因此不适合采非面向对象的语言来实现。

在后面的文章中，我会详细地描述如何应用微服务架构将系统一步步实现，以及讨论为什么要使用微服务架构。请看下文。