支付渠道，也可以叫支付通道，是指能够提供资金流转功能的通道，包括但不限于银行、第三方支付机构。我们常见的借记卡（储蓄卡）、贷记卡（信用卡）、微信、支付宝、云闪付等支付方式，都是通过对应的支付通道完成支付的。

支付渠道管理，通俗理解就是对支付渠道的管理， 为什么需要对支付渠道进行管理呢？下面通过场景说明其必要性。

场景一

电商公司A，在初期，为了使产品快速的成型上线，支付是辅助功能，支付收银台设计的是一个简单的收银台，只有【支付宝】，那我们该如何实现呢？

支付收银台只有一个支付方式——支付宝，是固定的，对应支付通道也是一个固定的，支付的时候直接请求支付宝就可以，调用流程简化如下

场景二

还是这个公司A，产品上线之后，业务发展的不错，产品也不断的迭代，单一的支付方式无法满足业务发展，收银台会发展到这样

相比于场景一，支持了更多的支付方式，这意味着需要接入更多的支付通道。后续也有可能会支持更多的支付方式，也就有可能需要接入新的支付通道。这个时候我们就需要思考了，比如下面的几个问题：

通道很多，如何对它们进行统一的维护呢？

当同一个支付方式有多个通道的时候，如何进行通道选择（即支付通道路由）？

后面如果新增通道，如何能灵活的进行添加呢？

这些可以总结为：需要对支付渠道进行管理。那支付渠道管理是管理什么？以及怎样进行支付渠道管理的设计呢？下面就以电商平台为例，进行支付渠道管理的设计。

01 场景分析

电商平台（以下简称平台A）的交易业务流程（担保交易）可以描述为以下几步。

1. 买家通过平台A购买商品：下单并支付完成；

2. 卖家收到订单，进行发货；

3. 买家收到包裹后，确认收货；

4. 平台A进行资金结算（按平台的结算规则），结算到卖家平台账户；

5. 卖家可以在平台A进行提现，提到卖家自己的银行卡。

在这个过程中，也可能发生退款，可以分为2类——售前退款和售后退款：

a）售前退款：买家下单支付成功之后，确认收货之前的退款。

b）售后退款：买家确认收货之后的退款。

两者主要的差异是退款的钱由谁来出，售前退款因为资金还没有结算给商家，所以资金是从平台A退给买家；售后退款就需要从商家的账户退给买家。

我们对上述流程进行简化，重点突出与支付渠道相关的部分，如下图所示。我们拆分成3个流程进行支付渠道需求分析：

1.1 支付流程

对平台A来说，首当其冲的是要保证用户能支付成功；其次才是其他的，比如通道的成本、用户体验等。分析渠道管理的功能：

（1）渠道的基本信息管理维护

渠道支持哪些支付方式。收银台展示的支付方式都可以走哪些渠道。

渠道的状态维护。例如某一个渠道现在有问题，那后续的交易是不能继续发到这个渠道的，需要维护成下线或者不可用。有的渠道有日常维护，比如每天的凌晨0点-1点不可用，需要增加渠道的维护时间配置。

（2）渠道路由

根据用户支付方式，选择一个最优的支付渠道。影响路由可能的因素，比如：通道费率、买家是否已经在某个通道支付过、渠道是否支持、渠道当前是否可用、支付环境（比如微信环境有h5、小程序、sdk，设计的时候可能会定义成不通的通道），以及也有可能会有一些业务上的限制，比如跨境交易只能走固定的几个通道。

（3）补单流程

正常情况下，渠道侧支付成功后，都会主动发送回调通知，告诉平台这笔订单的状态，但是如果出现了意外，渠道的通知服务异常了，单纯依靠渠道的回调就有问题了，用户银行卡已经扣钱了，但是平台的订单还是待支付，所以为了避免这种情况的发生，就需要有补单任务，主动去渠道查询订单状态。

（4）错误代码映射

提升用户体验。一般如果支付失败，渠道都会返回对应的错误代码以及错误原因，但是有些渠道，特别是银行卡支付的时候，因为失败的原因有很多种，且渠道直接返回的原因，如果直接展示给用户的话，用户不一定能理解，所以需要做一层转换，转换成用户容易理解的文案。

1.2 退款流程

退款都是原路退，即支付的时走的银联，退款的时候也走银联渠道退款。但是也有情况例外，比如：

超过通道的原路退款时间：每个通道不尽相同，有的是一年、两年或者更久，也有个的只有6个月，比如微信支付宝。超过期限就不能原路退了。

原路退异常：比如微信账号注销、卡注销等等。

所以退款这里，还需要考虑下无法原路退的情况，应该如何处理。

1.3 提现流程

这块涉及的功能和支付流程类似。需要额外考虑的是如果所有的提现渠道都有问题的时候，提现流程如何进行处理。

02.支付渠道管理设计

2.1 支付渠道管理总体架构设计

根据上一部分的业务场景分析，支付渠道管理系统的架构设计如下：

2.2 支付渠道路由

（1）路由要素分析

路由要素有很多，下图列了一下常见的要素。

渠道与支付方式的映射关系：是某个支付方式可以走哪个渠道的关键配置。

通道限额：除了微信或者支付宝支付的，银行卡支付通道都是有单笔支付限额，以及日限额。

渠道状态：渠道当前是否可以用。

渠道权重：比如建设银行-借记，提交筛选完之后，还有2个渠道可以用，这个时候就需要通过配置的权重，选择有限走哪个渠道。

白名单：渠道上配置白名单，白名单类型可以是卡号、买家用户ID、卖家用户ID，如果配置了白名单，在满足渠道条件之后，会优先走这个通道。

产品码：做业务区分。根据前面场景分析，某些渠道只能走特定的业务。

支付环境：同一种支付方式在不同的环境路由到不同的渠道。比如微信支付，可能的支付环境有：微信小程序环境、微信h5环境、SDK环境、浏览器环境，环境不一样，实际发送渠道请求的参数也不一样，所以需要进行区分。

渠道费率：每个渠道都会收手续费，会有一个费率配置。在实际路由配置的时候，费率选择问题可以和权重进行合并，运营人员直接根据产品策略，配置渠道权重，以达到目的。

维护时间：通道会有维护时间，即某段时间不能接受交易请求。银行类的交易，维护比较常见。

（2）路由逻辑

核心逻辑是——选择一个最优的可以使用的通道。其选择过程如图所示：

条件过滤：根据请求参数，选出所有符合条件的渠道集合。实现起来比较简单，配置好条件，筛选的时候逐个进行比较，如果符合就继续下一个条件，如果不符合就中止，进行一个下一个渠道筛选。

渠道选择：从可用的渠道集合中选择一个最优的渠道。一般会进行一个打分制，需要配置分数规则，比如配置的费率规则：

把所有的分数进行加和，就是这个渠道的分数，最后返回一个分数最高的渠道。比较特殊的，如果命中了白名单，则可以直接返回这个渠道。

（3）退款渠道路由

退款渠道的路由很简单，就是退款的时候获取到原单渠道，那么这个渠道就是退款渠道。

2.3 统一结果码映射

这里不仅有支付失败的错误文案映射，也还有订单状态的映射，因为渠道的返回报文有对应的返回码，这个在对接时候，渠道方会告知哪些返回码是成功的。这块的处理流程如下：

2.4 补单逻辑

不管是支付、退款还是提现，补单流程是统一的，如下图所示（图十一）：

不同的是，支付/退款/提现的查询，需要请求不同的接口，需要跟进订单类型进行适配。

2.5 退款超期处理

这里说的超期包含2种情况：

一是这笔退款订单的处理超过了一定的时间还没成功，我们就认为可能是有问题。这个时间是多少呢？不同渠道还不一样，微信或者支付宝的退款一般是很快的，银行卡的退款可能会慢一点，最长可能会到几天才会成功，所以这个时间配置在渠道配置里；

二是这个笔订单像上面说的几种情况，没办法原路退款了。

这2种情况我们都是需要发现并解决的，毕竟最终是需要把钱退给买家的，所以我们需要把这部分订单找出来，然后进行处理就好。整个处理流程可以设计如下：

这块核心就是需要把这个订单发送到【线下处理系统】（一个能承载这部分订单且能串通这个流程的系统即可）。对于处理方式，常见的有：

联系买家，进行线下打款，打一笔资金到买家的银行账户或其他的收款账户。

如果是渠道系统问题，可以再把退款单进行原单重新发送（前提是渠道支持重复发送）。

03 支付渠道管理后台

3.1 支付银行管理

这里的支付银行和收银台侧支付方式对应，是用于后面配置支付渠道路由。

3.2 支付渠道管理

支付渠道管理维护了支付通道的基本信息。描述为：哪个机构（外部机构的简称）、什么业务（入款、出款等）、什么支付类型（借记、贷记渠道）的通道，并为其定义一个在该支付平台的唯一通道编码。其中：

• 修改：对渠道基本信息进行修改；
• 配置接口参数：对这个渠道的接口请求参数进行配置；
• 银行配置：配置这个渠道能支持哪些支付银行。

3.3 渠道路由

渠道路由维护了支付银行和支付渠道的一些条件，如果需要修改。

3.4 白名单管理

白名单管理是为某个用户或者是卡号添加渠道白名单，在白名单列表里，渠道路由的时候有优先走这个渠道。

原文出自：人人都是产品经理