如今，支付通道已经是日常生活和商业交易中不可或缺的部分，也是各种支付业务的基础。本文作者对如何接入支付通道及规划通道管理系统相关功能进行了分析，一起来看一下吧。

从最初的现金支付到当下的电子支付，支付通道已然是日常生活和商业交易中不可或缺的部分，也是各种支付业务的基础。本文将详细解析如何接入支付通道及规划通道管理系统相关功能。

01 什么是支付通道

以运输货物为例，要将一批货从A地运到B地，可实现的运输方式有路运、海运、铁运、空运。相同的目的地，不同的运输方式，往往还有许多不同的航道、铁道和公路可供选择，只不过过程中耗费的时间、承担的风险、金钱成本不同而已。

1. 支付通道概念

类似于运输，支付通道的本质是通过构建一个个信息交换的环境，用于支持交易过程中多方之间的信息的传递和验证，以实现交易资金的流动，最终促进交易的完成。

狭义上支付通道是指交易时连接消费者、商家和银行各方钱包账户的网络通路，而从广义上来看，只要能需满足支付的需求，并将信息、资金成功安全地转移给对应的收款方的路径，即使是企业的用积分去支付、利用虚拟卡、利用虚拟账户等内部的资产形式来支付，与这些管理资产的系统对接接入，我们可以说接入了“内部的虚拟支付通道”。

2. 支付通道的分类

随着支付行业的发展，不同支付场景催生出多种多样的支付通道，不同的通道细分出了不同的特点，我们可以从多个不同的维度进行分类，来更好地感知支付通道的差异。例如：

• 支持不同卡类型的通道：仅支持借记卡的通道、仅支持贷记卡的通道、借贷卡都支持的通道；
• 扣款交互模式不同的通道：扣款前需要签约、鉴权的快捷通道、可建立预付授权关系，用于信用卡还款和水电煤缴费的代扣通道、需跳转银行页面进行付款的网银通道、通常被用于手机话费支付和流量充值等业务的手机运营商鉴权通道、支付时使用微信、支付宝等第三方支付平台输入支付密码或者进行指纹识别等进行认证的身份认证通道；
• 交易支持不同发起方的通道：持卡人（用户）发起、商户（平台）发起；
• 有不同行业限制的通道：微信代扣就仅限符合周期扣费和先享后付场景的行业使用，会员续费、水电煤民生类行业、打车、酒店类行业、停车场或高速公路无人缴费；
• 扣款要素不同的通道：如网银需要卡号和密码二要素、快捷则需要验证卡号/账号、户名、证件号、手机号四要素；
• 支付标的物不同的通道：比如用积分来支付、银行卡支付、代币支付、虚拟币支付、银行卡支付等。

1）根据通道的用途

通道的用途，顾名思义就是通道的功能，直白一点就是用来干嘛的，分为收款、付款、认证、跨境等。

• 收款通道：常说做支付要先做收单，收款通道就是实现让别人的“资产”付给自己的通道，打比方有早餐店“扫码支付”收钱立牌、线下商超的POS机支付、各类公交地铁卡和乘车码。
• 出款通道：“出来混总是要还的”，出款通道能够实现把自己的钱付给别人，好比公司给我们发工资的代付通道、灵活用工通道、银企直连通道。
• 鉴权通道：鉴权通道可以被想象成一条连接交易双方之间的安全通道，要先经过验证，才能通往支付之门。常见有银行卡签约验证；身份信息认证（四要素等），像账户的一些实名认证以及银行卡的绑定都需要用到；3D-Secure（3DS），一种用于网上支付的安全协议；指纹识别、面部识别等生物识别技术，通过授权人的生物特征来进行鉴权。

2）根据通道支持的对象

通道支持的对象，指的是支付交易的双方是谁，可以是个人、企业、组织等，通常我们区分为对公和对私。

• 对公通道：用于企业账户支付，包括企业网银，企业账户代扣，企业转账等等。
• 对私通道：用于个人账户支付，包括银行卡支付，微信、支付宝等三方个人账户支付。

3）按渠道提供方分类

其实支付通道是分层次的，下层为上层服务。不同的角色（按有无支付牌照、金融资质区分）对应所需的通道提供方是不同的。

• 对于普通企业：通道的提供方是具有支付牌照的三方公司如支付宝、微信支付；各个银行；或者是企业自己内部搭建的虚拟账户支付通道、卡券支付通道、积分支付通道等。
• 对于三方支付机构：那些有支付牌照，能对外提供支付能力的三方机构，他们需要的通道则是金融机构（银行、网联、银联）的核心系统。
• 对于银行：银行所需的通道就是央行（也就是人行）的大小额系统、超级网银系统，这几个通道也是金融活动的根基。

4）其他分类

根据支付方式：就是用户在平台下单后调起收银台看到各种各样支付方式，包括云闪付、支付宝、微信支付、Apple Pay等。如京东PC收银台就有2个支付品牌，京东支付和微信支付；3个支付方式，白条、小金库、微信扫码支付。

• 根据支付场景：包括线上支付、线下支付、跨境支付等。假设你深夜饿了，通过饿了么点外卖之后支付宝线上支付，或者出去楼下实体店面吃一碗隆江猪脚饭用二维码线下支付，然后早上醒来后像梁朝伟一样去伦敦喂鸽子，想喝一杯咖啡就需要用到跨境支付了。
• 根据支付保障机制：包括担保交易（拍卖网站的拍卖交易就是一种担保交易方式）、中介支付（像电商支付平台，买家付款后会将资金冻结，待确认收货后才会把钱付给卖家）、风控评估（例如，贷款公司对借款人进行风险评估，判断其还款能力和信用水平）等。

对支付通道有了初步的认识之后，我们来假定以下这样一个场景。假如你的公司要上线一个新业务，涉及到线上交易，需要你来负责接入支付，你会怎么处理。

3. 支付通道的结构关系

要深如了解支付通道，我们还需要知道一个通道在支付体系中所存在的结构关系，这也是很多人容易混淆的，特别是支付方式、支付通道、支付品牌、支付产品、支付合作方之间的关系。

支付方式、通道和品牌上文已经释义过，而什么是支付产品呢，我们借用微信支付的定义，支付产品其实就是支付机构针对某个支付场景，提供给外放使用的一套“解决方案”，其最基础也是最核心需要包含“支付通道”和“账户”两个服务，然后才能结合不同的场景包装出不同的产品。

1）支付通道-支付方式的关系

同一个支付方式，除了自身的官方通道，往往也会授权其他机构合作封装出对应通道，所以一个支付方式是由多个支付通道可以选择。

2）支付通道-支付合作方的关系

支付通道跟不同的合作方，又是处于什么关系呢。假设“光企业”要通过易票联接入微信支付的通道，那这条通道跟各个机构的关系如下。

3）支付通道-收付账户的关系

文章开头咱们也讲过，通道最终目的就算将不同收付账户之间的资金进行转移。以微信支付通道举例，可以看到通道和账户之间的关系和资金的转移。

4）普通商户的支付通道结构关系

作为一个普通的企业，是有可能同时接入多个支付方式，因此也会有多条支付通道，那么这之间整体的关系又是怎么样的呢。

5）普通商户与金融机构的支付通道结构关系

再往下走就涉及到支付机构和清结算机构了。

通过上面的结构关系分析，我们可以初步看出一个从用户支付方式到各层支付支付组织之间的关系。

02 选择支付通道

寻找合适的通道之前，我们来看下应该怎么选。

假设你是光企业的物流运输部，你需要采购一辆货车，那你肯定需要关注对应货车的属性有哪些对吧？车型是普通货车还是牵引车、载重总量是多少、要燃油车还是新能源等。

选通道也是，要知道通道都有哪些属性，这些属性就是我们在选择时要思考的维度，这些属性也是后续路由去判断的维度依据。

了解了通道的属性，就对通道有了更直观的认识，那么就可以基于需求区选择所需要的通道了。

1. 基于业务和交易场景做选择

要选择什么通道，要先了解业务的场景，不同的业务模式需要不同的支付方式。例如，传统的线下零售业务可以选择POS机、微信支付宝的主扫、扫脸等，而线上平台则需要根据不同的平台进行选择。

打比方公司准备依托微信小程序开发一款“针对园区等高密度打工人区域的午餐外卖”产品，则肯定是需要选择接入“微信小程序支付”方式的通道，而不可能选择支付宝。当产品成熟了有余力了再考虑拓展其他平台或者接入其他支付方式的通道。

2. 多维度指标评估预选通道

选定好合作机构之后，可以根据下表，评估该通道是否符合公司业务需求，评估满足需求的话，就可以着手接入了。

3. 通道的接入流程

1）参与的团队成员及分工

2）对接准备

步骤一：明确自身需求

对接之前，先确定自己的功能需求，比如我们是做演唱会票务，用户抢票之后是不允许退款的，那此时没有退款功能也不影响第一期上线。另外如果咱们是租赁场景比如租房，需要向用户收押金，但是退款往往有时限，这个时候就需要思考其他退款办法了，比如接入打款通道。

步骤二：明确接口文档

一般的支付公司为了方便广大用户使用,提供各种不同的接口,相同的功能也进行多变的实现。所以我们跟对方讲清需求后，对方开发人员通常比你更熟悉接口的使用和效果，他们很可以帮助我们快速找到最优的接口方案。

另外，很多合作方的文档都可能存在更新不及时问题，可以跟对方确定清楚用哪个板本的文档。

步骤三：研读接口文档

必须弄清你需要哪些接口后，我们要看清楚接口字段值怎么传、是否必传，以及有什么响应码。另外注意要和对方确定好返回结果是以码为准，还是以描述为准。

步骤四：输出需求文档

包含接入的背景，罗列功能点，第一期做哪些。

这里先强调一个支付中和退款中的问题，一定要牢记设计支付状态要考虑中间状态，以免产生线上问题。

此外安全类对接准备也需要提前沟通清楚，如IP地址白名单是否配置，怎么配置；公私钥加签验签；接口加密解密；是否需要专网、前置机堡垒机等，作为普通企业，如果不是对接银行核心系统的话，一般是不需要前置机堡垒机。这个环节你也可以拉上开发大哥协助评估。

03 通道管理系统设计

选择好要接入的之后，我们就需要规划我们的通道管理模块，以避免后续支付业务壮大了，最基础的模块却一团糟，因为很多人都是图快，先干上线，等到发现好乱了的时候，已经为时已晚。

规划通道管理模块之前，我们先看下通道管理在整个业务系统中是在哪里发挥作用的。

上游系统选择完通道，就可以拉起对应的支付、退款、打款请求了。

接着我们就来分析，我需要为通道管理规划什么样的功能。管理管理，首先咱们肯定得知道有什么通道，才能管理吧，因此肯定需要有一个通道管理列表。

1. 通道管理列表

这里以入金通道举例子，接入通道之后，每一条通道都有唯一的通道名称和编码，这个好理解，就像每个人都有身份证和名称一样。然后再把通道关联上支付方式和状态，没有其他追求的话，这个通道管理也就能用起来了。

不过咱们还是要为以后打好基础，站在企业的角度，咱们是不是需要核算每一次支付产生，企业所要付出的成本，也就是通道手续费，此时我们就需要为该通道关联对应的“成本规则”；比如站在运营/维护通道人员的角度，通道的一些商户号、回调地址有时候也需要变更，我们是不是做成配置化会显得更人性化；假设我们财务要知道每一笔支付是去到哪个账户，好去核对每天的账目，那我们是不是需要在通道关联“入账账户”会让后续的对账更方便（注意这里不是指定真实的资金流渠道哪个账户，而是纯粹的记录，方便后续核账）。

至于“映射通道代码编码”和“权重”，没有也行。“权重”主要是为了方便路由去兜底一个支付通道。而“映射通道代码编码”作用是让运营和后续接手的开发知道，这一条我们“定义的通道”对应是走那一套真实的通道代码。阐述一个具体情况，当我们公司接入某家公司同一条通道，但是出于商务等原因开通了几个商户号，这几个商户号要参与路由切换，而背后对应的代码，则是同一套。

所以一开始设计的时候，个人建议把我“不同真实通道+不同商户号”为最小颗粒度，定义我们通道管理里的唯一通道。

2. 通道成本规则

通道成本规则我们设计成单独配置规则，然后再从通道关联对应的成本规则，这样就不用新增通道的时候反复配置同样的成本规则。

遇到银行卡通道的时候，不同的银行收的费用可能会不一样，所以可以根据自身需求定义一个特殊银行特殊配置，如果特殊银行多的话，建议用导入配置文件的交互形式。

至于通道成本怎么用呢，其实就是在我们发起交易和退款的时候，读取对应通道的成本规则，计算出这一笔交易所产生的成本，并记录在每一笔支付记录里面，以后统计就可以很方便拉。

3. 通道参数配置

通道参数配置，一般是配置比较敏感的内容，商户号、请求地址等，记得做好菜单或者功能权限，专人专用。

04 银行卡代扣通道接入实战

1. 接入背景

为给客户提供更快捷、更优秀的支付体验，我们团队决定开发上线一个银行卡代扣支付功能，让用户实现账单的自动代扣支付，免去繁琐的操作。

经过公司领导层商议，决定接入PAF协议支付这条通道。

2. 研读接口文档

1）接口调用流程

通过接口调用流程，我们可以看出要银行卡代扣通道，要完成支付之前，还需要进行签约两步。

第一步调用协议签约接口进行签约请求，下发短信给用户，用户输入短信后调用协议签约短信验证接口验证验证码，完成签约；

第二步通过协议签约返回的信息（签约号）进行协议扣款，并同步返回交易状态。

弄清楚流程之后，我们继续细看接口文档。

2）签约环节

①协议签约接口

就是发起协议签约申请，发起成功后会给持卡人下发一条短信。

可以看到这条通道申请协议签约的时候，需要上送一个银行编码，并且这个编码是要根据这条通道的定义来，看到这里我们就要联想起两个问题。

第一点，卡签约的时候需要知道这张卡是什么银行卡，这个后续跟大家介绍卡bin模块。第二点是，不同无卡通道有可能存在的特殊标准，使用的银行编码标准与其他不相同，这时可以回想我们的通道属性和特征，就存在通道银行编码的对应维护了。

这里再说一个点，有一些通道签约信用卡的时候，需要上送CCV和有效期，而刚好这条通道不需要，因此前端签约页面也需要根据不同的通道进行路由，从这里又印证了咱们通道管理和维护还是蛮重要的。

调用签约申请之后，合作方会给持卡人手机发送短信，并接口返回一个令牌号。

②短信验证接口

用户输入短信验证码后，接口上送验证码和令牌号，就可以完成短信验证，验证通过就可以签约成功，获取对应的协议号。

3）扣款和退款环节

①扣款接口

拿到签约协议号，则可以根据该协议号进行发起扣款，咱们看接口说明，需要特别注意交易金额这个字段，单位是分，千万要搞清楚交易金额的单位，别摆大乌龙。

另外咱们看到有一个后台通知地址，他是我们发起扣款交易时，指定一个交易结果的通知地址，当交易有结果后，通道方会将结果告诉我们，按照上述地址。像更严密的通道方还会要求接入方进行结果响应，并且有一套完整的通知策略。

发起扣款之后，我们就需要关注扣款是否成功，可以看到响应信息已经说明这个操作成功仅代表请求成功，不代表交易成功。

因此这里重点说一声，支付状态一定要有支付中这个中间状态，以及要对支付中这个状态有对应的补偿机制，不然很容易发生线上交易事故。当你发起一笔交易的时候，还没收到通道方的结果之前这一笔交易就是支付中，等到有回调结果或者主动查询，再根据结果更改状态。

另外我们也要关注，单笔交易有无最低金额限制，以及并发量最多是多少，能不能多线程。

顺便再提一嘴，最好建议开发大哥在封装支付和退款接口的时候，即使接入了很多不同的通道，建议也尽量封装成一个统一的下单接口和回调接口给业务层用，可以避免很多麻烦。

以及一定要让前后端大哥们记得做防抖！

②退款接口

退款也可以看到，金额单位是分，以及退款也需要加退款中状态，同扣款一样就不赘述。

这种退款是原路退回，通道方会做好校验，一般不太可能一笔支付多退了钱，倒是要考虑退款时效是多长（有的合作方限制交易半年或一年后就不能退款）、能不能部分退款、退款次数有没有限制、同一笔支付能不能同时发起2次退款。

4）响应码

一般响应码有公共响应码和不同接口对应的业务响应码，这里建议前期梳理出一些常见通用的响应码，并“翻译”出用户可读懂的文字，以供展示。以及可以在报错类的提示前面加上通道合作方英文，以方便定位是我们系统报错，还是哪个通道方报错。

如我们公司定义为DM，某通道方定义为PAF，则报错内容展示为PAF:XXXXX，就可以很快速定位到是通道方的报错。

3. 功能规划

1）用户端签约

考虑到用户体验问题，用户绑卡签约的时候最好就是不用自己输入卡号和选择所属银行。因此我们就要接入银行卡OCR功能，以及需要根据OCR识别出来的卡号匹配到银行卡所属的银行以及银行卡的类型，才能根据通道方的要求来上送银行编码和卡类型，这个时候卡bin模块就可以派上用场。

具体用户端交互大家可以去参考支付宝、微信等大产品。

此外建议保留让用户手动选择更改银行卡所属银行的功能，避免卡号识别错误导致无法进行签约。

2）卡bin管理

卡BIN是一种标识银行卡的编码方式，又称为银行识别码。它通常由6到9个数字组成，前几位数字可以表明银行卡所属的银行、卡的种类以及卡的国际标准组织（ISO）代码等信息。卡BIN在银行卡的处理流程中非常重要，可以用来验证卡的有效性、确定卡的类型及所属银行等信息。

国内的卡表信息如下图，一般跟通道方拿一下都会有。

经过数据清洗之后，提取我们所需的信息，银行卡中心的卡BIN管理就出来了。更加专业一点的公司甚至会将卡BIN图标配置进来，以及将通道和卡BIN进行匹配关联维护，做到更加精细化管理通道所支持的能力。

有了卡BIN之后，我们就能根据用户输入的银行卡号匹配该卡所属银行。

匹配逻辑可以如下：

首先用银行卡验证luhn算法校验卡号的正确性，如不正确可以提示用户检查修改卡号。其原理是将银行卡号逐位相加，然后将结果与校验码比较。具体步骤如下：

1. 从银行卡号的最后一位数字开始，逆向将每个数字和它的位数做乘积。
2. 将这些乘积相加，得到一个和值。
3. 将和值除以模数（10）取余，得到校验码。
4. 如果校验码与银行卡号的最后一位数字相同，则银行卡号有效，否则银行卡号无效。

以中国银行卡为例，luha算法的模数为10，校验码为银行卡号末位数字。

实际操作中，可以先将银行卡号转换为int类型，再进行计算和比较。例如，以下代码可以验证一个银行卡号是否有效：

“`python

def check_luhn(card_num):

num_list= list(map(int, str(card_num)))

fori in range(len(num_list)-2, -1, -2):

num_list[i]<<= 1

ifnum_list[i] > 9:

num_list[i]-= 9

ifsum(num_list) % 10 == 0:

returnTrue

else:

returnFalse

“`

其中，str(card_num)将card_num转换为字符串，map(int, str(card_num))将字符串转换为由每位数字组成的列表，然后进行逆向乘积求和，并进行校验。

代码来源：chatGPT，仅供参考。

目前银联卡几乎都支持校验码算法，但是也不排除极个别不支持此算法的，如杭州银行早期发行的西湖卡和浙江民泰商业银行。

银行卡号检测正确之后，就从10位开始遍历卡bin表，依次递减至6位，直到找到唯一卡bin为止，并返回该卡bin对应的银行卡信息和所属银行。（目前国内银联卡,因银行众多,特别是村镇银行的存在,BIN长度以6位占绝大部分,另外还存在7、8、9、10等位数卡BIN）。

如果要更严谨，还可以匹配银行卡长度对应得上不。

3）银行管理

银行管理用于维护企业自己系统的标准银行及编码，为什么要加自己内部的标准？

还记得上文说过的不同通道可能有不同的银行编码标准吗？如果我们接了多个通道都有不同标准的银行编码，那么我们要根据我们自己的卡BIN，匹配我们标准的银行编码，再去映射不同的通道编码。

再者当我们没有接入多个通道的时候，不用复杂的路由的时候，哪些银行的储蓄卡、信用卡是否支持签约代扣，也可以放在此处去维护管理，当前端识别到不支持的银行的时候，则直接提示用户换卡即可。

4）签约记录

签约记录，方便运营/客服人员核实某个用户某张卡的签约状态，以应对用户的进件咨询和对外合作。

签约数据结构大家可以根据实际场景来设计，一种是卡号+商户、一种是用户+卡号+商户。两者灵活度不一样，举个场景，一个车队老板名下挂靠了很多太车，分别不同司机在管理，但是都用老板或者公司的账户签约代扣ETC通行费，如果某台车离职了，如果签约结构是卡号+商户，那把离职的司机的签约关系解绑了，那老板名下所有签约关系都解绑了。

然后关于签约数据，建议一开始就让开发大哥们维护一份独立的、统一的通道签约数据层，用于记录卡/账户信息在不同通道上的签约或者验证结果，以便路由层及其他业务场景可以据此来进行重新签约或者支付路由。

如果部维护统一的签约数据，而是业务各自去维护，就会出现一个比较尴尬的现象，以我司举例子，我们有客车和货车业务线，但是同一个用户同一张卡可能同时办理了客车和货车，签约数据如果各自维护，存在先后的签约关系，在通道方旧的签约号就会失效，失效的那一条业务线对应的用户就会扣款失败。

同一张卡的签约策略也是值得考究的，比如通道方是否允许重复签约，重复签约会返回什么样的结果，这些都是要搞清楚的。

然后基于企业自身，重复签约的时候是自己内部走个验证即可，还是重新上送通道方进行签约，这些也都要考虑好。如果通道方没有限制，个人倾向重新上送通道方去做签约，这样可以及时更新已过期的签约号。

有了统一的签约数据的话，同一张卡我甚至可以根据业务需求，在用户不同绑卡场景下判断是否走另外的通道进行签约，为同一张卡增加多一个扣款通道。

5）通道异常应急处理机制

最后再建议大家，可以在前期就考虑规划下异常预警机制，比如某个通道连续签约、扣款失败，就要及时发出通知。

我们可以秉承下列3个原则设定处理机制，在通道出了异常之后快速响应，确保交易正常、规避损失、维护用户体验。

专业：应急规范及角色分工清晰；有序：应急流程清楚简单、为可执行的标准化流程；快速：优先恢复通道交易稳定性，其次定位问题和提出解决方案。

万丈高楼平地起，对于支付而言，支付通道管理是不可或缺的一环，其他第三方底层服务也可沿用该思路进行管理，希望本文能对大家带来帮助。