三节课学懂支付核心(中)| 支付学院

三节课学懂支付核心(中)| 支付学院-烽言-心有所执,方有所成

提现业务边界分析

首先,提现业务边界分析可以拆分为两大部分:业务用例边界以及系统用例边界。这里着重讲一下系统用例边界,分为:

  • 异步提现支付协议申请
  • 异步提现支付协议推进处理
  • 接受清算处理结果回执
  • 统一协议处理结果回执
  • 同步提现支付协议申请
  • 同步提现支付协议推进/恢复处理
  • 提现退票支付协议
  • 打款机构
  • 支付能力
  • 分布式任务
  • 公共查询类服务:协议授权查询服务、机构信息查询服务
  • 提现查询类服务:银行卡段检查服务、对公账户联行号检查服务、支行列表查询服务、清算通道支付限额查询服务
  • 管理服务:协议授权管理服务、打款机构管理服务、支付能力管理服务、缓存刷新服务

1业务用例边界

支付层作为提供基础支付服务的核心系统,所承担的职责围绕着以下主要业务功能点:

以协议方式提供适用于各类产品使用的支付服务:

三节课学懂支付核心(中)| 支付学院-烽言-心有所执,方有所成

三节课学懂支付核心(中)| 支付学院-烽言-心有所执,方有所成

三节课学懂支付核心(中)| 支付学院-烽言-心有所执,方有所成

可供灵活编辑的各种核心处理规则配置机制,以及提供配套的规则管理服务:

三节课学懂支付核心(中)| 支付学院-烽言-心有所执,方有所成

2系统用例边界

三节课学懂支付核心(中)| 支付学院-烽言-心有所执,方有所成

 异步提现支付协议申请

本文重点描述异步提现支付协议在申请过程中支付层的体系结构以及处理流程。

需要重点指出的是,支付层所提供的协议申请使用嵌套分布式事物,在此将申请过程分为两个阶段处理:

阶段一:

1.      调用者开启分布式事务,在事务块内请求异步提现支付协议申请:

2.      整合现有各类非实时处理类提现产品要素,设计专用的申请单据对象;异步提现支付协议支持每次申请单笔或批量明细项;

3.      通过内部的业务接入层将专用单据转换成统一的内部领域模型对象;

4.      对领域模型对象加工,包括补全、拆分、检查等;

5.      启动嵌套分布式任务,执行预授权处理,即冻结提现款;

6.      组装处理结果并返回。

阶段二:

调用者根据支付层协议申请的返回结果,决定提交或回滚分布式事务:

三节课学懂支付核心(中)| 支付学院-烽言-心有所执,方有所成

异步提现支付协议推进处理

支付层自行调度的推进处理

  • 加载协议数据,激活领域模型对象;
  • 执行结算处理,包括账务解冻与扣款;
  • 执行报清算处理,通过确保达到的ESB消息通知清算层执行清算。

产品层通知方式的推进处理

  • 加载协议数据,激活领域模型对象;
  • 记录协议的相关审核人以及类似于生僻字审核所需要的银行开户名等信息;
  • 执行结算处理,包括账务解冻与扣款;
  • 执行报清算处理,通过确保达到的ESB消息通知清算层执行清算。

三节课学懂支付核心(中)| 支付学院-烽言-心有所执,方有所成

异步提现支付协议取消/接受清算处理结果回执

异步提现支付协议取消

  • 这里提到的协议取消不是对整个协议的取消,支付层只允许对单笔支付指令的取消行为;

接受清算处理结果回执

  • 在经历了上述两个处理过程后,清算层根据自有的业务规则进行清算处理;最终的清算结果需要确保通知到支付层;此处继续选用高可靠性的ESB确保到达。

三节课学懂支付核心(中)| 支付学院-烽言-心有所执,方有所成

统一协议处理结果回执/同步提现支付协议申请

统一协议处理结果回执

  • 除了上述的支付指令处理成功/失败已经提现取消作为处理结束状态,需要回执给产品层外,对于退票情况,也需要回执给产品层;
  • 产品层目前也是通过前置来统一处理的,所以支付层在回执产品层提现处理结果时需要一并报送该笔支付指令的产品码、子协议代码以及备注信息、操作员等;
  • 这里回执给产品层的处理结果,也是采用高可靠性的ESB确保到达。

同步提现支付协议申请

对于需要同步支付并清算的提现产品,使用本协议;同异步提现支付协议,本协议也可以使用嵌套分布式事务;

三节课学懂支付核心(中)| 支付学院-烽言-心有所执,方有所成

同步提现支付协议推进/恢复处理

  • 支付层同步请求清算,清算层的返回结果中有三种清算状态:

三节课学懂支付核心(中)| 支付学院-烽言-心有所执,方有所成

如果支付层在请求同步清算时出现了严重异常,如清算层异常宕机或清算返回丢失,则仍然返回产品处理中结果;支付层内部回复程序会继续尝试回复。

三节课学懂支付核心(中)| 支付学院-烽言-心有所执,方有所成

提现退票支付协议

提现退票支付协议作为本讲引入的协议之一,通过申请支付层的协议,由支付层负责账务与业务推进处理;在本协议下,退票流水将作为支付指令存在,与被退票的支付指令平级;不会去对已经处理成功的原支付流水做任何改动;

由于不需要进行清算,支付层内部只需要处理账务充值部分即可;所以本协议也是同步的,即申请成功则全部处理完毕。

三节课学懂支付核心(中)| 支付学院-烽言-心有所执,方有所成

打款机构/支付能力/分布式任务

打款机构

任何一笔提现申请,最终目的都是从某一支付账户提现至指定的银行卡上;这个银行卡就是提现支付协议中指定的收款方信息;

由于银行卡信息中的开户行种类繁多,比如各类非直接打款银行;对于这些开户行的提现申请,实际会通过跨行的方式进行提现;具体说来就是根据开户行、提现的额度范围、账户的对公对私属性等,来决定最优的提现方式;

产品层不知道本次提现的实际打款机构;而支付层对每笔支付指令进行账务处理时需要知道具体的打款机构,这样才能请求账务进行扣款或者回充处理;所以打款机构的规则就需要支付层进行维护。

分布式任务

支付层的大量调度任务如异步提现支付协议的推进、同步提现支付协议的掉单恢复等;将来会有更多的调度任务加入;

支付能力

作为支付协议最重要的处理规则,支付层对外提供可供快速定制的各种内部处理打包方案;

其他服务类

公共查询类服务

a)      协议授权查询服务

b)     机构信息查询服务

提现查询类服务

a)      银行卡段检查服务

b)     对公账户联行号检查服务

c)      清算通道支付限额查询服务

d)     提现统计查询服务

管理服务

a)      协议授权管理服务

b)     打款机构管理服务

c)      支付能力管理服务

d)     缓存刷新服务

本地缓存

a)      机构信息查询结果;

b)     清算通道支付限额查询结果;

c)      支行列表查询结果;

除此之外,支付层自有的配置规则也可以考虑使用缓存的模式,减少数据库读取频率:

a)      协议授权关系列表;打款机构规则列表;

b)     支付能力列表;

喜欢()
热门搜索
297 文章
16 评论
50 喜欢
Top