在支付中， 你是否了解通道是什么？通道系统设计该如何设计？本文对此进行解析，对相关设计流程进行了梳理，希望对你有所帮助。
通道是什么？这个在我们进入支付行业开始，就自然而然进入我们视线的词，到底意味着什么？
那么我们可以先回顾以下支付的定义：发生在收款人和付款人之间的货币债权转移的过程。
而通道，就是在支付过程中进行货币债权（钱）转移的服务提供方。
举个例子：我们买个早餐，用支付宝刷了我们的招行信用卡，老板的工行卡收到钱，老板使用的收款工具是收钱吧，收钱吧使用的结算通道是银联。这个支付过程中的支付通道是什么？是收钱吧，是支付宝，是工行招行，还是银联？
那么从本质上来说我们的钱从我们的招行到了老板的工行卡，因为我们的货币债权是由招行转移到了工行，所以毫无疑问招行是本次的收款通道、工行是本次的结算通道。
那有的人就会说，如果这么说，所有的钱本质上都在银行或者钱包公司手里，所以通道就只能是银行或者钱包公司对么？那这中间的支付宝、收钱吧、银联又算是什么呢？狭义上来说，确实如此。但广义上来说，通道的定义并非如此简单。
需要支付服务的公司就好比是一家超市，所有采购的商品虽然最终都是由厂家来生产，但是超市不会去联系成千上百个厂家来给自己供货，虽然厂家直销价格可能更优惠，但是他依旧会需要一些中间的批发商作为自己的供应商。一家供应商就能解决N种商品的供应，这样能为超市省下大量的联系厂家的人工和管理成本。在这个过程中，不管是厂家还是批发商，都成为了超市的供货通道。支付也是一样，货币债权的直接主体（各个银行）是通道，但是聚合了各种银行的三方、四方支付机构，也可以成为通道。
这也是直连通道和间联通道的由来。在上述例子中，直连通道有：招行、工行；间联通道有：银联、支付宝、收钱吧。虽然目前国内在经过了断直连改造后，在三方支付机构的视角里，已经没有直连间联的说法，但是在跨境领域和境外支付，这种场景还是依旧广泛存在。
所以很多时候，我们要有一个“通道意识”：我们在对接通道的同时，我们也是客户的通道，我们对通道提要求的时候，看看自己是否满足了客户的要求。
就如超市一样，超市本身并不生产商品，他必须依赖厂家或者一些批发市场供货商供货，超市才有商品可卖，才能生存，支付机构也需要一个个通道来为自己提供资金处理的能力，这样支付机构才能为收款人提供收款服务，为付款人提供付款服务。
所以，三方支付机构本质上就是基于支付通道而存在，并在此基础上而为收付款双方提供安全、便捷的支付服务的机构。甚至在早期，在支付方案不够成熟的时代，很多支付机构在大家眼中就是个卖通道的。从这种说法我们也可以明白通道对于一个支付机构的价值。
强如支付宝、微信，也需要客户先绑定银行卡。支付通道是三方机构的基石，没有通道，有再多客户、再强大的交易清算系统、再强大的解决方案都如空中楼阁，遥不可及。
对于日常的消费者（收款人或付款人）来说，通道是一个不可见的存在，他们所见的的也许是一个聚合支付的扫码牌、一个刷卡的pos机、一个支付方式的选择页面等等，但是对于我们支付相关的从业者来说，我们应当有能力去识别隐藏在背后的通道和一些简单的设计原理。
下面，我们选择用京东、美团、支付宝的支付页面。
这几个页面就是大家所熟知的收银台，而在图里我们可以很明显的发现，虽然内容完全不一样，但是由于每个平台都有很多支付方式可供消费者选择，所以每个平台都对支付方式做了不同的分类、集合。但是，分类的原因是什么、合并的原因又是什么？我们先简单对页面进行维度的梳理：
其他的支付工具：支付宝支付、微信支付。
而之所以有上面的这些分类，一方面是为了让消费者比较方便的选择他想要的支付方式，另一方面毫无疑问是因为通道本身也是有区别和分类的。
而通道我们通常会有以下常用的几个分类：
还以一些其他维度的分类，就不一一细说了。
每个支付机构根据自己开展业务的范围和倾向。
都会选择一种或同时选择多种分类来对自己的通道进行分类，同时还会采用合理的分类的层级分布。
而分类的目的就是为了梳理每个通道的特点、优点、缺点，以便于更好的使用每一个通道，最终提升自己的服务水平和客户的支付体验，同时还能更好的管控成本。
支付机构的业务变化往往是伴随着通道的发展，而业务的不同的阶段有不同的通道管理的要求。
1.4.1 通道管理系统的先决条件
在业务模式简单，而且通道少的时候，我们可能只需要几句话、几行备注说明，就能做好通道的管理。每个通道负责处理一类业务，使用上也没任何困难。
通道稍多的时候，可能我们就不得不借助一个结构合理的excel表，而且可能部分通道出现了功能重复，选择哪个通道更为合适的问题也出现了，不过这个问题还不算太麻烦，做好通道分类和信息整理，人工还能勉强管理。
通道进一步拓展的时候，靠人工对所有的通道进行高精度的管理已经是非常困难了，经常会出现各个部门或员工之间信息不同步的问题，从而导致了业务出现各种各样的事故。同时，相似的通道越来越多，如何选择合适的通道进行支付更是一个非常困难的问题，交易系统的自动化也面临巨大的困境。所以，如何高效的在公司内同步通道信息、做好成本核算管理工作，并且合理的使用好每个通道的需求就呼之欲出。而通道管理系统也应运而生。
当然，我们首先要明确一个大前提：
通道的复杂性和多样性是通道管理系统的先决条件。
如果是第一阶段，我们可能并不一定需要通道管理系统来支持业务，因为即没有管理需求也没有使用上的问题。第二阶段，可能只需要部分核心的功能就能较好的满足展业需求，这个时候并没有非常迫切的必要去搭建一个比较完整的通道管理的系统，毕竟技术资源也是有限的。只有在第三阶段，我们才有搭建完整通道系统的客观需求。
知道整个通道管理系统的架构非常重要，但是按实际业务情况，从整体功能架构中抽象当前需要的核心模块，减掉暂不需要的功能，同时为未来拓展打下坚实的基础，也是产品的必修课。
1.4.2 通道系统的使命
当然，假设我们确实需要搭建一个通道管理系统，那他应该至少包括两方面的核心功能：
通道的信息管理和通道的使用管理。
前者很好理解，而后者就是我们常说的：路由系统。而两个功能模块分别在支付体系内发挥各自的作用。今天，我们先来介绍前者：通道信息系统（后面简称通道系统）。路由系统会在后续的章节中再详细介绍。
设计系统之前，我们先问自己几个问题：通道系统的核心使命是什么？他需要为谁服务？仅仅只是路由系统吗？
所以我们需要和每个关心通道的部门同事聊一聊，然后我们可以总结到通道系统的两个核心使命：
为业务部门提供良好的通道信息管理工具。
让通道拓展部门了解通道拓展需求；让运营部门了解每个通道的性能如何；让销售部门了解公司现在对外能提供的支付能力；让财务部门了解每个通道的成本，让合规部门了解每个通道的风控要求等等。
作为系统各相关功能模块的通道信息中心。
路由、监控中心需要有信息来保证每笔交易使用最优通道：性能最好、成本最低、高成功率、高稳定性。计费中心需要有信息来统计通道成本，对账中心需要信息来进行对账项目和对账逻辑的处理等等。
这两个使命就是我们搭建通道系统的核心目标，整个系统的功能都应该为这两点服务。
换个角度来说：通道系统的核心功能就是对系统内模块和系统外操作人员做信息输出，本身基本不参与业务流程。
在明白我们的核心需求后，我们来谈谈怎么设计通道系统。
我们再将两个核心使命细化，你可以得到下面的图：
整理成通道系统在整体业务中的的业务架构图：
在详细的介绍通道系统如何设计之前，我们首先来介绍下通道的生命周期相关的知识。
通道生命周期就是一个通道在整个业务体系内从商务对接，到技术业务对接，到投产的整个过程。在国内通道同质化极高的情况下，三方机构本身是很少的去对接新的国内支付的通道了，但是商户对接支付通道以及在跨境支付领域，新通道的对接依旧是个常有的场景。
了解一个通道接入的生命周期、知晓每个节点各部门关注的点、理解其背后的底层需求，对我们设计和优化通道管理系统是非常有帮助的，所以我们也对此做个简单的介绍。
2.1.1 流程与节点
超市想找一个新的供应商，他会怎么办？首先他需要先搞清楚，他为什么需要找这个供应商，他需要供应商给他提供什么货？是拓新商品还是为老商品做个备份？找到了一个供货商，在确定合作之前，超市需要供应商告知他一些基本情况：供货的清单、商品的价格、补货的时效、账期等等，同时要验下货。超市觉得没问题，那就签合同，同时超市内部还得和相关的员工同步这个消息。而且，新的商品没经过市场的考验，超市一般会先少进点货，看看市场反应，反响不错再大量上架，这事终于成了。
从这个例子中，我们可以大致可以将通道的生命周期总结为以下4个阶段：
投产——正式运营，持续关注。
然后我们可以根据具体要做的事务，将其中的几个关键的节点列出来：
接下来让我们看看这些节点是如何推进，各部门的职责及需要产出的物料分布是什么。了解其职责与产出的需求，我们才能更好的明白，通道系统应该如何去服务他们。
2.1.2 参与方及其负责内容
基于不同的公司架构，每个节点的参与部门或者人员都会有所不同，而且需要完成的工作也会有所区别，这里给到一个角色与分工的示例表，仅做参考：
2.1.3 相关物料
经过整理，我们可以得到下面的角色与物料的表：
至此，我们对整个通道的生命周期，已经有了一个完成的理解，并对每个部门的述求都有了详尽的了解。此外，我们在上文有提到过，通道系统是同时需要满足业务部门和业务系统的双边信息要求，但是两者对信息的要求维度其实基本一致。所以通道系统应该输入的信息和输出的信息也基本成型了。
在理解这通道的生命周期后，我们可以根据阶段将通道系统拆分为3个功能模块：通道接入模块、通道信息模块、通道业务数据模块。
同时，每个模块都需要有信息的输入和输出功能。再结合之前的信息述求。可以得到下面的产品架构图：
一般来说，我们很少会在系统里专门去设计一个模块去做通道接入生命周期的管理，因为整体投入的性价比实在太低。所以通常我们会借助一些成熟的OA工具当做工单系统来推进节点、wiki工具做线上文档管理，来进行这种频率并不高的商务性流程的管理。
这里整理一些较为具体的工作内容，以作参考：
通道系统的本质就是提供通道信息的中心，因此这个模块是通道系统的最为核心的模块。我们的主要工作都在于如何抽象通道信息并搭建通道系统的信息输入输出体系。让通道系统真正的成为支付体系的基石。
3.2.1 通道的层级
前文我们有提到，通道分类的维度很多，使用符合公司业务需求的分类是架构通道系统的大前提。而往往单一的分类是不足以满足日常的通道管理需求的，所谓通道的层级就是我们所采用的通道分类维度的先后。
比较常用的一种分类逻辑是首先按业务线分类，而对于很多公司来说，业务线大多由目标客户群体决定，所以我们对通道的第一层级分类也会基于这个基调而展开。后续的层级，则会更加自由一点，但核心目的都是为了很好的满足管理需求。
举个例子，公司两条主要业务线：境内业务、跨境业务，境内业务线主要服务于零售类商家的日常收款，跨境业务线主要针对出口贸易卖家提供服务。那么我们也许可以采用如下通道分类结构：
又或者，公司主要是为电商平台提供支付服务，面对的都是个人付款人，那我们也许可以采用如下的分类结构：
一个合理的通道分类，能够让我们大大的提升公司的通道管理效率，实现通道系统的价值。分类确定后，通道信息模块的架构基本就确认了
3.2.2 通道的信息层
做好通道分类之后，接下来就是按分类进行通道信息的抽象了。
我们把我们业务所需要的最小颗粒度的通道信息称之为：通道能力。
那么如何进行能力的抽象？例如：一个通道的快捷业务支持10个银行，如果所有银行的所有参数（费用、时效、体验、清算等等）一致，而且其他通道的快捷业务特征也如此，那我们可以认为，这个通道有一条快捷的能力，它支持10个银行，他的能力是XXX。
若10个银行的特征不一致，则我们需要认为：这个通道有10条10个银行的快捷能力，他们的能力分别是XXX。
根据前文，以入金通道为例，我们先把初步把通道信息抽象为下图：
显然，这么多信息并不便于管理，而且我们会发现，在实际情况中，往往一个合作伙伴会同时拥有多种服务能力，就会出现一个现象：
一个通道可以拥有很多通道能力。
不同的相似通道之间，也有非常多的信息是相似的。从管理上来说，这些通道信息都可以被统一管理。所以我们一般需要在通道能力的管理，维度上面，新增一个信息层级，例如取名为：通道管理。这样我们就可以在一条数据上维护这些一致的信息了，不需要到N条能力数据上去维护，大大的降低了管理成本。
所以我们可以将通道的信息管理分类拆分为如下两个层级
通道信息变更的时候，会影响其所有的能力，能力数据变更时，只会影响本条能力。
3.2.3 通道的信息分类
有了信息层级之后，可以进一步的将信息按需求拆分：财务、合规、交易结算等等
3.2.4 通道的数据权限
数据准备的差不多了。那么该该考虑谁能看的问题，也就是数据权限的问题了。
权限，是任何后台系统设计都必须考虑的要素。而通道信息，作为支付公司的核心信息模块，权限设计更是其非常重要的一环。
常用的权限有两类：操作权限、和数据权限。操作权限就是操作员是否有某些页面、某些按钮的权限。数据权限就是即便在同一个页面，不同的人看到数据也是不一样的。
我们设计通道系统时，一定要考虑功能如何去满足不同操作权限的操作员的需求，例如我们上文举例的原型：我们将成本信息和交易信息合并在一个页面展示，若不设计数据权限，那么我们就无法满足高级权限人员（可知道通道成本）和低级权限人员（不应该知道通道成本）的需求。那这个设计方案就是不合理的。
另外说句题外话，作为产品经理，应当对数据在数据库的存储模式有粗浅的了解。数据库中的数据表都可以认为是一个个excel表，有行有列。数据权限就是对行数据和列数据分别做权限控制。
我们用两个例子来解释这两种数据权限：
当然有时候如果开发资源不充裕，我们也可以取个巧，手工权限，就是一个页面复制两遍，各自展示各自的信息，这样就不需要去实现数据权限了。
总而言之，无法实现权限分离的设计，都是存在缺陷的。我们在设计任何功能时，一定要时刻考虑权限。这个方法不仅限于通道系统设计，任何设计也都是通用的。
3.2.5 通道信息模块的功能架构
按照功能模块的使命，结合信息的层级与分类，我们可以基本设计通道信息模块的功能架构：
现在，我们可以来进行具体的系统功能设计了。
3.3.1 模块设计逻辑
这里我们会用到两种设计逻辑：
将不同用处的信息分散到不同的页面上，进行模块化分开管理。
比如我们会有通道对账信息管理、通道成本信息管理、通道交易信息管理、通道响应码管理等等，这样的好处在于结构清晰，权限采用操作权限设计方案，实现简单。但因为模块相互独立，但是参数相互间有较强的关联，会带来一定管理方面的困扰。
将关联性较强的信息合并在一个页面进行维护。
比如通道交易信息和成本信息和合规信息，都是后续路由系统的核心信息，那么我们就可以把他们放在一个地方维护，辅助用权限进行数据隔离即可。优势在于维护方便，但是结构上会相对不够明了，同时对权限体系的要求也更高，基本需要实现列权限才能按这种方案设计。或者公司本身对权限管理相对简单，也可以使用该方案。
两者各有优劣，而且通常我们会同时采用这两种设计逻辑，有机组合才能搭建出一个架构合理，可用性又高的通道系统。
接下来我们给到几个示例页面，通道信息页面是和业务联系紧密度非常高的功能，因此不同的业务场景，不同的阶段，所需要的通道系统也是不一样的。这里给到的只是一个样例参考。大家主要参考整个设计思路和信息结构的框架。
3.3.2 通道信息页面
设计的核心逻辑就是前文提到的通道分类结构和信息层级，只有明确了通道分类，才能清晰的定义通道和能力的管理层级。
在这个例子中，我们用到了4个分类：支付载体、业务形式、支持对象、支持银行。（当然实际原型中会有类似type切换的交互，截图中不做展示）。
同时，我们新增了通道编码的概念，因为大部分公司对通道都是有权限控制的，所以很多时候系统内都会用编码来代替真实的通道名称，以作权限控制。
3.3.3 通道能力信息页面
通道新增后，可自动生成通道能力（部分信息设置默认值后续编辑），也可手工批量新增。
通道能力的字段在于之前提到的各个部门或系统需要的信息。不要抽象无用的字段（比如代付通道的支持银行），也不要少抽象字段。这个尺度的把控就要求设计者对公司的各业务逻辑都要有一定程度的理解。当然若是真的有所偏差，信息架构合理的情况下，迭代也不是一件麻烦的事情。
由于入金、出金、鉴权通道字段可能有所差异，所以我们需要有不同的页面来管理各自的能力，当然也可以合并在一个页面，一切取决于实际情况与设计倾向。法无定法，一切为我们的核心使命服务，保证自己在正确的方向上，即便设计不够完善，也不会有太大的偏差。
此外通道能力往往会远多于通道，所以我们设计了批量增改的入口，当然如果业务需要设计复核权限，也可以添加。
3.3.4 通道响应码管理页面
通道响应码管理，参考页面：
页面一般由IT和运营同事共同使用，用以保证映射的准确和友好。有新增的响应码时，应当有默认映射的内容，同事可以自动新增一条记录，避免异常。
3.3.5 通道参数管理页面
通道参数管理，参考页面：
参数管理页面并非必须页面，一般由IT相关同事使用，尤其需注意权限。
3.3.6 通道黑名单管理页面
通道黑名单是针对某些被通道拉黑的主体，但可能尚未被我司拉黑，因此将他置于通道黑名单中进行特定的交易阻断。黑名单一般适用于整个通道而不是仅限于某个业务类型，一般需要手动维护。黑名单主体将无法被路由到对应通道，主体类型会有：证件号、名称、卡号等。
通道黑名单管理，参考页面：
3.3.7 通道备案管理页面
部分通道有预先备案的业务逻辑，未备案主体无法进行交易。备案过程可能有api或人工，api模式也行可以设定自动备案逻辑。但是无论那种方式，都需要有页面进行备案信息管理。
通道备案管理，参考页面：
3.3.8 商户通道信息页面
经过上面的功能，我们已经基本实现了通道信息的输入与输出，基本满足了对中后台员工的管理诉求、系统功能模块的信息诉求。但是还欠缺一个最重要的功能点，即满足对客的通道信息输出。参考京东的收银台页面，对客展示的限额应当是所有通道能力的汇总有效限额，再有销售同事也需要对公司的通道能力有所了解，这个能力也应该是汇总的通道能力。
所以我们还需要通道系统有产出汇总数据的能力。
通常来说，我们在通道充足的情况下，会通过给不同级别的商户配置不同的一堆通道能力来说满足商户分级的业务述求。一般我们称之为通道组，具体的配置逻辑我们会在介绍路由系统时详细说明。所以这里面其实有个小小的流程：
给销售、客服同事提供的商户通道信息参考页面：
整体功能会相对简单，主要依赖研发同事的实现和通道组的配置。
至此，整个通道核心使命已基本完成。
任何系统和业务的成长，仅仅满足于当下是不够的，所以一定周期的数据分析工作是非常有必要的。如果通道系统能产出分析数据来补上最后一块拼图，无疑是一个非常好的收尾。
在这里我们主要会用到两类数据：统计类数据、分析类数据。我通常也会称之为结果性数据和过程性数据。
结果性数据：某个通道在某个周期内的交易量、成本、成功率、业务数据分布等等。
过程性数据：通道业务数据的变化，比如一定周期内的环比、同比数据。
一般我们可以选择用数据报表的形式来展示，大家可以根据各个业务部门的关注重心，为他们定制其需要的业务分析数据，从而反哺通道系统，最终持续强化我们的通道管理能力和通道结构。
一定要时刻牢记通道系统的两个核心使命：为业务部门提供良好的通道信息管理工具，让系统尽可能详细的了解每个通道的特征。
深入的了解公司通道生命周期：每个节点会有什么部门参与，他们各自需要做什么。
对通道合理的分类，设计良好的管理架构，抽象信息字段，是搭建通道系统的重中之重。
随时考虑权限的设计，是检验设计主干是否合理的重要方法。
大数据量和数据层级复杂的背景下，如何提高功能的可视化程度、降低操作的难度，需要好好的做些思考。
最后，通道本身就同时具备死板与灵活的特点的，通道系统没有什么固定的设计方案。我所使用的例子主要还是用以展示设计思路，希望大家活学活用，适合自己的才是最好的。
专栏作家
陈天宇宙，微信公众号：陈天宇宙，人人都是产品经理专栏作家。多平台支付领域专栏作者，十年资深产品；专注为10万支付产品经理和支付机构以及企业提供深度支付内容和服务！
本文原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于 CC0 协议。
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。