付款协议 深度解析：什么是支付核心？

本文主要从八个方面阐述了什么是支付核心，包括哪些内容？

支付核心:

一、支付和清算的核心责任

首先要明确一个概念:在一个完整的支付清算体系结构内，各种具体业务所涵盖的支付服务和清算服务是相互独立的。

其独立性体现在具体的产品开发过程和后期维护工作中:

这种现状导致了业务产品开发复杂化、风险性提高；支付与清算的相关规则各自为政，彼此独立，加大管理难度；在开放平台的大背景下，也不能提供给大量外部业务系统所需要的基础支付服务；若清算服务部署于在后台管理系统，各类清算细则繁冗复杂，对运营部门造成很大不便性。

设计支付清算系统时，建议:

支付核心和清算核心设计为两层，分为两个独立的子系统。

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

支付层提供各种打包支付服务，包括清算服务、会计服务、客户相关服务等。，实现基本支付服务的安排。

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

前提:将同步/异步维度的提现支付协议进行划分，得到两类提现支付协议的处理流程。

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

该服务接口可以接受批量充值指令的可充可退额度统计。

充电和退出高可用性通道配置:

对于业务部门要处置的收费退费申请，比如在某些渠道发起收费退费申请时，线下文件方式无法退款，业务部门可以选择柜台提交方式重新办理；支付层的要求是识别这些高可用性收费和退款应用，并在提交清算指令时指明该参数项。

目前，识别规则分为产品、商家(客户)和渠道三个维度。实际上，在申请收费和退费协议时，收费和退费产品是从产品和商家的角度来确定的。比如强制充退产品发起的充退应用，或者BD签约商户发起的充退应用，都是高可用性的充退应用。

然而，频道识别规则的充值指令必须具有高可用性。我们不希望产品受到渠道识别规则的管辖，所以识别规则需要产品层和支付层的合作。

如果产品应用的收费协议中已经指定了高可用性，则无需再次检查；产品应用的收费协议中没有规定高可用性，支付层的内置渠道规则生效。

各种规则配置管理服务:

简要介绍所介绍的各种配置规则，包括:

支付渠道配置管理；与收银台相关的过滤配置管理；统一的支付能力配置管理；支付能力与协议配置管理；分流目标管理；充值后冻结渠道配置管理。

对于上述规则的配置，支付层需要提供相应的管理服务，供管理平台使用。

业务收据拆分器:

本次讲座中提到的支付层的重要基础设施之一是负责完成与支付业务处理无关的业务回单分流，作为支付层与其他产品系统之间的通信支持。

分流需要解决以下问题:

(1)目标

收款的对象，也就是付款结果需要通知给谁，我们通过预定义的配送目标配置数据，记录各种产品的收付款层的收款服务地址、通讯方式、通讯质量作为初始收款对象。推出新产品，辅以管理平台的功能菜单，可以灵活配置收货的目标数据。

(2)语境

在请求支付层的支付协议时，比如充值协议，交易系统需要得到支付层的响应，比如充值是否成功，充值金额等。

上下文可以通过两种方式注册:一种是包含在协议申请单中，另一种是在没有任何充值后台的情况下使用该组件进行业务回单，比如线下网点。

支付层接收产品的上下文由两部分组成:请求者注册信息和支付层自己的处理结果信息。

例如:url①+(收款单号②[金额、状态、付款渠道...】③)+(收件人证件号码④[买方、卖方、交易金额、商品名称] ⑤)

其中:

可以在注册请求中指定该url，也可以由支付层通过配置获取，以请求中指定优先；必选，代表着希望告诉对方系统处理结果的唯一单据号；可选，解释该单据号的关联要素信息；必选，代表中接收者唯一可识别的业务单据号；可选，解释该单据号的关联要素信息。

(3)战略

每个收据上下文的处理状态可分为:

未通知：尚未回执至产品层；已通知：已回执产品层，但未得到应答；成功：已回执产品层，得到应答，并且后续处理成功如充退申请成功，终结状态；失败：已达到最大尝试次数，不再进行再次尝试的终结状态。

转移者和业务逻辑互不侵犯，只是作为沟通工具。原则上，转移人不会自行发起业务收据，并且需要第三方通知转移人执行收据。但是，分流器本身具有一定的处理权限，例如通知的任务实例。

拆分器只会再次尝试这种情况下的接收行为，直到达到指定的最大接收时间，并且拆分器只关心系统之间的通信状态。

本讲提到的回执通信方式选择基于ESB的异步通知方式。

商业收据转移登记:

本讲有充值/退款后台的业务回单行为，回单上下文是在申请单组装到支付层时设置的。其他子系统也可以直接使用业务回单拆分器完成回单，只注册回单上下文信息。

统一支付能力:

为提现、充值、取款等领域的服务设计可配置的支付能力，确保各种协议使用的差别支付能力可以为后续支付进行配置。

域服务侦听器:

本文将分流器建成与支付协议无关的系统间共享通信通道，以保证分流器本身的稳定性；另一方面，各种支付协议的核心域服务，如充值协议，需要构建得更加稳固和稳定。现在，需要另一个角色来连接这两者，即域服务侦听器，它决定是否通知分流器进行接收。

如上所示，通过监控域服务的处理结果，我们可以识别是否有必要发起产品的接收，从而将核心域服务层与拆分器隔离开来。

这里会设置一些识别规则，比如预定义的网银充值B2B支付渠道。对于交易产品，关注B2B支付的预授权和清算完成状态。其实这不是交易产品的约束，而是内在的渠道本身。

充值协议申请单指定收款目标和收款上下文时，根据配置的规则，识别出指令状态过渡到预授权或清算成功/失败时，需要通知分流器进行分流，此时完成分流任务的登记。

充值域服务收到清算层的回单，如清算成功，域服务完成账户充值等业务逻辑，并通知该监听器，包括当前充值指令的状态和金额。因此，域服务不再关心侦听器和拆分器的实际处理过程，因此侦听器应该识别当前指令状态是否需要回执产品，如果满足条件，则通知拆分器进行回执。

业务收据拆分器恢复计划:

也就是说，上面提到的分割器的默认调度策略:如果收到监听者通知但未执行，或者采用同步接收通信方式，则对方响应丢失，需要重新尝试，当接收次数超过指定上限时，不会再尝试。

业务收据拆分器恢复计划:

如图，支付层会管理所有的支付渠道，包括与金融机构互动的清算渠道和未清算的渠道，如余额，所以支付渠道的范围大于等于清算渠道的范围。

清算层负责管理各类清算通道的可用性维护，理论上支付渠道中所包含的清算通道部分没有必要一定要与清算层的保持一致，如：状态、API的命名等。但某个清算通道的关闭/开启，我们希望能够直接反映至前台，基于用户体验而考虑，在清算通道发生关闭/开启事件后，需要以异步消息通知至支付层。支付层负责同步更新该通道的可用状态，以此反映至收银台的可供选择渠道列表。不考虑对清算层新开通的清算通道数据做同步，此处需要人工介入。

本文最初由@ Payment College发布，大家都是产品经理。未经允许，禁止复制

标题图来自Unsplash，基于CC0协议