很多东西玩不明白，主要是没从错综复杂的信息和逻辑中抽象出来

越复杂的事物，往往蕴含着最简约的本质。接了很多条通道以后，做了各厂的、各式各样的通道管理系统以后，我发现，通道管理没那么难，只需要一个通用范式：

“强大的通道信息、牛逼的路由处理、严丝合缝的错误码映射”

1.通道管理场景

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

那么啥是支付渠道，也可以叫支付通道，是指能够提供资金流转功能的通道，包括但不限于银行、第三方支付机构。

我们常见的借记卡（储蓄卡）、贷记卡（信用卡）、微信、支付宝、云闪付等支付方式，都是通过对应的支付通道完成支付的。

1.1.就1条通道

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

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

1.2.很多条通道

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

相比于场景一，支持了更多的支付方式，这意味着需要接入更多的支付通道。后续也有可能会支持更多的支付方式，也就有可能需要接入新的支付通道。

这个时候我们就需要思考了，比如下面的几个问题：通道很多，如何对它们进行统一的维护呢？当同一个支付方式有多个通道的时候，如何进行通道选择（即支付通道路由）？后面如果新增通道，如何能灵活的进行添加呢？

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

02.支付流程分析 

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

买家通过平台A购买商品：下单并支付完成；卖家收到订单，进行发货；买家收到包裹后，确认收货；平台A进行资金结算（按平台的结算规则），结算到卖家平台账户；卖家可以在平台A进行提现，提到卖家自己的银行卡。

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

2.1.补单流程

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

2.2.退款流程

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

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

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

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

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

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

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

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

2.3.提现流程

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

3.总体架构设计   

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

4.支付渠道信息管理

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

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

5.支付渠道路由   

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

6.统一结果码映射与管理  

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

7.退款超期处理