全文共8840字。 建议先保存再读取。

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

01.什么是支付渠道？ 以运输货物为例。 将一批货物从A点运输到B点，可用的运输方式包括公路运输、海运、铁路运输、航空运输。 对于同一目的地，不同的运输方式，往往有多种不同的水路、铁路、公路可供选择，但过程中所花费的时间、风险和金钱成本是不同的。 1.1 支付通道的概念与交通类似。 支付通道的本质是构建一个信息交换环境，支持交易过程中多方之间信息的传输和验证，从而实现交易资金的流动，最终促进交易的完成。 。

狭义上的支付通道是指交易过程中连接消费者、商户和银行钱包账户的网络通道。 广义上讲，只要能够满足支付需求，将信息和资金成功、安全地转移到相应的接收方，支付路径即使是企业用积分支付、使用虚拟卡、使用虚拟账户等内部资产形式来支付，并连接到这些资产管理系统，我们可以说它已经进入了“内部虚拟支付通道”

1.2 支付渠道分类

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

支持不同卡种渠道：仅支持借记卡渠道、仅支持信用卡渠道、同时支持借记卡渠道；

不同支付交互方式的渠道：扣款前需要签名认证的快捷渠道、可建立预付费授权关系、用于信用卡还款和水电煤缴费的借方渠道、需要跳转的网银渠道到银行页面进行付款。 手机运营商认证通道，通常用于手机话费缴费、流量充值等业务，以及使用微信、支付宝等第三方支付平台输入支付密码或进行指纹识别进行认证的身份认证通道付款时。

交易支持不同发起方渠道：持卡人（用户）发起、商户（平台）发起；

有不同行业限制的渠道：微信扣缴仅限于满足定期扣费先缴费的行业、会员续费、水电煤民生行业、打车、酒店行业、停车场或高速公路无无人缴费的行业；

扣款要素不同的渠道：例如网银需要卡号、密码两个要素，快递需要验证卡号/账号、账户名、身份证号、手机号四个要素；

支付对象渠道不同：如积分支付、银行卡支付、代币支付、虚拟货币支付、银行卡支付等。

1.2.1 按通道用途

通道的目的，顾名思义，就是通道的功能。 说白了就是用来做什么，分为收款、支付、认证、跨境等。

收款渠道：常说付款前先开收据。 收款渠道就是将他人的“资产”支付给自己的渠道。 比如有一家早餐店“扫码支付”收钱立牌，或者是线下超市。 POS机支付、各种公交地铁卡及公交代码。

提现渠道：“出去乱搞总要还的。” 提现渠道可以把自己的钱给别人，比如公司的支付渠道、灵活用工渠道、支付我们工资的银企直连渠道等。

认证通道：认证通道可以想象为连接交易两方的安全通道。 必须经过验证，才能通向支付大门。 常见的有银行卡签名验证； 身份信息认证（四要素等），一些账户实名认证、银行卡绑定等需要； 3D-（3DS），一种在线支付的安全协议； 指纹识别、人脸识别等生物识别技术通过授权人的生物识别特征进行身份验证。

1.2.2 通道支持的对象

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

企业渠道：用于企业账户支付，包括企业网银、企业账户扣费、企业转账等。

私密通道：用于个人账户支付，包括银行卡支付、微信、支付宝等第三方个人账户支付。

1.2.3 按渠道商分类

事实上，支付通道是分层的，下层为上层服务。 不同的角色（按是否有支付牌照、金融资质划分）对应不同的渠道商。

对于普通企业：渠道商为支付宝、微信支付等拥有支付牌照的第三方公司； 各种银行； 或企业内部搭建的虚拟账户支付通道、卡券支付通道、积分支付通道等。

对于第三方支付机构来说：那些拥有支付牌照、能够提供对外支付能力的第三方机构，他们需要的渠道是金融机构的核心系统（银行、网联、云闪付）。

对于银行来说：银行需要的渠道是央行（即中国人民银行）的大小额系统和超级网银系统。 这些渠道也是金融活动的基础。

1.2.4 其他类别

按支付方式分：用户在平台下单后，呼叫收银台，看到各种支付方式，包括银联闪付、支付宝、微信支付、支付宝等。如下图所示，京东PC端收银员拥有京东支付和微信支付两个支付品牌； 以及白条、小金库、微信扫码支付三种支付方式。

按支付场景分：包括线上支付、线下支付、跨境支付等。假设你深夜饿了，通过饿了么订外卖并用支付宝在线支付，或者出去到楼下的实体店吃一顿一碗龙江猪蹄饭，线下刷二维码支付，然后早上起床，像梁朝伟一样去伦敦喂食。 鸽子，如果你想喝一杯咖啡，就需要使用跨境支付。

根据支付担保机制：包括担保交易（拍卖网站上的拍卖交易属于担保交易方式）、中介支付（像电商支付平台，买家支付后会冻结资金，确认后才支付款项）卖方收到货物）、风险控制评估（例如贷款公司对借款人进行风险评估，以确定其还款能力和信用水平）等。

在对支付渠道有了初步了解后，我们假设以下场景。如果您的公司要开展一项涉及在线交易的新业务，需要您负责接入支付，您会如何处理？

1.3 支付渠道结构关系

要深入了解支付渠道，我们还需要了解支付系统中渠道之间的结构关系。 这也容易被很多人混淆，尤其是支付方式、支付渠道、支付品牌、支付产品、支付合作伙伴之间。 关系。

上面已经解释了支付方式、渠道和品牌，但是什么是支付产品呢？ 我们借用一下微信支付的定义。 支付产品实际上是支付机构针对某种支付场景提供的一套供外部使用的“解决方案”。 其最基本、最核心的需求包括“支付通道”和“账户”两项服务，然后可以结合不同的场景封装不同的产品。

1.3.1 支付渠道-支付方式关系

同一种支付方式，除了自己的官方渠道外，往往还会授权其他机构合作封装相应的渠道，因此一种支付方式可以有多个支付渠道可供选择。

1.3.2 支付渠道-支付合作伙伴关系

支付渠道和不同合作伙伴之间是什么关系？ 假设“光企”想通过一票联接入微信支付渠道，则该渠道与各机构的关系如下。

1.3.3 支付渠道-支付账户关系

正如我们在文章开头所说，通道的最终目的是在不同支付账户之间转移资金。 以微信支付渠道为例，可以看到渠道与账户的关系以及资金的划转。

1.3.4 普通商户支付渠道结构关系

作为普通企业，有可能同时接入多种支付方式，因此就会有多种支付渠道。 那么它们之间的整体关系是怎样的呢？

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

再往下，还涉及到支付机构、清算结算机构。

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

02.选择支付渠道

在寻找合适的渠道之前，我们先来看看如何选择。

假设您是一家轻型企业的物流运输部门，您需要购买一辆卡车。 那么你肯定需要关注对应卡车的属性吧？ 车型是普通卡车还是牵引车，总载重量是多少，是燃油车还是新能源车等。

这同样适用于选择频道。 您需要了解渠道具有哪些属性。 这些属性就是我们选择时需要考虑的维度。 这些属性也是后续路由决策所依据的维度。

了解了渠道的属性后，你会对渠道有更直观的认识，进而可以根据需求区域选择自己需要的渠道。

2.1 根据业务和交易场景进行选择

选择哪种渠道，首先要了解业务场景。 不同的商业模式需要不同的支付方式。 例如，传统的线下零售企业可以选择POS机、微信支付宝的主扫描仪、人脸扫描仪等，而在线平台则需要根据不同的平台进行选择。

例如，如果一家企业打算依托微信小程序开发“针对公园等微信员工工作区域的午餐外卖产品”，那么肯定需要选择一个渠道来接入“微信小程序支付”方式，而且不可能选择支付宝。 当产品成熟并且你有足够的能量时，你可以考虑扩展到其他平台或接入其他支付方式。

2.2 多维度指标评价预选渠道

选择合作机构后，您可以通过下表来评估该渠道是否满足公司的业务需求。 如果评估满足需求，就可以开始接入。

2.3 渠道接入流程 2.3.1 参与团队成员及分工

2.3.2 对接准备

第 1 步：明确您的需求

对接之前，首先确定您的功能需求。 例如，我们从事音乐会售票。 用户抢票后不得退款。 如果此时没有退款功能，也不会影响第一期的上线。 另外，如果我们处于租房等租赁场景，我们需要向用户收取押金，但退款往往是有时间限制的。 这时候我们就需要考虑其他的退款方式，比如接入支付渠道。

第二步：澄清接口文档

为了方便用户使用，一般支付公司都会提供各种接口，同样的功能也有多种实现方式。 因此，当我们和对方明确了自己的需求后，对方的开发人员通常比你更熟悉界面的使用和效果，他们可以帮助我们快速找到最优的界面解决方案。

另外，很多合作伙伴的文档可能更新不及时。 您可以与对方确认使用哪个版本的文档。

第三步：研究接口文档

需要弄清楚自己需要哪些接口之后，我们需要看清楚接口字段值是如何传输的，是否需要，响应码是什么。 另外，一定要和对方确认返回的结果是基于代码还是描述。

第四步：输出需求文档

包括接入的背景，列出功能点，以及第一阶段要做的事情。

这里首先强调一下付款和退款的问题。 我们在设计支付状态的时候一定要记得考虑中间状态，避免线上出现问题。

另外，安全对接的准备工作也需要提前沟通清楚，比如是否配置IP地址白名单以及如何配置等； 公钥和私钥签名和验证； 接口加密、解密； 是否需要专用网络、前端堡垒机等。 作为普通企业，如果不接入银行核心系统的话，一般不需要前端堡垒主机。 这个阶段也可以请开发小哥协助评估。

03.渠道管理系统设计

选择好我们要连接的之后，我们需要规划我们的渠道管理模块，避免后续支付业务的扩展，但是最基本的模块却是一团乱，因为很多人都是先在线上快速做，然后再找发现这是一团糟。 到时候，已经太晚了。

在规划渠道管理模块之前，我们先来了解一下渠道管理在整个业务系统中扮演什么角色。

上游系统选择通道后，即可发起相应的支付、退款、支付请求。

然后我们来分析我需要规划哪些功能来进行渠道管理。 管理管理，首先我们要知道有哪些渠道，然后才能进行管理，所以我们肯定需要一个渠道管理列表。

3.1 频道管理列表

这里我们以充值通道为例。 访问频道后，每个频道都有唯一的频道名称和频道代码。 这个很容易理解，就像每个人都有身份证和名字一样。 然后将渠道与支付方式和状态关联起来。 如果没有其他追求，可以使用这个渠道管理。

但是，我们仍然需要为未来打下坚实的基础。 从企业的角度来看，我们是否需要计算企业每次支付所要付出的成本，即渠道费。 这时候我们就需要关联对应的“费用规则”；比如从运维渠道人员的角度来看，渠道的一些商户号码和回调地址有时需要改变，我们是否应该将其配置为更人性化吗？假设我们的财务部门需要知道每笔交易的款项到底到了哪个账户，以便我们可以查看日常的账目？是否需要将“入账账户”与渠道关联起来，以便进行后续的对账更方便（注意这里并没有指明哪个账户是真正的资金流向通道，只是纯粹记录以方便后续核算）。

至于“映射通道编码编码”和“权重”，没有它们也可以。 “权重”主要是为了方便路由到支付渠道。 “映射通道编码编码”的作用就是让运营和后续开发者知道这个“我们定义的通道”对应的是哪一组真实的通道编码。 我来解释一下具体情况。 当我们公司接入某公司同一渠道，但因业务等原因开设多个商户账户时，这些商户账户需要参与路由切换，其背后对应的代码是同一套。 。

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

3.2 渠道成本规则

我们设计通道成本规则是单独配置规则，然后从通道中关联对应的成本规则，这样我们在添加新通道时不需要重复配置相同的成本规则。

遇到银行卡渠道时，不同的银行可能会收取不同的费用，因此您可以根据自己的需求定义特殊的银行配置。 如果特殊银行较多，建议使用导入配置文件的交互形式。

至于渠道费用如何使用，其实就是我们在发起交易和退款的时候，读取对应渠道的费用规则，计算出本次交易的费用，记录在每条支付记录中，我们会进行统计之后。 它可以很容易地被拉动。

3.3 通道参数配置

渠道参数配置一般会涉及到配置比较敏感的内容，比如商户号、请求地址等，记得给专人准备菜单或功能权限。

04.银行卡扣费通道接入实践 4.1 接入背景

为了给客户提供更快更好的支付体验，我们团队决定开发并上线银行卡代扣缴费功能，让用户自动代扣缴费，免去繁琐的操作。

经过与公司领导讨论，决定接入PAF协议支付通道。

4.2 研究接口文档 4.2.1 接口调用流程

通过接口调用过程我们可以看到，对于银行卡扣款通道，需要经过两步签名才能完成支付。

第一步，调用协议签名接口，提出签名请求，并向用户发送短信。 用户输入短信后，调用协议签署短信验证接口，验证验证码并完成签署；

第二步，利用协议签署返回的信息（签名号）扣除协议，同步返回交易状态。

理清流程之后我们继续详细看接口文档

4.2.2 签名流程

1）协议签署接口

即发起协议签署申请。 成功启动后，将向持卡人发送一条短信。

可以看到，在申请该通道的协议时，需要提交一个银行代码，而这个代码是基于该通道的定义的。 看到这里，我们必须思考两个问题。

第一点是，办卡时需要知道该卡是什么类型的银行卡。 下面我给大家介绍一下card bin模块。 第二点是不同的无卡渠道可能有特殊的标准，使用的银行编码标准也不同。 这时候我们就可以回忆起我们的渠道属性和特征，渠道银行代码就会有相应的维护。

这里我再说一点。 通过某些渠道办理信用卡时，需要提交CCV和有效期，但该渠道不需要。 因此，前端签约页面也需要根据不同渠道进行路由。 这也证实了我们的渠道管理和维护是相当重要的。

调用合约应用后，合作伙伴会向持卡人手机发送短信，接口会返回一个号码。

2）短信验证接口

用户输入短信验证码后，界面发送验证码和令牌号，即可完成短信验证。 如果验证通过，则可以成功签订合同并获得相应的协议号。

4.2.3 扣款及退款流程

1）借记接口

获得签约协议号后，您可以根据协议号发起扣款。 我们看一下接口说明。 您需要特别注意交易金额字段。 单位是分。 请务必了解交易金额的单位，以免出错。

另外我们看到还有一个后台通知地址。 当我们发起扣费交易时，我们指定一个交易结果的通知地址。 当交易有结果时，通道方会根据上述地址告诉我们结果。 例如，更严格的渠道方也会要求接入方有结果响应，有一套完整的通知策略。

发起扣款后，我们需要关注扣款是否成功。 可以看到响应消息中已经说明了本次操作成功仅代表请求成功，并不代表交易成功。

因此，这里的关键点是，支付状态必须包括支付的中间状态，并且针对这种支付状态必须有相应的补偿机制，否则很容易出现网上交易事故。 当您发起交易时，在收到渠道方的结果之前，交易将被支付。 等待有回调结果或者主动查询，然后根据结果改变状态。

另外，还要注意单笔交易是否有最低金额限制，最大并发是多少，是否可以多线程。

顺便提一下，最好建议开发者在封装支付和退款接口时，尽量封装成业务层统一的订单接口和回调接口，即使是连接很多不同的渠道。 避免很多麻烦。

而且一定要让前端后端小伙伴们记得做好防抖！

2）退款接口

还可以看到退款，金额以分为单位，还需要添加退款状态，和扣款是一样的，就不详细说了。

这种退款是按原路线退回，渠道方会做验证。 一般来说，一次付款不太可能退更多的钱。 不过，您需要考虑退款期限是多长（有些合作伙伴限制半年或一年后交易）。 不退款）、是否可以部分退款、退款次数是否有限制、同一笔款项是否可以同时发起两次退款。

4.2.4 响应码

一般来说，响应码包括公共响应码和不同接口对应的业务响应码。 建议前期整理一些常见的响应码，并将其“翻译”成用户可以阅读的文本进行显示。 并且您可以在错误提示前添加渠道方的英文，方便定位是否是我们的系统报错或者是哪个渠道方报错。

例如我们公司定义为DM，某渠道方定义为PAF，那么错误内容会显示为PAF:，您可以快速定位渠道方报出的错误。

4.3 功能规划 4.3.1 客户签约

考虑到用户体验问题，用户在签订合同时最好不要输入卡号并选择所属银行。 因此，我们需要接入银行卡OCR功能，并且OCR识别的卡号需要与银行卡所属银行以及银行卡类型进行匹配，这样才能发送银行卡代码和卡类型根据渠道方的要求。 这时，card bin模块就派上用场了。

具体客户交互可以参考支付宝、微信等主流产品。

另外，建议保留允许用户手动选择更改银行卡所属银行的功能，避免卡号识别错误而无法签订合同。

4.3.2 卡仓管理

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

国内卡表信息如下所示。 一般情况下可以从渠道获取。

经过数据清洗，提取出我们需要的信息，银行卡中心的卡BIN管理就出来了。 更专业的公司甚至会配置卡BIN图标，并对通道和卡BIN进行匹配和维护，以实现对通道支持的能力的更精细化管理。

一旦我们有了卡的BIN，我们就可以根据用户输入的银行卡号来匹配该卡所属的银行。

匹配逻辑可以如下：

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

1、从银行卡号的最后一位开始，将每个数字逆序乘以它的位数。

2. 将这些乘积相加得到总和。

3. 将总和除以模（10）并取余，得到校验码。

4、如果校验码与银行卡号最后一位相同，则该银行卡号有效，否则该银行卡号无效。

以中国银行卡为例，Luha算法的模为10，校验码为银行卡号的最后一位。

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

````

定义（）：

= 列表(地图(int, str()))

(len()-2, -1, -2) 中的fori：

[我]