同学们经常在支付相关文章中看渠道对接，支付渠道是什么？支付渠道即资金转移的通道，
也称为资金渠道、支付通道，所有支付系统建设都需要先建设渠道。
以电商平台为例一般来说主要对接两类通道三方支付机构、银行；三方支付机构就是我们平时熟悉的微信、支付宝等，银行主要是银企直连通道，为平台提供一些资金收付的解决方案。在商户与三方支付之羡昌芦间，还有第四方支付。四方支付是作为对第三方支付平台服务的拓展。
第三方支付介于银行和商户之间，而第四方支付是介于第三方支付和商户之间，没有支付许可牌照的限制。
银联、网联等清算机构主要是为非银行支付机构、银行等提供网络支付清算平台的运营机构。
央行是清算中心，清算中心是所有支付清算服务的最底层。我们日常经常使用的支付宝、微信的银行卡支付（微信、支付宝的余额支付是属于三方支付的内部账户支付，没有实际的资金流清算，不过央行的清算中心）。
企业的代发工资等等最底层都是使用的央行的清算中心，比较常用的有以下几个：
小额系统： 又称小额批量支付系统，是人行建设的系统之一，采用批量包的形式进行交易，工作时间是24小时受理，每家行根据自身需求间隔2小时或4小时一打包进行请求发送，所以小额系统的到账时间是不确定的。
对于小额系统来说交易资金会有交易限制，交易金额不能超过5w，超过5w的必须走大额。
大额系统： 又称大额实时支付系统，也是人行建设的系统之一，采用单笔交易，工作时间是工作日的一般早8点30分到晚5点，有些行会在这个时间内自行定义自己系统运行的时间，如下午4点就关闭了。
对于交易资金没有限额限制，任意金额（没有5w的资金限制）都可以使用大额系统进行资金划转，只是手续费相比小额来说会稍贵，到账时间是实时到账，支持的银行也是目前最广泛的。
超级网银： 超级网银在中国又被称为“第二代支付系统”，采用单笔交易，交易金额上线为5w，面向客户免手续费，工作时间做到7*24不间断运行；目前加入超级网银的银行占据大多数，基本上国内大中小城商行均加入了超网系统。
但是仍然有少量几十家城商行未开通超级网银渠道，所以目前我们在日常生活中常用的转账系统在后台都极有可能走的超网渠道，因为到账快、成本低。
以对接银行直连通道为例，以下是平台与银行交互的主要步骤，按照经验对接一条通道，从商务谈判到最终的商用切量时间在1-1.5个月左右。
其中大概1周左右的商务谈判过程，1周的产品设计时间，2-3周的开发与测试，1周的对接联调时间，与银行的对接联调主要依赖于银行的效率。
在通道对接中，涉及到了各个部门的很多角色，包括商务、产品、技术、测试、财务、以及运营人员，各个角色的大体工作职责如下：
其中通道信息评估表是接入前评估通道质量，兄带确定通道优先级的重要依据，需要商务、产品、技术等人员配合完成。
通道评估表涉及以下方面：
基本信息通道名称等基本信息：
在完成完毕以上所有事情后就可以由产品经理涉及通道上线的商用计划，按照商用计划观察切量；一般来说一条细通道上线都需要用2周左右的时间逐步切量，密切观察交易数据。如有异常可以及时切换通道路由。
“九层之塔，始于累土”通道是支付的最基础，只要充分了解通道才能做出最合理完善的支付方案。
通道从广义上来看其实就是只要能完成支付信息传输以及推动交易完迅喊成的接口或者其他形式都可以成为通道，支付信息传送的通道；我们为通道做一个更广义的分类，从通道提供方或者通道形态做阐述。
银行通道：
就是银行提供给三方支付机构的收单出款以及垫资通道，鉴权通道；以及提供给企业的银企直联通道；银行支付通道又有快捷通道，网关通道，代扣通道，垫资通道，预授权通道等。
网银联通道：
断直连后，网联银联通道包装商业银行的通道给三方支付公司，基本跟银行通道类似，满足各类支付业务场景需求，比如协议支付，商业委托支付，网关支付，认证支付等。
三方支付机构通道：
就是三方支付机构提供给商户的收付款支付通道，比如微信，支付宝，易宝支付。
自建虚拟广义虚拟通道：
作为一个平台在某些交易场景会用到更加多样的支付方式，我们都可以称为通道，比如利用自己搭建的账户实现平台虚拟余额的交易支付的余额支付通道；卡券支付通道，积分支付通道等。
所以综上，通道建设其实就是支付的基础设施，最终目的是完成支付信息的交互传输，推动支付交易的完成。
微信支付宝通道我们就不过多介绍了，到官网看一下支付文档就全部明白了，按照接入规范进行接入即可。
基于业务需要我们要接入一条新的通道，比如我们要接入一条代付通道，经过市场调研，我们选定了“厦门银行的某款代付通道产品”。
通过商务我们联系到了厦门的通道服务部，经过浅谈会后，商定了相关事宜，比如成本等等。
此时我们就会获得银行的通道接入文件包，包里有你需要的所有内容，并且和技术支持的介入，有不懂得问题可以实时沟通。
一般拿到的接口文档包，我们就可以开始做产品设计和技术设计了；产品设计主要是查看该通道的业务交互逻辑以及支付请求和返回的相关字段要求，以此编写产品需求文档，技术人员根据文档的技术要求规范开始技术框架和方案的设计，准备开工。
支付通道文档包：
基本就是通道本尊了，包含对通道的定义，接入办法等信息，文档包内容如下：
正式和签名包产品可以不看，产品主要看接口文档说明，从中巴拉需求：
从目录我们可以看出，文档一般包含这几部分内容：
协议概述：主要说明技术要求，技术规范，接入的技术方式等，这部分技术看就行了。
业务接口规范：这个就是定义核心的支付接口入参和出参，也是产品巴拉需求的核心部分，我们可以看出接口需要哪些字段，比如流水号，商户ID，金额等等，这样就可以设计出支付处理核心应该封装的协议了。
比如我们看一下3.1交易接口的定义：
定义接口：
提交一笔支付时的请求参数：
别管平台自己怎么处理，只要按照通道接口要求，就可以完成支付。
请求完的接口返回：
看完这一个通道接口的定义，是不是瞬间豁然开朗了，知道了支付体系应该怎么设计，怎么封装信息了；其他接口逻辑类似，比如账户余额查询接口，交易结果查询接口等。
通道返回码：
通道返回码就是两边的沟通语言，告诉你成功了还是失败了，失败的原因是什么，当然基于业务需要和用户体验，我们一般不会将通道返过来的编码直接展示给用户；而是封装一层，让用户更容易理解，体验更好。
一个平台一般都会接入很多类型的通道，虽然通道只是一些列的接口组合，但是这时候单单通过程序中的接口研发已经不能满足业务需求了；就需要一个通道管理后台来管理接入的每一条实体通道。
比如通道管理列表：来管理每一条通道的基本信息，比如通道名称，通道编码标识，通道所属银行，通道的类型，通道方的联系人等等；通道编码标识就是平台唯一识别这条通道的ID，比如路由器选择的最后其实就是选出一个通道ID
通道证书，就像原来我们通过网关支付时，跳转到银行的网上银行，我们都需要下载一个安全证书或者插入U盾，这些信息都可以维护到通道的基本信息里；我们可以把通道当成一个用户一样去管理，通道也有通道画像。
作者：陈晓光，一个会弹吉他会算命的产品经理老司机，微信公众号：陈晓光
题图来自Unsplash，基于CC0协议