充值系统业务流程分析

充值协议处理主体流程图&＃xff08;充值遵守的系统处理原则&＃xff1a;先清算&＃xff0c;后结算&＃xff09;

充值协议处理主体流程图&＃xff08;充退遵循的系统处理原则&＃xff1a;先结算&＃xff0c;后清算&＃xff09;

后结算处理的充值协议&＃xff0c;如阿里国际站的小额担保交易的使用场景&＃xff0c;其处理流程如下&＃xff1a;

充值协议系统级架构和领域模型

系统整体架构

我们从多个视角来快速浏览支付层的整体系统架构&＃xff1a;

模型总览

核心业务逻辑

用户进入统一收银台界面&＃xff0c;选择了充值渠道以及充值金额&＃xff0c;收银台经过规则检查&＃xff08;如安全、渠道等&＃xff09;后&＃xff0c;向支付层发起充值协议申请&＃xff1a;

清算层在处理完金融机构的清算结果通知后&＃xff0c;回执给支付层&＃xff1a;

充值指令的状态迁转如图所示&＃xff1a;

充退协议领域模型

模型总览

在某些特定商业背景下&＃xff08;如机票平台大客户的充退需求&＃xff09;必须大客户一次性对一笔充值指令的连续多次充退请求&＃xff0c;有如下两种实现方式&＃xff1a;

方式一&＃xff1a;需要清算层在报送银行端时进行恰当的处理&＃xff0c;如将支付层报送过来的充退清算指令进行合并&＃xff0c;或采取延迟报送银行等手段加以实现&＃xff1b;

方式二&＃xff1a;产品层加强此类合并充退的组织力度&＃xff0c;即支付层、账务/会计、清算层以及对账中心都不为此类业务进行内部业务合并&＃xff0c;而是交由产品进行合并&＃xff0c;请求支付层的充退已经是合并后的单据&＃xff1b;这样的整体代价较小&＃xff0c;并且提高了核心系统的业务处理稳定性。

支付层提供的充退协议遵循一笔充值指令最多只能有一笔处于活动状态充退指令的约束&＃xff1b;同样的原因&＃xff0c;充退协议也不再引入协议明细项&＃xff0c;直接建立协议与指令的关系&＃xff1b;

1. 每1充退协议&＃xff0c;拥有1到多个充退指令&＃xff1b;
2. 每1充退指令&＃xff0c;拥有1到多个充退操作指令&＃xff1b;

核心业务逻辑

注&＃xff1a;对于后结算充退协议&＃xff0c;指令状态直接迁转为已报送清算状态&＃xff0c;在等待清算回执后再做账务结算。

充值协议领域模型VS充退协议领域模型

与提现和退票的关系类似&＃xff0c;充退也是建立在充值基础之上的特殊协议&＃xff0c;都是完成了正向协议的反向资金处理过程&＃xff1b;

在前面讲述中将提现协议与退票协议进行合并&＃xff0c;反映在模型本身、处理流程以及数据存储等各方面都保持一致。

充值业务边界分析

系统用例边界总图&＃xff1a;

业务用例边界总图&＃xff1a;

系统用例边界

网银充值协议申请

基本流程示意图&＃xff1a;

代金卡&＃xff08;充值码&＃xff09;充值协议申请

1. 网银充值协议申请后所返回的跳转表单对象供收银台跳转至金融机构&＃xff1b;而代金卡的充值处理中收银台无需获取跳转表单对象。
2. 代金卡充值协议需要收取手续费&＃xff0c;在报送的协议申请单据中需要指定待冻结的金额&＃xff1b;支付层充值领域服务完成充值后即发起对充值账户的冻结处理。

快捷充值协议申请

接受充值清算回执

无清算充值协议申请

1. 以上介绍的各类充值协议其处理过程&＃xff0c;都遵循了支付层先记录单据&＃xff0c;待清算层完成清算后再由支付层进行结算的处理原则&＃xff0c;也就是意味着当清算层回执支付层具体的清算结果时支付层一定是有相应的单据的&＃xff1b;而由于COD业务模式的特殊性&＃xff0c;物流收到货款后即才支付机构发出通知&＃xff0c;以物流订单号作为充值订单号&＃xff0c;要求完成此次充值行为。

支付层要严格控制消息的幂等性&＃xff0c;不能为中间账户多次充值&＃xff01;

充值后通知事件

1. 所有成功完成的充值协议&＃xff0c;都需要以异步消息方式通知CTU及积分核心系统本充值事件。

支付与清算系统掉单恢复

对于实时完成支付、清算过程的充值协议&＃xff0c;需要辅以定时调度任务恢复系统响应超时的掉单充值指令。

充值协议查询

用以解释当前充值订单处理状态&＃xff0c;当清算层push相关信息至收银台后&＃xff0c;收银台使用此服务获知处理结果并显示用户。

预结算充退协议申请

后结算充退协议申请

1. 针对诸如Migs的渠道&＃xff0c;支付层提供了后结算充退协议供使用&＃xff1b;与预结算充退协议不同处在于完全依赖清算层的回执才进行账务扣款&＃xff0c;并且不存在冻结、解冻以及失败回充的动作&＃xff1b;仅在清算层明确回执清算成功后&＃xff0c;以实际清算金额&＃xff08;RMB&＃xff09;为准进行账务扣款。

异步充退推进调度

使用分布式任务组件&＃xff0c;作为异步充退推进处理的调度策略&＃xff1b;这里要完成:

1. 结算
2. 清算

异步充退超时调度

1. 处于结算成本以及客户引导的原因&＃xff0c;结算人员对客户发起某些金融机构下的充退是不给予处理的&＃xff1b;同时某些充退在申请时其通道是可用的&＃xff0c;而推进处理时则发现通道已关闭&＃xff0c;此类充退指令则一直处于待推进状态&＃xff1b;

接收充退清算回执

当清算层与金额机构清算完毕&＃xff0c;业务对账完成后&＃xff0c;清算层将清算结果回执给支付层&＃xff0c;支付层进行后续处理&＃xff1a;

1. 结算
2. 业务分流

单笔充退指令取消

允许异步充值指令的取消行为&＃xff0c;所遵循的处理原则有&＃xff1a;

1. 外部系统请求支付层取消某一笔充退指令&＃xff0c;如果是预结算的&＃xff0c;只有该支付指令处于预授权状态放可进行取消&＃xff1b;对于后结算充退指令&＃xff0c;只要该笔充退指令没有报送至清算层均可被取消&＃xff1b;
2. 预结算充退指令取消要完成账务解冻处理&＃xff1b;
3. 如果当前状态不允许进行取消&＃xff0c;则外部系统需要请求清算层进行取消&＃xff1b;复核清算层的取消规则后&＃xff0c;清算层会以清算失败的状态异步回执支付层&＃xff0c;则支付层进行失败回充。

人工充退指令推进

1. 见上述异步充退推进调度中所使用的独立门面服务&＃xff0c;完成结算以及报清算处理过程&＃xff1b;

充退汇总查询

独立的门面服务&＃xff0c;支付层内部以及外部系统均可使用此服务&＃xff1b;用以解释指定的充值指令所对应的所有充退指令集合&＃xff0c;包括每笔充退指令的金额、状态等&＃xff1b;

可充退额度统计

用以统计每笔充值指令当前可充退金额&＃xff0c;如前台会员自助充退则需要获得此统计金额进行控制&＃xff1b;

此服务接口可接受批量充值指令的可充退额度统计&＃xff1b;

充退高可用性的渠道配置

1. 目前的识别规则分三个维度&＃xff1a;产品、商户(客户)、渠道&＃xff0c;实际上充退产品在申请充退协议时从产品和商户的角度来决定。

各类规则配置管理服务

简单的介绍一下引入的各类配置规则包括&＃xff1a;

1. 支付渠道配置管理&＃xff1b;
2. 与收银台相关的过滤配置管理&＃xff1b;
3. 统一的支付能力配置管理&＃xff1b;
4. 支付能力与协议配置管理&＃xff1b;
5. 分流目标管理&＃xff1b;
6. 充值后冻结渠道配置管理

以上各类规则配置&＃xff0c;支付层均需开设相应的管理服务供管理平台使用。

业务回执分流器

本讲说的支付层重要的基础设施之一&＃xff1a;负责完成与支付业务处理无关的业务回执分流工作&＃xff1b;本讲说的回执通讯方式选型为基于ESB的异步通知方式。

业务回执分流注册

本讲有充值/充退背景的业务回执行为&＃xff0c;在组装申请单据至支付层时即设置了回执上下文&＃xff1b;而其他子系统也可以直接使用业务回执分流器完成回执&＃xff0c;可仅注册回执上下文信息&＃xff1b;

统一支付能力

设计提现、充值、充退领域服务可配置的支付能力&＃xff0c;保证后续的支付等都可以配置各类协议所使用的差异性支付能力。

领域服务监听器

这里将分流器建设成与支付协议无关的系统间共用通讯通道&＃xff0c;从而确保分流器本身的稳定性。

业务回执分流器恢复调度

即前文中所提到的分流器默认调度策略&＃xff1a;接收到监听器通知但并未执行的、或者采取同步回执通讯方式的&＃xff0c;对方应答丢失的两种场景下需要进行再次尝试&＃xff1b;当回执次数超过指定的上限后即不再尝试。

业务回执分流器恢复调度