支付核心和清算核心职责

首先要明确一个概念：一个完整的支付清算系统结构内，各种特定业务所涵盖的支付服务、清算服务是相互独立的。其独立性体现在具体的产品研发过程以及后期维护等各项工作中：

1、 这种现状导致了业务产品开发复杂化、风险性提高；

2、 支付与清算的相关规则各自为政，彼此独立，加大管理难度；

3、 在开放平台的大背景下，也不能提供给大量外部业务系统所需要的基础支付服务；

4、 若清算服务部署于在后台管理系统，各类清算细则繁冗复杂，对运营部门造成很大不便性。

在设计支付清算系统时建议：

1>、 将支付核心和清算核心设计为两层，分为两个独立子系统：

2、 支付核心提供适应各类产品使用的基础支付服务；清算核心则将所有机构所能提供的底层清算服务归集，专门负责与银行的各类清算接口对接；

3、 支付层则对外提供各类经过包装的支付服务，涵盖清算服务、账务服务、客户相关服务等，实现对基础支付服务的编排。

提现协议系统业务流程分析

前提：以同步/异步的维度划分提现支付协议，得出两类提现支付协议的处理流程。

维度：会员层、提现产品层、支付层、财务核心、清算层、银行。

1、 同步提现支付协议处理流程图

2、 异步提现支付协议处理流程图

3、 退票支付协议的处理流程

如图，将支付与交易分开，主要是为了体现出支付服务机构的核心支付服务功能。

核心支付服务能够为会员提供丰富个性的支付服务：充值、提现、内外转型支付、支付侧营销等内容。

若将交易产品中包装的相关支付服务交由支付服务层与清算服务层协作完成，并将交易以及其他产品释放出来，则产生的整体系统框架图如下：

提现支付协议领域模型

模型总览

通过对提现支付协议、提现支付指令的归纳抽取，得到本模型图。其中，操作指令部分不对外暴露。

每 1 提现支付协议，拥有 1 到多个明细项；提支付协议本身和明细项信息是产品在使用支付协议时各专用申请单据转化而来，由原始业务单据数据经过简单加工后得出；

每 1 提现支付协议，拥有 1 到多个提现支付指令；支付指令是在协议和协议明细项基础之上加工得出；其具备了进行后续操作处理的全部要素信息，除原始单据中请求要素外，经过支付层的一系列诸如补全、拆分、检查之后产生；部分没有业务数据的提现产品如正常提现和卡通提现，都是以支付指令作为其产品数据；

每 1 提现支付指令，拥有 1 到多个提现操作指令；提现操作指令是真正可被系统处理的、运行时得出的具体操作步骤；具体表现为账务相关、清算相关以及其他底层公共服务的处理单元；

为了简化提现支付指令与提现支付协议的从属关系，可以直接认为每 1 提现支付协议拥有 1 到多个提现支付指令。

核心业务逻辑

以在线用户发起的正常提现申请为例，整体的交互时序图如下：

支付层内部处理的交互时序图

提现支付指令作为提现支付协议的流水数据，其处理生命周期的状态迁转如图所示：

异步提现支付协议下的提现支付指令状态图

提现退票支付协议下的提现支付指令状态图

同步提现支付协议下的提现支付指令状态图