这次给大家介绍的是支付的三个黑盒之一的“渠道和路由”（另外两个黑盒是账户账务、清结算）。
每天我们使用微信、支付宝等轻松转账消费，但背后的支付渠道选择却鲜为人知。面对众多支付方式和资金来源，如何选最优渠道成难题，仿佛是个‘黑盒’。今天，我为你揭开这个‘黑盒’的秘密。
一、支付渠道需求
1.1、降低成本
谁都希望用到手续费低、支付效率高的通道，但是大量的支付通道、开户银行、借贷记卡类型以及不同开户银行的费率标准，显然需要一个能够动态计算的路由来匹配最优的支付路径。
1.2、灵活配置
支付需求五花八门很多都需要支付渠道支持，例如有的客户只用便宜的银行，有的渠道要商户进件才能使用，有的支付产品只能做借记卡，不同的渠道维护期也经常变更。这就需要有灵活的配置管理来快速调整渠道策略。
1.3、快速发布
接了很多通道后，相同的通道是否能够减少重复开发，通过简单的配置就能快速发布上线，这样即节省了开发资源也大大提高了渠道发布的效率。
1.4、支付稳定
支付是所有商业模式的重要一环，用户下单后付不了钱，那前面所有的商业运营活动就都白忙活了，所以要有支付稳定性的保障策略；
1）应急切换：当某支付渠道异常时，系统自动切换至备用通道。
2）负载均衡：当某渠道过载时，系统提前分散压力至其他渠道，确保各渠道高效利用。
以上两种方式自然需要自动完成切换，因为谁也不愿意半夜三更爬起来切换通道。
二、支付渠道方案介绍
2.1、为什么要支付路由
交易平台和商家为提升跨行支付转化率，接入大量支付渠道，并推出聚合收银台、扫码支付、刷脸支付等产品。在高效支付与复杂渠道间，渠道与路由协作成为关键。它们精准筛选和匹配最佳支付通道，确保跨行收付款既迅速又节省成本。
2.2、支付渠道的核心流程
实现上述的支付体验，需要支付平台与支付渠道协同自动化的完成整个支付过程，这里就包含“订单数据串联、渠道服务调度、支付路由筛选、资金渠道管理、渠道接口适配、支付结果回调”等六个过程
2.2.1、订单数据串联
从整个场景来看，从用户下单到最终完成支付的链路是比较长的，因此为了保障数据全流程的连接，将支付订单分为了“交易订单”和“渠道订单”两部分。
两个订单前后串联，分工明确，记录的信息也更加清晰和完整
2.2.2、渠道服务调度
支付系统接收支付请求后，将交易订单转为渠道订单并发送给渠道服务。渠道服务会像指挥官一样根据请求调度内部模块，如绑卡、支付、退款、查询等，确保高效完成支付处理。
2.2.3、支付路由筛选
接收支付请求后首先就是要找条最优的通道来进行支付，这里就需要进行支付路由。路由一般分为自动路由和手工路由两种模式；
1）自动路由：就是根据预先配置好的规则动态的计算最优路径。这种比较适合渠道比较多的持牌机构。
2）手工路由：这种又叫静态路由，就是提前给商户分配好支付通道直接完成支付，当然切换就需要人工接入。一般企业、服务商和非持牌机构较多采用这种方式。
2.2.4、资金渠道管理
支付路由筛选的“资金渠道”早期通过简单筛选如开户行、卡类型等即可选定。但随着多银行、多机构、多级价格、渠道商户进件等复杂因素出现，资金渠道管理变得复杂难管。为解决此问题，需要在资金渠道的基础上，采用搭积木的方式来实现渠道特性的扩展和路由筛选（详细内容我们设计部分来介绍）
2.2.5、渠道接口适配
筛选到资金渠道后，需调用银行接口完成支付。此过程涉及“接口转换、文件处理、加解密和网络安全”等个性化处理。为实现标准化，需进行“标准接口定义”和“渠道个性适配”两项工作：
1）标准接口定义：
定义了不同支付产品的标准交互接口，消除渠道间的差异，使支付系统能按统一规范访问各渠道，减少因新增渠道而频繁修改重复开发。
需人工开发，针对各银行的接口和安全机制，转换为渠道可识别的标准接口和字段信息，以平衡个性化需求和人力投入的矛盾。
2.2.6、结果回调通知
支付交易需实时性，渠道处理量大时可能延迟。为保障及时准确，采用回调机制：渠道处理完交易后主动通知支付系统结果。若无回调，可开发定时查询功能并回调支付系统。支付结果展示给用户，并通过短信等通知，确保用户了解状态。此流程闭环，提供便捷高效支付体验。
回调和异步通讯：
回调是以一种异步通讯的实现手段，简单来说他就像微信聊天一样，你给对方发送消息，对方并不需要立刻回答你。等他忙完了之后再把处理结果告诉你。
2.3、支持的支付产品和特性
支付系统要支持的支付产品基本涵盖了主流“入款、出款、鉴权”的主流线上化支付方式。其中族系比较庞大的是“入款”类支付产品，其特性也是纷繁复杂。参见下图
这么多产品功能要集成到一起，如果能够快速的筛选和找到呢？这就要用到渠道路由了。
三、渠道路由方案
支付路由就是将渠道特性拆解后制定一套规则，从而实现灵活的路由。因此，讲路由之前我们先从分析渠道有哪些特征信息开始。
3.1、渠道特征拆解：
3.1.1、特性分析
从上图拆解出来的支付渠道特性种类非常多，这么多特性怎么去管理它并且做到自动路由是一个非常大的挑战。因此我们把它们拆分为了三级特性；
1）一级：基础特性
通用特性就是每条渠道必须要有的特性，并且特性也是直接可以通过标准化的路由计算方式筛选出来的。这部分稳定的特性我们可以用可视化的配置来把他们固定下来，做出基础功能。
2）二级：扩展特性
扩展特性并不是每条渠道都具备的，这是因为接入渠道、使用商户的场景差异造成的一些个性化特性。这类特性是随着业务增长而不断在增加的。这部分特性我们设计上就要保持其灵活的扩展（例如使用定制化程序，使用脚本语言来处理）。
3）三级：技术特性
这类特性是为了找到效率最高的通道，保障支付高效稳定的运行。
3.1.2、渠道名词解释
渠道特性拆解有些名词，我这里做个介绍，避免出现理解不一致。
1）支付方式：
严格的说应该叫“渠道支付方式”，是渠道对接的支付产品。通过支付方式可以把快速同类型的渠道检索出来；
2）目标机构：
是一个渠道和支付产品支持的银行分组；可能会有点奇怪直接写银行不就行了吗？这主要是为了使用和检索的时候方便；如果两条渠道支持的银行一致，那就可以直接复用过来了。
3）银行：一家银行总行的中英文简称。
4）分支银行：主要用于付款产品在需要选择开户银行时提供给用户选择，以免填错信息。
5）支付模式：参数值是B2C、B2B、C2C、C2B等；因为个人和企业输入参数的差异很大，因此该参数是为了判断使用哪条渠道的支付产品。
6）服务质量（QoS）：
是技术层面对于网关访问质量的名词，用来给用户提供最快、最高效的支付通道；
一般质量规则处理方式有“分流、熔断切换和降级”。例如某条渠道压力过大就需要做分流；如果某条渠道延迟较多就要做降级处理；如果某条渠道不工作就要进行熔断切换。
3.2、路由筛选原理
3.2.1、路由因子分类
一次支付路由是由一笔支付订单驱动的，当支付订单按照渠道标准转化为“渠道订单”后，支付渠道会从订单中解析出路由的基础因子，这些路由因子都是基础的渠道信息。
扩展因子是渠道一些复杂的特性或者是后期不断新增的渠道特性，由于需要特殊的处理因此对其二次筛选。这里包含维护期、交易限额、黑白名单等比较大的特性；也包括补充鉴权、退款限额、到账时效等小特性。
就是能够给用户提供一条最高效的支付渠道。这类路由因子一般也是通过网关策略或者定制开发的方式实现的。
3.2.2、多级渠道路由
渠道采用多级路由方式，我们这边介绍的是最典型的三级路由模式。
1）一级：筛选基础信息：
- 路由策略：对“支付方式、终端类型、卡类型、支持银行、是否可用、成本权重”等渠道固定值参数进行表层筛选。
- 路由控制：获得一级渠道信息，这些信息获得后会按照“成本优先级”做个排序。
- 实现方式：由于这部分比较基础的渠道信息筛选，实现上可以通过可视化的方式配置出来的；
2）二级：筛选扩展特性：
- 路由策略：有了一级渠道信息后，其实这时候渠道未必可以马上使用，例如渠道是否在维护期，渠道交易限额是否满足，渠道是否要商户进件才能使用，这些扩展特性还没有校验过，因此需要做进一步筛选还排序。
- 路由控制：筛选出来的结果，会重新按照“成本+特性”进行排序，到这一级筛选之后就是可以直接使用渠道了。当然如果有更加深层次的特性需要筛选还能继续扩展特性进行多次路由处理。
- 实现方式：由于这部分规则比较复杂，且数据量比较多。实现上一般通过定制开发或者编写路由脚本的方式进行处理。
- 路由策略：如果此时还有多条渠道可供选择，就需要对当前运行的渠道质量进行筛选，找一条最好快的通道完成支付。
- 路由控制：此时就会筛选这些渠道的“延迟率、链接数和异常率”等情况。最后找到一条最优的通道完成支付。
-
实现方式：这类路由因子一般也是通过网关策略或者定制开发的方式实现的。
以上一个标准的渠道三级路由，当然如果你的渠道特性非常丰富，可以扩展更多的路由因子和处理规则来实现多级扩展。
3.2.3、选中渠道执行
找到一条最终的支付渠道后，就需要获取这条渠道对应的“渠道接口”，进行渠道报文的组装后完成支付。
3.3、路由因子参数说明
上图就是对路由因子有哪些参数和参数结构进行的说明，可以看到既有枚举值，也有复杂的结构化数据。对于固定的枚举值可以通过可视化的配置方式来实现。而对于结构化的数据（例如限额、维护期、成本等）这类不适合规则配置的内容采用了定制程序或者路由脚本的方式来实现。
四、渠道设计方案
基于“渠道方案”和“路由方案”，下面我们来看下整个渠道和路由系统如何来实现。
4.1、渠道业务架构
从业务架构图我们可以看到渠道系统分成了三层的结构。
1）资金渠道管理：
这是渠道模块的核心系统，他放在了支付系统的内网，与外网隔离保证其可以安全的使用而不被攻击；其内部又分为了“渠道服务、路由管理、资金渠道、定时任务、基础服务”五个重要的渠道核心功能。
这部分是渠道外部的适配器，用来对接各家银行的支付渠道，他分为了“渠道接口、渠道适配”，新增一条支付渠道就要在这里进行配置和开发。
通过资金渠道网关，屏蔽不同渠道的差异，给上层渠道服务提供统一的访问处理。这类部分模块是安放在网络隔离区，通过防火墙完成内外部网络的访问。
这里就是需要通过对接和访问的银行、三方、清算机构的支付通道了。
4.1.1、资金渠道管理
这是渠道对外提供的标准服务，上层支付平台要按照标准接口来访问渠道，同时渠道服务也是下游流程的调度者。这里的渠道服务支持“鉴权、预路由、入款、收款”等支付核心功能。
渠道路由会接收支付服务的请求，将支付请求的“订单信息”解析成“路由因子”，按照对应的规则模版进行多级路由，最终选中一条资金渠道进行调用。
这里存放着接入的每条渠道的所有配置信息，渠道相关的重要信息都存放再此。路由结果也是通过调用这里的渠道接口完成最终的支付。
这是资金渠道的一个辅助功能，对于需要定时进行的支付结果查询，对账文件、批量任务等进行处理。
这里是资金渠道业务层面的一个附属功能，包含基础参数、卡Bin、签约信息、结果码、安全证书、缓存等管理。
4.1.2、资金渠道网关
资金渠道网关既是对外访问的模块，新接入渠道二次开发模块也是部署在这里。
1）渠道接口：定义标准的渠道访问接口，他屏蔽了不同渠道差异性，让上层的渠道管理可以用统一的方式来管理渠道。
2）渠道适配：就是对不同银行的渠道进行接口转换、安全加密处理、网络处理等各种渠道差异性进行二次开发。因此新增一条通道，只要在这里做渠道的接入开发就可以了。
4.2、渠道用例模型
下面我们看下这些功能是如何协同起来工作完成“渠道管理、支付路由、渠道调用”等支付处理。
4.2.1、渠道服务：
渠道服务提供统一的服务接口，并根据业务类型细分为七大类功能，每类功能均可扩展。在入款功能中，按支付方式细分为快捷、网银、条码三类。这些服务既支持单笔和批量接口处理，也支持文件接口处理。
对于复杂的快捷支付，渠道服务提供签约记录和卡Bin管理两个附属应用，用于在快捷签约时进行银行卡验证和补充鉴权操作。
渠道服务的核心职责是将“支付订单”转化为“渠道订单”，实现内部数据流转。这涉及将标准化信息传递给下游的路由和渠道模块，以便进行解析和完成支付处理。通过这种机制，渠道服务确保了支付流程的高效、安全和顺畅。
4.2.2、渠道路由：
1）路由访问：
- 动态访问：一种是提供路由因子由路由系统动态路由一条支付渠道完成支付。
- 直接访问：对于像快捷支付需要访问签约通道的支付产品，可以直接传送签约的“资金渠道编号”访问对应的签约渠道。如果由多条签约渠道则按照“成本和Qos”找到一条最便宜、最快的通道完成支付。
渠道路由通常利用规则引擎进行处理，这种处理方式允许我们提前编写好规则脚本。当输入相关数据后，规则计算引擎会根据这些脚本进行计算，并输出一个结果。
这个结果可以是一个简单的数值，比如一个特定的资金渠道编号，也可以是一个更复杂的数据对象，包含多个资金渠道编号以及对应的渠道接口信息。
这种机制使得渠道路由处理非常灵活，计算结果可直接调用支付渠道或作为二级路由输入，持续筛选直至选定合适渠道。未选中则报错。
4.2.3、渠道管理：
渠道管理包含接入渠道的所有信息，其最核心的就是“资金渠道”的管理，它拥有我们一级路由所需要的主要基础信息，而一些像“维护期、交易限额、扩展因子”等信息则根据业务的增长和需要进行灵活的扩展。
由此我们也可以知道为什么要做三级路由了，因为一级路由我们筛选的就是渠道表层的基础信息，二级路由是筛选渠道的扩展的信息，三级路由是筛选动态的渠道交易信息。
4.2.4、渠道网关：
经过渠道路由选择资金渠道后，接下来需要调用该渠道的接口。渠道接口调用分为标准化的“渠道接口”和需要个性化开发的“接口适配”两部分。对于新增的渠道，通过接口适配实现与系统的对接，确保顺畅的支付流程。
这种机制既保证了接口的标准化和通用性，又兼顾了不同渠道的个性化需求，提升了支付系统的灵活性和可扩展性。
渠道网关还有个回调服务，前面已经介绍过来，我们这里就不再赘述了。
4.3、渠道数据模型
渠道的数据模型几乎是和用例模型直接映射的，因此下面我们就从处理流程的角度来说下数据之间的关系。
4.3.1、渠道管理：
4.3.3.1、渠道配置：
1）创建资金渠道：
新接入的支付渠道需要配置相应的“资金渠道”，这包括渠道的基础特性信息，确保渠道能正确识别和处理支付请求。
资金渠道创建后，需要与目标机构进行关联。目标机构代表了一组特定的开户银行信息，与支付产品相对应，确保支付流程中的银行信息准确无误。
在基础信息和目标机构关联完成后，还需为渠道关联包括“支付限额、维护期、结算信息、黑白名单”等在内的扩展信息，以满足不同支付场景和运营需求。
4.3.3.2、渠道接口配置：
完成上述渠道配置后，需要为渠道配置相应的接口。这些接口用于与支付渠道进行交互，包括请求发送、结果接收等，确保信息的准确传输和处理。
4.3.3.3、渠道路由配置：
只有渠道配置还不能立即使用，还要把渠道对应的路由规则按照模版配置出来，然后把这些路由规则发布。这样这条渠道就可以使用了。
当然，这里的规则模版是为了方便配置按照不同的支付方式提供的标准化模版，这些模版既可以是一个脚本也可以是一套可视化的配置界面，这样发布渠道就比较灵活。
4.3.2、联机交易：
渠道配置发布后，联机交易就可以调用渠道了。
1）请求处理：首先上层支付系统会按照接口标准向渠道服务传送“渠道支付订单”信息。
2）渠道路由：支付路由系统把渠道订单数据解析成“路由因子”，然后按照路由规则筛选渠道。
3）调用渠道：当选中一条渠道后，就调用对应的资金渠道和接口，通过渠道适配器完成接口转换完整一笔联机交易的处理。
4.3.3、运营管理：
渠道配置完成后，商户侧运营还需要配置商户产品和行业信息（MCC），包括微信、支付宝等支付产品，还需配置渠道行业及进件信息。
五、资金渠道交互设计
前面讲了设计，那整个支付渠道到底长什么样子的呢？下面我们就来介绍下渠道的交互部分设计。由于支付产品的类型非常多，我们以相对复杂的快捷支付为例来介绍整体交互流程。
5.1、整体交互流程
整个渠道交互都是围绕着“资金渠道管理”来展开的，他整个处理流程与用例图、ER模型基本是一致的。
以资金渠道为核心页面，完成基础信息配置后，对扩展的关联信息进行配置，最后完成接口配置。
2）支付路由管理：
支付路由管理通过一套可视化的配置模版的界面，可以轻松的配置各类路由规则。这些路由配置界面可以按照业务类型的不同分为不同的模版，例如“快捷路由配置”、“扫码路由配置”、“付款路由配置”等。
5.2、渠道功能清单
针对渠道比较丰富的持牌机构，需要支持的主要功能有如下。
1）基础参数：提前需要配置好存放在系统内的基础信息。
2）资金渠道：渠道管理和路由所需要的功能。
3）渠道运营：提供给商户侧运营使用与渠道相关的功能。
5.3、新增资金渠道
新接入支付渠道需要对应配置一条资金渠道信息，配置资金渠道还需要同步去关联“目标机构、维护期、渠道限额、黑白名单、渠道接口”等渠道扩展信息。
5.3.1、填写资金渠道信息
创建资金渠道同时需要填写渠道的基础信息和常用的渠道特性和结算信息，这些基础信息可以包含最常用的渠道路由信息。
5.3.2、新建目标机构：
创建资金通道后还要创建对应的目标机构，把当前渠道支持的开户银行关联到渠道上。这样在支付路由的时候就能获取当前渠道支持的银行。
5.3.3、资金渠道接口
资金渠道与目标机构创建后，需配置对应渠道接口，以便路由选中时完成跨行支付。接口采用标准化模板，并提供参数配置以适应不同渠道。复杂渠道可通过个性化开发的“接口适配”服务处理支付。标准化接口减少了定制工作量，加快了渠道发布速度。
完成资金渠道和目标机构的创建后一条最基本的资金渠道就配置完成了，但是这些信息还不能满足快捷支付产品复杂的特性需求，因此还要做扩展渠道特性的配置。
5.3.4、渠道限额
快捷产品的限额比较复杂，不同银行按照卡类型设置了不同的单笔、日限额和支付成本，因此这部分需要单独来进行配置和管理。
5.3.5、渠道维护期
每条渠道对应的渠道和开户银行也非常多，因此不同渠道、不同银行经常会有维护期需要进行设置（主要是快捷、网银、付款类产品），这部分信息由于更新频繁需要经常维护，因此也需要单独管理。
5.3.6、商户黑白名单
黑白名单属于扩展特性，只有渠道需要对指定商户进行准入或者限制时才需要配置。
1）白名单：
即只有名单内的商户才能使用；现在支付渠道开始要求商户进行渠道进件，例如条码支付、商户侧全渠道、商业委托扣款、新代收等产品。所以需要再渠道上设置对应的白名单，只有白名单的商户才使用这些渠道。
2）黑名单：
即名单内的商户不能使用渠道或者部分特性。黑名单使用的原因有很多，最常见的就是渠道价格调整后，有些商户手续费和渠道成本倒挂了，因此需要限制这些商户使用指定银行的银行卡产品。如果商户支持银行和卡选择ALL，这说明这个商户这条渠道不允许使用。
5.4、设置渠道路由
5.4.1、渠道路由管理
一套路由规则通过基础参数、扩展参数可以关联多个渠道，每条路由规则也要支持，创建、修改等一系列的管理功能。
路由规则不建议做物理删除，因为直接删除会影响渠道的稳定切换。可以通过新增一条规则设置新老规则的衔接时间来实现稳定的切换。
为了表现规则和渠道的两级结构关系，交互中采用了树形查询列表，当然条件不具备的小伙伴可以使用普通列表查询也可以，就是交互体验上要考虑怎么展示规则和渠道的关系，以及规则如何修改和编辑。
5.4.2、路由规则设置
路由规则的创建是由“基础信息、规则组、路由规则、执行渠道”嵌套实现的，没错又是烧脑的“嵌套”。因为这样可以把同类型的渠道分别进行设置。
需要说明的是并不是所有规则都能可视化配置的。路由规则配置主要处理的是一级路由中固定取值的“基础因子”的配置，动态计算的扩展因子和质量因子的处理需要定制化开发。
当然也可以提供脚本编写功能给配置人员使用，不过这需要有编程经验才行。
是整个路由规则的基础信息，包含这条规则什么时候生效和创建内部嵌套的规则组。
为什么要对路由规则分组呢？目的是把同类支付产品，按照不同特性区分出来。例如同样是快捷支付产品，有的产品只要绑卡签约就能使用，有的产品需要商户渠道进件才能使用，有的产品小金额支付可以优惠。
这么多特性显然需要不同的路由规则来描述，因此需要设置不同的分组。
- 基础因子：这类规则都有固定的枚举值，因此基础规则可以用可视化的方式来设置对应的条件，多条规则通过后置逻辑关系来实现链接。
- 扩展因子：“维护期、渠道限额、渠道质量”等扩展特性并非固定取值，需根据实际订单与渠道配置信息动态计算。因此，需开发定制化程序以处理，无需在单条渠道上分别设定路由规则。
-
临时新增：如果有些临时新增的规则可以通过编写嵌入脚本来快速实现。
最后要把规则对应执行渠道配置上去，这样规则才能正常工作。需要说明的是同一套规则会有一条或者多条渠道被选中，因此需要支持多条渠道和接口的设置。
可能你会问，多条渠道该用那条呢，其实路由配置就是一级路由的处理，最终命中渠道还有技术层面内部处理来决定的。
5.4.3、路由的多组规则
一条路由规则可以设置多组子路由规则，如下图所示，通用的快捷支付规则包含了“协议支付、无卡支付、银联商户侧、云闪付免密”等所有的快捷类支付方式，可以通过分组的方式来实现。
例如图中的规则组1，他是为协议支付、无卡支付这样的通用性支付渠道进行设置的规则。银联商户侧由于需要渠道侧进件才能使用因此要单独设置一个规则组。云闪付免密支付由于1000元以下有优惠，因此也为其提供了一个规则组。
六、支付渠道总结
本文介绍的支付渠道设计还是比较复杂和庞大的，这种模式比较实用持牌机构，非持牌机构可以按照这套模式做适当的裁剪。
本文主要基于快捷支付产品场景来介绍的，条码支付、网银支付、付款产品也都是适用的，本文咸鱼篇幅不再展开介绍了，同学可以自行按照这套模式来进行扩展。
1）渠道的需求：降低成本、灵活配置、快速发布、支付稳定四方面。
2）支付渠道组成：
支付渠道是一个独立的模块，包含了渠道服务、渠道路由、渠道任务和渠道网关四部分。
3）支付路由原理
支付路由是将渠道特性拆分成路由因子，通过规则化的模版来实现动态路由。
4）渠道三级路由：
渠道路由最经典的模式就是三级路由，一级路由筛选渠道基础信息，二级路由筛选渠道扩展信息，三级路由筛选渠道质量因子。每一集路由按照成本、特性权重、质量权重进行排序，最终选中一条渠道。
5）资金渠道管理：
是一个星型结构，核心存放渠道基础信息的“资金渠道”，围绕资金渠道的是“目标机构、结算信息、维护期、渠道限额、商户名单”等扩展信息。这样的结构可以实现渠道特性的扩展。
6）支付路由管理：
是一个链式结构，每个阶段采用了“输入，计算，输出”的处理步骤，通过前提配置好的路由规则根据输入的数据计算一个结果。结果可以作为下一个接点的输入，循环多次，最终选中通道。
7）路由规则交互
路由规则的配置有可视化、脚本、内部程序三部分来实现。对于固定值信息可以采用可视化配置，如果需要动态计算或者临时新增的规则，可以用编辑脚本的方式实现路由。
本篇文章来源于微信公众号: 刚哥白话
