各位同学大家好,我是学院教导主任,今天的课程是「全面解读与认知支付系统」的第二个大板块「支付核心」中第一部分。由于「支付核心」这部分内容比较多,所以分成三节课来详细解读。希望大家认真学习,有所收获。

三节课学懂支付核心(上) | 支付学院-烽言

那么,课程开始了,请认真听讲。

支付核心
三节课学懂支付核心(上) | 支付学院-烽言
支付核心和清算核心职责

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

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

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

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

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

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

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

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

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

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

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

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

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

三节课学懂支付核心(上) | 支付学院-烽言

会员提交提现申请后,进入提现产品层申请同步提现支付协议,然后进入支付层请求扣款提现金额:此时进入财务核心执行扣款,同时报送清算请求指令进入清算层,报送银行处理;然后进入银行执行扣款并返回清算结果,此时做一个判断,若清算成功则回执处理结果,并回到提现产品层进行业务处理并通知用户提现处理结束;若清算失败则进入财务核心,进行回充。

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

三节课学懂支付核心(上) | 支付学院-烽言

会员层提交 T 日申请提现需求后,进入提现产品层申请异步提现协议,然后进入支付层:首先请求冻结提现金额,并进入财务核心进行冻结;在 T + N 日请求扣款冻结金额,并进入财务核心层进行扣款,同时报送清算请求指令,进入清算层进行清算指令的记录并生成清算报文(文件),再进入银行层执行清算。在 T + N 日,运营平台层执行回导清算结果/文件,进入清算层勾兑清算指令并回执处理结果,进入支付层进行判断:若清算成功则回执处理结果,并回到提现产品层进行业务处理并通知用户提现处理结果;若清算失败则回到清算层进行回充。

退票支付协议的处理流程

三节课学懂支付核心(上) | 支付学院-烽言

这部分内容比较容易理解,这里就不做详解了。

三节课学懂支付核心(上) | 支付学院-烽言

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

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

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

三节课学懂支付核心(上) | 支付学院-烽言
提现支付协议领域模型

模型总览

三节课学懂支付核心(上) | 支付学院-烽言

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

就提现支付协议本身,分为同步/异步两种处理方式:前者将提现支付协议的申请过程、处理过程打包处理;后者则是分阶段处理。

提现支付指令里包含了收款方-银行卡、付款方-支付账户的各自支付工具,依据此可拆分出相应的账务类操作指令与清算类操作指令。

作为提现支付协议的一种,退票支付协议也将退票单的申请与处理过程打包。

三节课学懂支付核心(上) | 支付学院-烽言
  • 每 1 提现支付协议,拥有 1 到多个明细项;提支付协议本身和明细项信息是产品在使用支付协议时各专用申请单据转化而来,由原始业务单据数据经过简单加工后得出;
  • 每 1 提现支付协议,拥有 1 到多个提现支付指令;支付指令是在协议和协议明细项基础之上加工得出;其具备了进行后续操作处理的全部要素信息,除原始单据中请求要素外,经过支付层的一系列诸如补全、拆分、检查之后产生;部分没有业务数据的提现产品如正常提现和卡通提现,都是以支付指令作为其产品数据;
  • 每 1 提现支付指令,拥有 1 到多个提现操作指令;提现操作指令是真正可被系统处理的、运行时得出的具体操作步骤;具体表现为账务相关、清算相关以及其他底层公共服务的处理单元;
  • 为了简化提现支付指令与提现支付协议的从属关系,可以直接认为每 1 提现支付协议拥有1到多个提现支付指令。
核心业务逻辑

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

三节课学懂支付核心(上) | 支付学院-烽言

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

三节课学懂支付核心(上) | 支付学院-烽言

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

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

三节课学懂支付核心(上) | 支付学院-烽言
提现退票支付协议下的提现支付指令状态图

三节课学懂支付核心(上) | 支付学院-烽言
同步提现支付协议下的提现支付指令状态图

三节课学懂支付核心(上) | 支付学院-烽言