在支付业务中，渠道路由是连接银行、第三方支付机构等持牌机构的关键环节，其复杂性和重要性常常令人望而却步。本文将用通俗易懂的语言，结合清晰的图表，给大家详细解读了支付渠道和渠道路由的原理与设计。

支付业务说到底是个渠道业务，他是支付系统的接出端，对于一家支付公司来说，只有接入有市场竞争力的支付渠道，支付产品才能被更多的客户使用。

对于每个刚入支付行业的同学来说，很多都是从接渠道和配置路由开始的。

今天，我们就来介绍支付渠道和被传的神乎其神的渠道路由。

引子：神秘的渠道路由

支付渠道是支付平台链接银行、三方等持牌机构的系统。其中最神秘的就是渠道路由，由于它是持牌机构内部的系统，因此接触者寥寥，并且其内部结构错综复杂，加之“智能化”的宣传使其更加神秘。

其实只要记住“三级路由”基本原理，把流程和模型做个上图这样的二维展开，任何人都能拿捏渠道对接和路由。

01、支付渠道原理

支付路由就是将渠道的路由因子组合形成一组规则，将用户的支付请求准确的传送到支付渠道上完成支付。因此，讲路由之前我们先要了解路由因子和三级路由。

所谓的三级路由，就是把路由拆解成三个阶段，各阶段分工合作，最终命中一条可用的支付渠道。

1.1、路由因子

图1：渠道结构和路由因子

路由因子和渠道的结构密不可分，因此在了解路由因子前，我们先要分析下支付渠道的结构。

1.1.1、渠道结构

渠道的结构分为“资金渠道”和“渠道网关”

1）资金渠道：每条资金渠道代表着一条可使用的外部支付产品。在资金渠道中设置了“基础信息”和“渠道特性”参数，这些参数控制着渠道的路由和参数转换。

2）渠道网关：负责与外部支付产品的接口适配和参数转换，以此来屏蔽内外部接口的差异，以便支付引擎能够按统一的流程和参数来调用。

1.1.2、路由因子

1）基础因子：对应着渠道的基本信息，通过对支付订单的拆解可以初步匹配到符合要求的渠道。因此基础因子大都是支付订单中包含的信息。

2）特性因子：对应每条渠道特殊的属性，例如维护期、交易限额、渠道成本等需要后台单独配置的规则来处理，这些因子需要按请求参数进行逻辑计算。

3）质量因子：对应的是渠道网关，发起支付时要选可靠渠道，因此需要动态监控渠道的成功率、延迟率和连接数等参数，以确保支付请求被快速处理，减少订单积压。

1.2、三级路由

图2：三级路由

分析完路由因子后，我们来看下三级路由是如何流转的。

1）一级路由：筛选渠道

解析支付订单根据基础因子筛选出符合条件的支付渠道，把结果存入一级列表。

2）二级路由：匹配特性

一级列表中的渠道不能直接支付，因为如果渠道处于维护期或限额较低等特殊情况，支付请求会失败。需要根据每条渠道的特性匹配合适的渠道，再将结果存入二级列表。

3）三级路由：检查网关

二级列表的渠道具备了直接支付的条件，但是为了减少异常订单的堆积，还需要对渠道网关运行情况进行筛选，找到质量最好的那条通道完成支付。

经过以上三级的筛选，就找到了一条又快又省钱的渠道，选中这条渠道完成支付即可。

02、支付渠道设计

了解了以上这些原理之后，我们再来看支付渠道的设计就很好理解了。

2.1、渠道业务架构

图3：渠道业务架构

从业务架构图我们可以看到渠道系统分成了三层的结构。

1）资金渠道管理

这是渠道模块的核心系统，他放在了支付系统的内网，与外网隔离保证其可以安全地使用而不被攻击；其内部又分为了“渠道服务、路由管理、资金渠道、定时任务、基础服务”五个重要的渠道核心功能。

2）资金渠道网关

这部分是渠道外部的适配器，用来对接各家银行的支付渠道，他分为了“渠道接口、渠道适配”，新增一条支付渠道就要在这里进行配置和开发。

通过资金渠道网关，屏蔽不同渠道的差异，给上层渠道服务提供统一的访问处理。这部分模块是安放在网络隔离区，通过防火墙完成内外部网络的访问。

3）外部合作渠道

这里就是需要通过对接和访问的银行、第三方、清算机构的支付通道了。

2.1.1. 资金渠道管理

图4：资金渠道管理

1）渠道服务

这是渠道对外提供的标准服务，上层支付平台要按照标准接口来访问渠道，同时渠道服务也是下游流程的调度者。这里的渠道服务支持“鉴权、预路由、入款、收款”等支付核心功能。

2）路由管理

渠道路由会接收支付服务的请求，将支付请求的“订单信息”解析成“路由因子”，按照对应的规则模板进行多级路由，最终选中一条资金渠道进行调用。

3）资金渠道

这里存放着接入的每条渠道的所有配置信息，渠道相关的重要信息都存放在此。路由结果也是通过调用这里的渠道接口完成最终的支付。

4）定时任务

这是资金渠道的一个辅助功能，对于需要定时进行的支付结果查询，对账文件、批量任务等进行处理。

5）基础服务

这里是资金渠道业务层面的一个附属功能，包含基础参数、卡Bin、签约信息、结果码、安全证书、缓存等管理。

2.1.2. 资金渠道网关

图5：资金渠道网关

资金渠道网关既是对外访问的模块，新接入渠道二次开发模块也是部署在这里。

1）渠道接口：定义标准的渠道访问接口，它屏蔽了不同渠道差异性，让上层的渠道管理可以用统一的方式来管理渠道。

2）渠道适配：就是对不同银行的渠道进行接口转换、安全加密处理、网络处理等各种渠道差异性进行二次开发。因此新增一条通道，只要在这里做渠道的接入开发就可以了。

3）回调网关：用来处理银行的支付结果的回调请求。

2.2、渠道集成关系

图6：渠道集成关系

2.2.1、渠道服务

渠道服务提供统一的服务接口，并根据业务类型细分为七大类标准功能，这些功能可以组合成快捷、扫码、网银、钱包等各种支付产品的标准接口。

通过定义标准化的服务接口，可以有效地抽象和屏蔽各渠道间的差异性。这样一来，支付引擎就能够以统一的方式进行调用，而无需关注每个具体渠道的特性与差异。

2.2.2、渠道路由

渠道路由就是对支付请求进行解析，然后进行路由的筛选和计算。这里就包含了路由访问、订单解析、路由计算三个步骤。

1、路由访问：

支付请求有动态路由和直接访问两种方式。

1）动态访问：顾名思义让渠道根据请求去自动的计算，找到一条最快最便宜的渠道完成支付。

2）直接访问：有些支付产品是与渠道绑定的，例如快捷支付的协议号只能在签约的通道上有用，因此可以直接传送签约时对于的“渠道编号”直接访问，而无需路由。

2、订单解析

对支付订单进行解析，从订单中抽取出路由因子进行逐级的筛选。

3、路由执行：

图7 ：路由规则工作原理

渠道路由通常利用规则引擎进行处理，这种处理方式允许我们提前编写好规则脚本。当输入相关数据后，规则计算引擎会根据这些脚本进行计算，并输出一个结果。

这个结果可以是一个简单的数值，比如一个特定的资金渠道编号，也可以是一个更复杂的数据对象，包含多个资金渠道编号以及对应的渠道接口信息。

这种机制使得渠道路由处理非常灵活，计算结果可直接调用支付渠道或作为二级路由输入，持续筛选直至选定合适渠道。未选中则报错。

2.2.3、渠道管理

渠道管理包含接入渠道的所有信息，其最核心的就是“资金渠道”的管理，它拥有一级路由所需要的主要基础信息，而一些像“维护期、交易限额、扩展因子”等信息则根据业务的增长和需要进行灵活的扩展。

2.2.4、渠道网关

渠道网关负责不同的渠道接口适配，并且完成向外部渠道发送支付请求，最终将结果以回调的方式返回给上层支付系统。因此实际渠道对接主要是在渠道网关进行二次开发，以实现不同渠道的适配和安全加解密处理

同时渠道网关也兼具渠道质量监控的功能，可以异常渠道进行降级、限流和熔断，以减少异常订单的堆积。

2.3、渠道流程串联

图8：三级路由的流程串联

分析完渠道设计后，下面我们就把流程、参数和模型进行串联，以此来了解其上下游的对应关系。

①解析支付订单：

解析出支付订单中的路由因子，准备路由。

②判断路由模式：

需要判断动态路由还是直接路由，如果是动态路由就通过路由因子进行筛选渠道。如果是直接路由，则取出渠道号存入二级路由的结果列表，直接进行第三级路由。

③一级渠道匹配：

根据基础因子筛选出共同特性符合条件的支付渠道，把结果存入一级列表。

④二级特性匹配：

前面已经介绍，一级列表中的渠道还不能直接支付。因此需要对一级列表中支付渠道的特性进行逐条遍历和计算，找到完全符合条件的支付渠道后才能存入二级列表。进入二级列表的渠道基本满足了支付的条件。

⑤三级网关检查：

为了减少超时等情况造成的订单堆积，还要对支付网关服务质量因子（QoS）进行一次检查，路由到成功率最高，速度最快的渠道上去。

⑥组装接口完成支付

以上路由都成功后根据选中的渠道组装接口，进行数据转换后就能完成支付了。

03、支付渠道交互

前面讲了基本原理和设计，那整个支付渠道到底长什么样子的呢？下面我们就来介绍下渠道的交互部分设计。由于支付产品的类型非常多，我们以相对复杂的快捷支付为例来介绍整体交互流程。

3.1、整体交互流程

图 8：渠道交互整体流程

整个渠道交互都是围绕着“资金渠道管理”来展开的，因此他整个交互界面就是模型的可视化展现。

1）资金渠道管理：

以资金渠道为核心页面，完成基础信息配置后，对扩展的关联信息进行配置，最后完成接口配置。

2）支付路由管理：

支付路由管理通过一套可视化的配置模板的界面，可以轻松地配置各类路由规则。这些路由配置界面可以按照业务类型的不同分为不同的模板，例如“快捷路由配置”“扫码路由配置”“付款路由配置”等。

3.2、渠道功能清单

针对渠道比较丰富的持牌机构，需要支持的主要功能有如下。

1）基础参数：提前需要配置好存放在系统内的基础信息。

2）资金渠道：渠道管理和路由所需要的功能。

3）渠道运营：提供给商户侧运营使用与渠道相关的功能。

图9：渠道功能清单

3.3 新增资金渠道

新接入支付渠道需要对应配置一条资金渠道信息，配置资金渠道还需要同步去关联“目标机构、维护期、渠道限额、黑白名单、渠道接口”等渠道扩展信息。

图10：资金渠道管理

3.3.1、新增资金渠道

创建资金渠道同时需要填写渠道的基础信息和常用的渠道特性和结算信息，这些基础信息可以包含最常用的渠道路由信息。

图11：资金渠道基础信息

3.3.2、新建目标机构

创建资金通道后还要创建对应的目标机构，把当前渠道支持的开户银行关联到渠道上。这样在支付路由的时候就能获取当前渠道支持的银行。

图12：创建目标机构

3.3.3、资金渠道接口

资金渠道与目标机构创建后，需配置对应渠道接口，以便路由选中时完成跨行支付。接口采用标准化模板，并提供参数配置以适应不同渠道。复杂渠道可通过个性化开发的“接口适配”服务处理支付。标准化接口减少了定制工作量，加快了渠道发布速度。

图13：渠道接口维护

完成资金渠道和目标机构的创建后一条最基本的资金渠道就配置完成了，但是这些信息还不能满足快捷支付产品复杂的特性需求，因此还要做扩展渠道特性的配置。

3.3.4、渠道限额

快捷产品的限额比较复杂，不同银行按照卡类型设置了不同的单笔、日限额和支付成本，因此这部分需要单独来进行配置和管理。

图14：渠道限额和成本

3.3.5、渠道维护期

每条渠道对应的渠道和开户银行也非常多，因此不同渠道、不同银行经常会有维护期需要进行设置（主要是快捷、网银、付款类产品），这部分信息由于更新频繁需要经常维护，因此也需要单独管理。

图15：渠道维护期设置

3.3.6、商户黑白名单

黑白名单属于扩展特性，只有渠道需要对指定商户进行准入或者限制时才需要配置。

3.3.2.1、 白名单商户

即只有名单内的商户才能使用；现在支付渠道开始要求商户进行渠道进件，例如条码支付、商户侧全渠道、商业委托扣款、新代收等产品。所以需要在渠道上设置对应的白名单，只有白名单的商户才能使用这些渠道。

3.3.2.2、黑名单商户

即名单内的商户不能使用渠道或者部分特性。黑名单使用的原因有很多，最常见的就是渠道价格调整后，有些商户手续费和渠道成本倒挂了，因此需要限制这些商户使用指定银行的银行卡产品。如果商户支持银行和卡选择ALL，这说明这个商户这条渠道不允许使用。

图16：渠道黑白名单维护

3.4 设置渠道路由

3.4.1 渠道路由管理

一套路由规则通过基础参数、扩展参数可以关联多个渠道，每条路由规则也要支持，创建、修改等一系列的管理功能。路由规则不建议做物理删除，因为直接删除会影响渠道的稳定切换。可以通过新增一条规则设置新老规则的衔接时间来实现稳定的切换。

图17：渠道路由管理

为了表现规则和渠道的两级结构关系，交互中采用了树形查询列表，当然条件不具备的小伙伴可以使用普通列表查询也可以，就是交互体验上要考虑怎么展示规则和渠道的关系，以及规则如何修改和编辑。

3.4.2、路由规则设置

路由规则的创建是由“基础信息、规则组、路由规则、执行渠道”嵌套实现的，没错又是烧脑的“嵌套”。因为这样可以把同类型的渠道分别进行设置。

需要说明的是并不是所有规则都能可视化配置的。路由规则配置主要处理的是一级路由中固定取值的“基础因子”的配置，动态计算的特性因子和质量因子的处理需要定制化开发。

当然也可以提供脚本编写功能给配置人员使用，不过这需要有编程经验才行。

图18：快捷路由规则设置

1）基础信息：是整个路由规则的基础信息，包含这条规则什么时候生效和创建内部嵌套的规则组。

2）路由分组：为什么要对路由规则分组呢？目的是把同类支付产品，按照不同特性区分出来。例如同样是快捷支付产品，有的产品只要绑卡签约就能使用，有的产品需要商户渠道进件才能使用，有的产品小金额支付可以优惠。这么多特性显然需要不同的路由规则来描述，因此需要设置不同的分组。

3）路由规则：基础因子：这类规则都有固定的枚举值，因此基础规则可以用可视化的方式来设置对应的条件，多条规则通过后置逻辑关系来实现链接。特性因子：“维护期、渠道限额、渠道质量”等扩展特性并非固定取值，需根据实际订单与渠道配置信息动态计算。因此，需开发定制化程序以处理，无需在单条渠道上分别设定路由规则。临时新增：如果有些临时新增的规则可以通过编写嵌入脚本来快速实现。

4）执行渠道：

最后要把规则对应执行渠道配置上去，这样规则才能正常工作。需要说明的是同一套规则会有一条或者多条渠道被选中，因此需要支持多条渠道和接口的设置。

可能你会问，那多条渠道该用哪条呢，其实路由配置就是一级路由的处理，最终命中渠道还有技术层面内部处理来决定的。

3.5、路由的多组规则

一条路由规则可以设置多组子路由规则，如下图所示，通用的快捷支付规则包含了“协议支付、无卡支付、银联商户侧、云闪付免密”等所有的快捷类支付方式，可以通过分组的方式来实现。

图19：快捷支付的多组规则例

如图中的规则组1，他是为协议支付、无卡支付这样的通用性支付渠道进行设置的规则。银联商户侧由于需要渠道侧进件才能使用因此要单独设置一个规则组。云闪付免密支付由于1000元以下有优惠，因此也为其提供了一个规则组。讲在最后

最后，渠道路由由于需要提前在各条渠道上开启开通备付金或者商户账户，因此这种模式比较适合于持牌机构，如果普通商户也要做支付路由，除非是传统企业，否则都是有二清问题。

我给人面试的时候，偶尔也会听到候选人说四方、商家做渠道路由，这种情况经常会被我问的脸红脖子粗的，反正大家没做渠道路由可以仔细看下我这篇文章后再去面试吧。