原文参见知乎：代扣转协议支付改造实践

一、背景

2017年8月，中国人民银行支付结算司发布《关于将非银行支付机构网络支付业务由直连模式迁移至网联平台处理的通知》（银支付[2017]209号），规定自2018年6月30日起，支付机构受理的涉及银行账户的网络支付业务全部通过网联平台处理。

2018年3月底，网联清算有限公司发布《关于非银行支付机构网络支付清算平台渠道接入工作相关事宜的函》（网联函[2018]042号），规定各相关成员单位应积极配合完成协议支付、付款、网关支付、商业委托支付、认证支付全业务功能的生产测试。

一直以来代扣通道是互金行业业务发展的重要一环，如果代扣通道关闭，那么应对措施就是接入支付公司的协议支付模式！不管当前更多走的是银联的快捷支付产品，还是将来网联的协议支付产品，模式非常类似。

当前市场环境下改造最困难、模式最复杂的，当属网联借贷中“多资产方、多资金方”商业模式下的互金企业。本文主要阐述的也是针对该场景下，代扣转协议支付的改造建议与指南。

二、网联协议支付简介

网联清算有限公司为支持630“断直连”目标，为了能够满足目前网络支付业务需求而发布协议支付、付款、网关支付、商业委托支付、认证支付五大业务功能。 网联是基于中国人民银行关于《网络支付报文结构及要素技术规范（V1.0）》（银办发[2016]222号）为基础，建立网联相关技术标准与规范体系。 其中，协议支付对标的是现有市场业务中的“快捷支付”业务。 在630“断直连”之前，网联与银联都会优先保证存量业务的迁移。当前阶段是，大部分第三方支付公司都已完成可支持银行的数据迁移，不过目前仅有部分银行对部分第三方支付公司已完成签约数据回盘。 另外，鉴于网联平台运行之前，各支付机构与部分银行已建立起相对成熟的价格体系，为避免对支付行业秩序造成较大的冲击。因此现阶段，网联不干涉现有价格体系。

三、系统改造方案

整个代扣转协议支付的改造方案应包含两大模块：

1、存量银行卡鉴权数据的迁移：包括支付渠道数据迁移以及鉴权数据迁移回盘入库处理。（比较简单，不在本文讨论范围内）

2、新增银行卡鉴权数据的路由与备份：包括协议支付渠道路由以及快捷鉴权渠道备份。

3.1 支付渠道协议支付产品对接

此前互金行业的银行卡鉴权功能实现验证渠道一般分为两类：第三方支付公司的银行卡鉴权通道与数据服务提供商。

因此需要调整为对接支付渠道的协议支付产品或快捷支付产品以实现银行卡鉴权。目前这两类产品走的都是银联的通道，但也有以下不同点：

1、协议支付：一次鉴权，后续直接扣款。而且根据的规定，协议支付鉴权短信是发卡行负责下发。

2、标准快捷支付：笔笔鉴权。快捷支付银行卡鉴权短信可以支付公司下发，也可以发卡行下发。

3.2 协议支付渠道路由方案

协议支付产品的路由方案与原代扣模式下的路由方案应略有不同。原因在于协议支付产品需要做鉴权短信交互，即会从用户体验上对客户造成影响。而且每次最多仅能下发一次短信完成一次银行卡鉴权操作。因此需要进行业务流程调整，示意图如下：

从上述示意图可以看出，协议支付渠道路由方案应该由三部分组成：

1、第一部分：【增加鉴权入口】

由于一次鉴权最多仅能绑定一个支付渠道，即只能在该渠道内发起扣款。假如支付系统内对接了三四家支付渠道，那么系统支付路由将无法实现。特别是对于从事借贷业务的企业，系统到期日自动还款也会受影响。因此同一张银行卡可能需要在多个支付渠道完成多次快捷鉴权，达到备份的目的。

可以考虑通过在APP各环节想方设法增加鉴权入口，或者通过活动页H5、微信公众号链接、短信链接等方式增加客户鉴权交互。

互金企业可以参考通过每次借款、还款等必经交互路径增加鉴权入口。

2、第二部分【鉴权路由判断】

由于增加了多次鉴权的入口，而每次鉴权都是对客户交互体验上的干扰，因此系统需要增加相应的路由逻辑：判断该客户当前是否需要出现鉴权入口。同时鉴权入口应该更加灵活智能，当判断发现不需要展示鉴权入口时，将相应控件进行隐藏。此时用户体验最佳，同时也降低该环节的漏损率。

建议从两方面执行鉴权路由判断：

1） 以客户维度执行银行卡鉴权判断：一名客户可能绑定多张借记卡，有的借记卡已完成快捷鉴权，有的借记卡还未完成快捷鉴权；客户的自扣银行卡可能已完成快捷鉴权；客户最常用的借记卡也可能已完成快捷鉴权……场景繁多，因此需要从客户维度执行多层判断，以决定是否展示鉴权入口。逻辑示意图如下：

为了贴合业务模式，更灵活更智能的控制快捷鉴权入口展示逻辑，建议通过设置三层业务开关来实现：

其中，关键银行卡可能是自动还款银行卡，也可能是最常用的借记卡，具体可以根据业务需要调整。

2） 以银行卡维度执行银行卡鉴权判断：

通过“客户维度银行卡鉴权判断”之后，一旦判断结果为“需要快捷鉴权”，则APP或H5界面就会展示出“输入手机号码”以及“获取短信验证码”相应控件。此时，一旦展示出来让客户交互，就应想方设法让客户成功转化并顺利完成后续交易。

根据客户所绑定的银行卡数量进行差异化处理：

仅绑定一张银行卡：仅“客户维度银行卡鉴权判断”即可，若判断结果为“需要快捷鉴权”，则直接发起快捷鉴权即可。 绑定多张银行卡：则需要根据客户所选择的银行卡执行不同的鉴权。因此该场景下需要“客户维度银行卡鉴权判断” + “银行卡维度执行银行卡鉴权判断”。 逻辑示意图如下：

需要注意的是：前端APP界面已展示出来让客户交互做银行卡鉴权，就应想方设法让客户成功转化并顺利完成后续交易。因此对于“银行卡维度做鉴权判断”的逻辑中当出现“不需要快捷鉴权”时，应该由本系统直接下发短信而非通过快捷鉴权，而且后续客户提交验证码也直接由本系统进行校验。

这样优化的好处主要有两点：

对于相同的四要素在同一个支付渠道已有签约协议号，并不是所有支付渠道都支持重入或者再次绑卡。因此这种场景改成由本系统直接下发短信，可以有效避免业务流程死循环。 由本系统下发短信，有效降低外部系统依赖，减少与支付渠道的系统交互，也是保障用户体验的有效补偿。

由于支付渠道所支持扣款的银行是变动的，因此建议系统中应维护一套“支付渠道属性”能力表，用以动态核验每个支付渠道的能力。

3、第三部分：【快捷鉴权路由】

经过了前面两步快捷鉴权的路由判断，最终确定客户的银行卡需要做快捷鉴权时，将进入协议支付模式下的鉴权路由。为了满足“强运营”与更优秀的用户体验，建议鉴权路由应建立具备以下三层结构的路由模型：

A. 业务配置层（OCM）：包括各类业务参数配置管理、指定银行卡路由、交易分流切量等策略引擎参数配置

A1. 指定银行卡路由：客户在操作银行卡鉴权时可能会存在某个支付渠道的问题导致绑卡失败。因此建议设置按照指定银行卡选择支付渠道

A2. 发卡银行路由：作为业务配置规则中最重要的路由策略，为了提升策略引擎的执行效率，建议设计以发卡行维度直接指定支付渠道的优先级、流量等属性

B. 渠道限制层（CLM）：包括交易数据监控（日/月交易量统计、后台日志监控、支付渠道异常次数统计与自动切换）、渠道属性限制（根据当前交易的金额与发卡行等信息与支付渠道属性进行匹配筛选）、交易数据分析（交易异常率分析、渠道失败率分析）

C.渠道优先层（CPM）：根据支付渠道属性（优先级、可用性等）进行自动路由优先排序以及鉴权备份路由，最终路由选出综合方面最优的支付渠道，并执行后续快捷鉴权操作。

路由模型参考如下：

具体业务配置规则、限制规则等请参考：知乎： 支付路由设计与实践

四、资产方与资金方交互改造方案

在网络借贷业务中，对于单一资金方与资产方且仅有一家支付渠道的模式，改造非常简单，不在本文讨论范围内。比较复杂的类似于助贷机构，根据央行相关规定，客户扣款动作应由资金方执行，以此避免资产方由于清结算时间错配而形成非法资金池。

资产端是直接面向客户的，客户的银行卡鉴权也是在资产端完成的。在协议支付产品模式下，银行卡鉴权完成后，第三方支付机构将下发该银行卡相应的协议ID号，用于后续扣款交易使用。

那么问题来了：协议ID号在资产端系统中，资金端如何发起客户扣款？

有三类实现方案可解决该问题（具体实现模式待后续细化介绍）：

一、方案一：银行卡鉴权直接上送资金端

客户在资产端APP或H5等入口发起银行卡鉴权时，直接将交易发送到资金端，由资金端调用相应支付渠道的快捷鉴权接口，并下发短信完成鉴权。这种模式下双方系统至少需要交互两次才能完成一次快捷鉴权。

二、方案二：资产端路由后下发协议ID给资金端

银行卡鉴权仍由资产端完成，但发起还款或者代收时，将协议ID下发给资金端。此时，需要双方在支付渠道上各自的商户号进行鉴权共享，以此实现双方协议ID共用。

三、方案三：资金端提交商户号与秘钥由资产端执行扣款

这种模式比较简单。例如华澳国际信托有限公司与广东二三四五互联网小额贷款有限公司的合作模式，前者提供对应的商户号与秘钥，由后者发起代收还款时直接发起。这种模式对资金端来说工作量最小，同时解决资金结算合规问题。

综上，互金企业在调整代收功能的支付渠道策略，同时引进快捷支付渠道模式时，应注意协议支付产品的支付路由方案与代扣的支付路由方案的差异，针对从事信贷业务的“资产方与资金方交互改造方案”内容，比较复杂但很关键。后面有时间再写写这方面功能的具体实现模式。

本文档来自支付产品技术交流群的聊天记录整理，由志愿者整理并发布到本网站。如需要及时收到来自支付产品技术交流群的最新消息，请扫码关注“凤凰牌老熊”的微信公众号。 本群面向支付行业的有经验（2年以上）的产品经理、软件工程师、架构师等，提供交流平台。如想加入本群，请在本文评论中留言（不公开），说明所在的公司、负责的工作、入群分享的主题和时间。