支付业务，无论是收款、付款、退款、转账、充值、提现等，都离不开支付核心，支付核心是安排处理不同支付方式全局支付流程的核心系统全文将从支付架构、支付全局流程、收银台、前置路由、后置路由、退款业务、支付单据关系、支付网关模型、支付通道管理、通道等十几个方面，全方位分析支付核心的设计方法文中个别模块会涉及到支付核心相关的原型或者视频解读，会让大家对支付系统的理解更加透彻在支付核心分模块不断展开的同时，我想需要先把整个架构拿出来唠一唠，先通过全局分析略知一二，然后再去从微观上把他拆解透彻将整个支付体系进行抽象和总结，绘制成下图，在这个框架上可以基于本公司的业务规模、支付诉求、产研能力做增减和调整
完美是不重要的，重要的是不完美的第一步，那个最基础的内核和框架，它是迎合市场和内部需求，走向成功的内核
整个支付结构由5层组成，终端属于业务层，不考虑在内，而支付是向各终端提供支付多样化的服务，帮助业务完成收付诉求
没有任何一家企业或者机构可以不依赖外部的支付服务，就可以独自完成一个支付体系的建设，所以至少要接入一家支付服务商如果只是一家刚起步的Toc电商APP，那么接一个微信APP支付、支付宝APP支付就足够用了，因此也就是2个渠道，2款支付产品，2组支付接口
但是，随着业务的不断扩大，支付场景越来越多，为了提升用户支付体验势必要接入更多的支付渠道和产品，满足用户多样化的支付诉求，比如消费分期那么，可以将支付渠道层抽象出支付渠道维度和支付产品维度，总结成一句话就是“接谁的什么产品”因此，将支付产品的共性抽象出来，可以更好地管理支付渠道层比如可以按照收付类型抽象，抽象出收款产品、付款产品；可以按照终端类型抽象，比如抽象出App支付、小程序支付、网站支付等；可以按照支付额的大小进行抽象，比如大额支付、小额支付；也可以按照支付对象的类型进行抽象，比如对公支付、对私支付等等
这样做的目的，就是看清楚渠道的画像，让渠道和产品选择更加合理和高效，避免过多的重复接入同等能力的支付产品
网关是支付核心与外部渠道通讯的关卡，也是外部多样化支付产品和接口向内部第一次统一的一层
你不能指望支付核心去适应每一个渠道的不同，比如微信APP支付、支付宝APP支付、云闪付APP支付，渠道侧虽然是3套接口，但是对内完全可以抽象出APP支付一套接口，所以这是做了第一次统一
支付网关还承载着支付安全、支付通讯、协议转化和处理等一系列的能力
支付核心是支付业务的核心处理层，也是基于渠道支付能力包装出内部支付业务的核心所在
我们将支付核心分化出三大主要部分：支付核心、风控子系统、路由子系统，当然了，后2部分完全可以独立出去，将处理链接的服务留在支付核心内
第1部分是接入处理的核心流程，处理来自上游系统的支付请求，进行一系列的支付校验、参数补全、风控调用等，并将支付请求转换成最终的支付指令提交给网关完成最终的支付，以及结果回调通知业务方第2部分是支付核心的服务集群，包括支付处理、支付单处理、支付结果处理、外部服务调用模块、收银台服务、支付协议管理、支付营销、基础服务等综合支付服务的构建支付核心的大部分能力和逻辑是不可视化的，是服务化的，比如支付单的创建，支付数据的补全，要补哪些数据，从哪里获得；支付参数的校验，校验哪些，检验不通过怎么处理等等
之所以将这部分从支付核心分化出来，是因为这一部分是对外的，是支付核心支付能力产品化提供给外部的体验
比如，收款、付款、退款、代扣、分期、绑卡、合单支付等等
支付的接入层最被熟知的就是收银台，是用户可视化的部分，也是支付的最直接入口当然，还有一个接入模式就是支付API，直接将支付能力以API的形式提供给其他业务系统调用，比如资金调拨系统对于收银台来说，最主要的就是支付方式种类的抽象，每一个支付方式背后都有一组支付通道的支持，例如微信支付，背后可能有直联微信的通道、间联微信的通道，间联通道可能来自多家提供商而，从收银台的一个支付方式发起支付，到最终从多个支付通道挑选出一个完成支付，这中间其实就是“支付核心”的使命所在每一种支付方式都有一个相同流程和个性化流程，那么支付核心就是通过相同的支付主流程完成多种个性化支付子流程的融合，形成多个支付核心流程同样，其他收款流程类似，但微信APP、H5支付有稍微的区别；付款流程也是如此，每个通道大体相同，但有稍微的区别，这是支付核心每一个支付流程抽象的依据
将每一类支付流程，分成“主流程”“子流程”“环节”三部分
可以说，每一个支付场景，都有一个独立的支付流程，而支付系统就是总工程师，控制这些流程的全链条和链条是环节链
每一个字都代表了一个大的业务，依赖某一款产品去实现各业务终端通过收银台或者开放API接入支付核心，发起支付业务请求，通过支付核心完成自己的支付业务
支付核心主要由支付处理核心、支付风控、支付路由、支付网关等4个核心部分组成当然整个支付业务的实现也离不开其他层的支持，如交易核心、清结算、账务核心、以及用户中心、商品中心、合同中心等
在这样的框架下，支付的核心处理流程是什么样的呢？我们通过3张图可以展开这部分的分析
站在全局的视角看支付流程，了解清楚从用户挑选商品开始，到最后支付完成，不同系统层之间是如何协调完成的，看下面第1张图
横向看，代表支付的进程，包含了交易处理环节、收银台处理环节、支付处理环节、支付应答环节；该4大环节分别解决了交易单的生成、收银台的封装和展示、请求支付渠道完成支付、支付后的各方应答反馈纵向看，是支付在多层之间的协同交互，主要是客户端、交易核心、支付核心以及外部支付渠道侧的业务处理，这里我们弱化了与其他如账务核心的交互
用户支付的前提是要买东西，因此需要先选择自己需要的商品，并且生成对应的订单以后，才能进入到支付环节这时候需要计算出本单相关的费用，例如优惠券的使用、总优惠券金额、本单应付金额等信息用户提交订单以后在交易核心生成交易单据，并完成卡券的冻结、订单的创建、账单的创建，如此完成了整个业务层交易类单据的生成交易层业务处理完成以后，接下来就开始进入支付阶段的，支付的起点是收银台有了完整的业务单据信息以后就可以请求支付核心获得本笔交易的收银台的模版，然后反馈客户端，跳转到收银台页面，进入到支付流程中我们在收银台模版一文详细介绍了在客户端是如何获得可用收银台的，这里就不再详述了
到了收银台页面，展示了本单支持的支付方式，用户选择对应的支付方式，例如微信支付，就正式进入了支付处理阶段不同的终端类型、如网站、H5、APP等，就有不同的支付流程，比如在网站进行支付，就无法跳转到支付应用中，但可以跳转到银行网银或者扫码支付
但整体来看整个支付流程应该分成三大部分的流程，客户端的流程、支付核心的流程、与渠道的交互流程不同的终端形成了不同的终端支付流程，是展示收款码还是跳转到网上银行，支付成功后落地页是什么
是针对“终端+支付方式”所形成的支付业务处理，如APP里的微信支付、网站的快捷支付、H5内的快捷支付等，都有相似的“主流程”和“差异化的分支流程”
但是支付核心的主流程如上图所示，不管什么支付方式都包含了参数的交易、交易信息补全、风控与路由处理、支付单的生成及渠道请求报文的封装、提交渠道等相同的环节
不同的支付方式就决定了如何与渠道进行交互，有的渠道可能需要预下单、有的渠道可能就不需要、在预下单以后渠道就会返回不同的“支付标识”，如token、url等，这是支付下一步的关键参数第一次预下单交互，调用预下单接口，渠道返回了预付单标识
通过JSAPI下单接口获取到发起支付的必要参数prepay_id，如上图，然后使用微信支付提供的前端JS方法调用公众号支付，在请求参数中使用prepay_id，封装到package参数中支付发起以后，等待支付渠道的结果通知，在发起支付请求时我们预留了“通知地址”，渠道会将支付结果告知该地址支付成功了要告诉用户，如果支付是跳转到了渠道的收银台，那么用户在渠道的支付应用内已经知道了支付成功的结果
只不过，用户调回商家应用以后会到达商户应用的支付成功通知页面至此，客户端的支付流程就全部结束了，但是整个支付还没有结束，支付系统还要进行各方通知
支付核心需要将支付结果告知交易系统，毕竟人家是业务方，支付成功后还要进行订单履约等一系列后续动作
交易接收到支付成功的通知以后，会更新交易单、订单、账单等的单据状态为成功
卡券的处理一般是下单成功以后进行冻结，支付成功以后进行核销，也就是如上图中券状态变成已使用或者已核销
因为有些渠道需要计算累加交易，以进行交易的分流，就是每个渠道都提供的交易，不能0交易
此时路由就需要记录每个通道的累计交易情况，以便后续进行通道筛选时使用
当然，支付成功以后记账是少不了的，这一点就不过多描述了上面我们介绍了全局视角的支付流程，当然还能进行细化，比如每一个支付方式的具体支付流程在第1张图中进行展开细化
了解了全局流程以后，应该支付支付请求到了支付核心以后的处理流程是什么样的
这里要清楚，每一个支付方式，路由筛选出了不同的通道，都会形成一个独特的支付处理流程，快捷支付、网银支付；A支付机构的快捷支付、B支付机构的快捷支付等所形成的支付核心的处理流程是存在差异的当然，要想把控好每一个支付方式在每一个通道的处理流程，首先要先把握“主线流程”
主线流程不会因为支付方式的不同，选择的渠道不同而不同真正不同的是渠道的差异化造成的，所以我们把支付核心主流程抽象出11个环节，这就是第2张图
可以根据实际的业务需要，对该图的环节进行增加或者删减，但大同小异
上图的11个环节可以再次划分成客户端支付请求处理、支付核心请求报文处理、请求渠道发起支付、支付应答处理等4个阶段客户端或者内部业务系统按照支付接入接口要求传入支付请求，需要进行一系列的校验和信息补全处理
如上图所示，应该判断该请求是否有当前支付业务的请求权限，并校验请求参数是否合法，比如必填参数是否正确、参数格式是否正确、枚举类参数的枚举是否正确等
然后对交易信息进行补全，比如增加交易状态、其他一些交易信息补充，为后续的请求路由系统以及生成支付单做准备交易信息完整以后，接下来就是请求路由获取可用支付通道
通过路由系统返回的通道编号，补全渠道信息，例如该渠道的商户号信息、通讯协议信息、以及一些其他差异化数据
支付单生成以后，并且补全了渠道需要的参数以后，就开始准备向渠道发起支付申请了按照渠道的协议要求，封装协议参数，进行加密、签名，封装成渠道要求的报文格式并且，通知支付单模块、路由系统、记账系统等内部系统更新状态以及下一步业务的预处理将支付报文提交给渠道以后，就等着渠道返回支付结果了接收到支付结果以后，更新支付单相关状态，并通知交易系统、业务请求系统、账务系统等内部系统进行支付成功后的业务处理
以上的主流程，可以在每一个支付方式上进行差异化调整，细化
可能第一次用户取消了，要重新发起支付，或者第一次失败了，系统要再次发起支付而不同渠道对于重复请求，对单号有不同的要求，有的可能需要取消原单，以新单发起支付，以避免重复支付或者付款，有的可能没有这个要求，需要使用原单号发起支付这一点要跟退款重新发起区别开，渠道对重新发起退款的要求是使用原单号进行退款，不需要更换退款单号，这一点与重新发起支付请求有区别
考虑到支付的重新发起情况，我们可以将支付单的结构设置成两层结构，由支付单和支付流水组成，一笔支付单对应对比支付流水
支付单与业务请求一一对应，支付单与支付流水一对多，支付流水与渠道请求一一对应
这样的机构下会产生至少3个单号，业务订单号、支付单号、支付请求号（支付流水号），形成的表结构和对应关系如下图所示
以上就是支付核心的全部支付流程分析，具体的支付方式的差异化流程，大家可以自主研究
在上述的框架上，具体的支付方式的流程相对比较简单，就不再展开了收银台，从字面意思“收银台=收+银+台”，顾名思义就是收取银子的台子在古代你去饭馆吃饭喝酒吃肉，酒足饭饱后到柜台掏出50两的大元宝拍在了“收银台”上：老板结账，不用找了；最原始的收银台就是那个柜台，柜台的特点就是结账的场所，你把钱放上去，有专门的人员核实账款与商品，无误以后，交易就完成了。结账场所最核心应该具备的内容应该包括以下点这些信息构成收银台应该具备的基本元素以及职能，而且这些职能是在实际执行过程中逐渐形成并固定下来。对于电子支付收银台的设计具有参考意义。近代在电子支付出现之前，我们去超市购买商品，挑好货品后拿到结账处进行清点，工作人员告诉你“一共10斤粮票” ，你掏出纸质的票子完成了付款，商品就是你的了；此时的工作人员叫收银员，他面前的台子就是收银台；这里收银台就是商品和现金的交换场所。形式跟传统收银台没有本质差别，但在技术和管理能力上有了很大的提升——货币形式变了，有了专业的收银人员，交易场所更加规模化，商品管理也更加标准化。电子支付出现以后，出现了新的货币形式“账户货币”支付方式产生了电子支付方式，从而产生了线上的支付场所——电子支付收银台；一个可以在线上通过各种电子支付手段完成账户货币转移的支付收银台形式硬件收银台：pos机，mpos机等硬件设备，支付卡牌等移动端收银台：填写订单、选择支付方式、支付流程、支付结果收银台，是支付的起点，所以无论是何种企业或者支付组织，收银台都是支付架构的最前位置，支付从“收银台”开始收银台是支付的起点，是交易环节和支付环节的衔接点，用户在交易环节完成了商品的选购以及订单的填写、合同签约以后，下一步就要进入支付环节完成支付，而支付的起点就是收银台。用户在收银台选择合适的支付方式进行支付收银台不只是用户看到的收银台页面那么简单，其除了在不同场所页面元素以及交互方式不同以外，与后台的数据交互以及子系统的划分也会存在差别例如普通的商户和三方支付机构对收银台的设计思路会存在差别，这些差别这些差别可以从不同角度去分析，例如分析不同组织之间的收银台差别、同一个组织的收银台的前后端的差别商户侧的收银台分：前台/后台，前台面向用户，后台面向渠道支付公司的收银台：前台对应商户或者直接面对用户，后台面向渠道收银台前台：面向用户的可视化收银台页面主要是提供给用户完成支付方式选择和支付请求的发起收银台后台：主要是调用后端获取支付参数和支付通道，请求通道发起支付请求产品的一切目的都是以价值为导向，无论是用户价值还是企业价值，否则就失去的产品的方向和意义对收银台来说，我们如何定义其好坏，考量其“好坏”，所以需要建立几个核心指标用以考核收银台好不好用，用户用地爽不爽，界面舒服，操作流畅，支付方式丰富最短的时间完成支付，简单的加载5s内可以反馈支付结果支付成功率越高意味着用户体验越好，同时也是支付转化率中最核心的一部分平台交易在“支付环节”的转化率高低，是整个交易转化率的一部分在设计收银台之前要先做好下面几个方面的准备，才能确保设计的产品相对完整，能够达到预期的用户体验，完成相关的支付指标。做任何产品的前提就是先了解业务是怎么样的；例如售卖的是什么商品，业务模式是电商、游戏、课程售卖还是会员充值等等，其实就是搞清楚卖什么，怎么卖的问题；我们假设是电商平台，卖的是实物商品。想好要为用户提供什么支付方式，比如微信支付，支付宝支付，银行卡快捷支付，账户余额支付？一般场景中，选择微信支付宝就够了，但也难免有用户想直接绑定信用卡去支付，虽然通过微信支付宝也可以使用信用卡支付；这个要看平台的选择，如果有能力实现就尽可能给用户更多的选择，满足更多的用户需求，覆盖更多的支付场景。完成了（2）的分析，基本就可以确定要签约什么支付产品，也就知道该如何去设计收银台了。假设签约了微信支付，易宝的快捷支付，自建钱包；就可以拿到微信的文档，易宝支付的文档，钱包账户自己来设计；拿到文档后就知道了支付需要的参数，就能确定我们请求通道时需要哪些参数，哪些参数是用户提供的，哪些参数需要后台整理封装，当前系统是不是可以提供需要的参数，还需要做哪些改造。分析清楚要完成支付至少需要哪些支撑系统，收银台还需要内线的订单账单、账务等，外线就需要收银台后台、路由、风控（非必须）、支付处理、渠道管理等。收银台包含前端和后端，前端是用户可以看到的收银台页面，在订单填写页提交订单以后到达。对于前端页面比较容易调研，因为直面用户，所以到任何一个平台操作一下下单和支付就可以到达相应的收银台，看到收银台展示的内容元素以及交互收银台随着业务的变化在不断发生变化，在更多的端上建设收银台，收银台支持更多的支付方式，相应也会出现支付方式推荐、支付补贴露出、活动优惠推送等更多内容。同样收银台类型的拓展：逐渐发展出PC收银台，H5收银台，app收银台等更多的收银台形态。支付方式的拓展：除了微信支付、绑卡支付、余额支付等方式以外，逐渐发展出数字人民币支付，线下支付等支持更多支付场景的支付方式。银行卡快捷支付可以选择已经绑定的卡，也可以添加新卡；新卡的绑定一般按照绑卡鉴权的要求既可以设计出需要的要素，借记卡和贷记卡的要素不一样；个人户和对公户也不一样；随着电子支付的发展，方式也会变化，跟着接入方的要求走即可。既然是自己包装或者接入的钱包余额，算是一个新的支付方式，一个新的支付方式需要关注以下几个要素支付方式名称：起个名字，比如抖音支付，余额支付，钱包支付等支付发起流程：选择这个支付方式以后，提交支付后的业务流程如何。收银台的设计离不开企业业务特点，而企业的业务特点又离不开交易场景，我们看下常见的支付场景有哪些，这些场景对收银台的诉求对于常见的支付方式选择，可以结合上面所述的支付场景，然后通过以下几个维度进行分析对于主流支付方式，目前国内成熟市场下，主要还是微信和支付宝以及银行卡这三种支付方式，大部分可以满足消费需求，但也有基于其他目的比如降低费率、覆盖低收入人群等等，可以选择外漏支付宝花呗等消费贷支付产品另外还要考虑的问题就是对用户的覆盖、支付体验、支付限额、用户类型等维度，以下是主要几个支付方式的维度分析余额支付的最大特点就是“组织内闭环”，可以不依赖外界渠道，直接在内部完成账务处理好处就是可以有更好的支付体验和额度控制，劣势就是依赖前置的账户充值，依然依赖外界支付余额支付的核心是：为支付系统模拟出一条“余额支付”通道常见的代扣场景有2个，一个是自动周期性扣费，如自动会员续费；另一个是先服务后支付，如乘车码，我们以微信代扣支付为例从协议中看代扣，有几个关键描述点：从哪里扣钱、代扣前的通知、订阅周期我们串起来看一下腾讯视频会员在苹果内签约的自动续费的扣款路径，以及扣款账单先服务后扣款的常见场景是打车以及乘坐地铁的乘车码，如我用滴滴打车，结束后微信自动支付成功，看下图微信内的支付通知和账单信息微信代扣产品叫“微信支付扣款服务（原委托代扣）”，是为微信支付为商户和用户提供的，可以在交易场景之外完成支付的能力，主要服务于三个场景免密支付：可以实现对存在签约协议的用户进行小额立即扣款的功能，扣费时间无延迟，无扣费前通知，商户只需调用【申请扣款】接口发起扣款即可自动续费：扣费时间有延迟，需有扣费前通知，具体参看【 周期扣费】说明文档，目前支持通知后【24小时自动扣费】或【预扣费通知】两种模式，商户只能选择申请其中一种模式实现扣费，一般申请后为【24小时自动扣费】模式，如需使用另种模式，请联系对接您的运营同学协助申请修改模式授权扣款：可以实现对存在签约协议的用户进行大额立即扣款的功能，扣费时间无延迟，无扣费前通知，商户只需调用【申请扣款】接口发起扣款即可小额免密支付是在零售小额场景下，一定金额以下的小额支付时，无需用户进行支付密码确认，商户直接发起扣款指令完成扣款的支付方式接入外部消费分期产品方式，以接入花呗为例，至于独立设计消费分期属于信贷范畴，体系庞大，后续会出单独的内容体系，这里站在大多数普通企业视角做分期支付场景花呗分期是蚂蚁集团推出的消费金融产品，用户在商家端网站或线下门店购物时使用花呗分期支付，订单全额实时支付到商家支付宝账户中，用户分期偿还花呗收银台的个性化展示：我们可以从以下几个方面去分析，当然还有很多种其他原因，归根结底都是因为多样化业务诉求的产生随着平台的发展，为了迎合更多场景及用户，会签约更多的支付渠道，从微信支付宝，到银行卡支付，苹果支付，再到银联闪付，数字人民币支付，余额支付等等，多样化的支付方式就必然对收银台的展示策略提出了更高的要求有了丰富的支付渠道之后，其实业务多样化同样也会影响支付方式的展示，比如有些渠道拒绝某些品类的支付请求，所以如果用户选择了这种品类下的商品，那收银台就不应该展示不接收该类商品交易的渠道支付方式随着商户数量的增加，种类的增加，合作模式的增加，对支付渠道的要求，甚至是收银台的要求也会相应增加，比如有些ka大商户因为跟某些渠道有合作，可能就会要求仅支持某几类支付方式，这样就需要根据大商户的特殊要求设定支付方式平台本身也会有营销等各种诉求，AB实验的诉求等，也会对收银台的个性化提出要求，比如某些用户优先推荐微信支付，某些已经绑了银行卡的用户优先推荐银行卡支付等有些渠道可能会提供一些合作模式，比如你把我放在第一位我就给你降费率，或者更有甚者，你把竞品折叠，我再给你降一些费率，而这种合作模式又可能不是全量用户，比如你要将50%的交易采用这种收银台模式用户体量足够大时，你就不得不考虑更好的用户习惯和体验的诉求，比如有些用户每次购物都是用微信支付，那么下次支付你要是推荐了支付宝而折叠了微信，那必然会让用户多操作几次去找到自己想要的支付方式；而如果有些用户上次使用了银行卡支付，那么下次推荐上次用的卡可能是一个不错的选择有些银行渠道可能会提供一些支付补贴，这也会成为支付方式个性化的需求来源，但是这种营销又可能不是全量用户，所以这里又需要策略问题所以说，收银台个性化展示的目的有时为了更高的成功率，有时为了提高用户体验，为了给某一个支付渠道引流等不同的诉求，但最终实现的业务效果就是不同的人可能看到的收银台页面的支付方式的种类和顺序会有差别在购物支付时，你有没有发现，这次的收银台提供的支付方式和上一次不一样了
想了想，可能是自己换手机了，上次用的安卓手机，这次换苹果手机了，收银台多了一个苹果支付同样，在我们进行超大额支付时，收银台所提供的支付方式也不一样了，这一点容易理解，毕竟有些支付方式本身能支持的限额就非常小所以，一个平台是怎么实现收银台支付方式组合的多样化呢？为什么同一个平台，支付场景不同，看到的收银台不一样呢？主要有以下几个原因就如微信支付分app支付、H5支付、小程序支付等等，所以不同的终端类型，单单微信支付就如此多样，所以难免在不同的发展阶段，不同终端能做到的支付方式也是有差异的在H5应用里为了快速上架商用，可能初期就仅支持支付宝一种支付方式，微信支付、绑卡支付等其他支付方式稍微再接入
这样的安排，就会造成App内的收银台和H5内的收银台支持的支付方式不一样，如下图京东的pc端收银台仅支持银行卡和微信支付，相比其App端，少了很多支付方式
如果平台就2个终端，总共也就微信、支付宝、银行卡三种支付方式，那么收银台的展示完全可以在终端通过代码逻辑实现举个例子，有些企业存在多条业务线，独立公司、独立团队运作，那么开通的收款商户号复杂多样，有的业务线可能压根就没有支付宝收款账号，那么收银台里怎么会有支付宝收款方式呢？
比如我们原来新上线了一款服务品类“做饭保姆”，做为早期的验证阶段，为了尽快上架，仅开通了微信支收款商户号，没有开通支付宝，那么针对做饭保姆这个品类用户就支付用微信进行支付了就比如开头的京东收银台，进行分次付款时，微信支付和数字人民币就不支持了
这就是不同的支付能力造成了支付方式不同，也可以认为是不同的支付场景造成了支付方式的不同
比如跟某些渠道达成合作，将50%的交易，让其放在收银台支付列表的第一位，会提供一定的手续费优惠，这种情况下，收银台策略发生了变化，不同的用户，或者同一个用户不同的支付，收银台支付方式排序不一样了
还有一些其他原因也会造成收银台可用支付方式不同，比如支付限额，当超大额支付时，明确超过了某些支付方式的限额时，那么就应该屏蔽或者置灰该支付方式，避免在后续过程中支付失败我们前面介绍的支付方式是用户侧在支付时，收银台能看到的，常见的支付方式有微信支付、支付宝支付、云闪付、银行卡支付等等
用户能看到什么是由“前置路由”决定的，也就是我们本文重点介绍的，它决定了收银台的内容还有一个路由是后置路由，也就是当用户选择了“微信支付”，并提交支付以后，后端如何决策这笔支付应该提交给谁
你可能会说，用户不是已经选择了微信支付么，肯定提交给微信侧啊提交给微信没问题，但问题是，仅仅是微信么，或者只能是微信么？
别忘了有很多三方机构或者聚合支付支持微信支付这种方式，也就是我们可以通过多渠道实现“微信支付”
那这个时候，你就要想了，我怎么选择提交给那个微信支付？它为每一笔支付选择最优的支付渠道，这部分我们在路由相关文章里有非常详细的介绍
前置路由决定用户看见什么，渠道路由决定支付提交给谁进行处理当然，用户看到什么样的收银台，完全可以靠代码把逻辑写出来，比如判断什么终端、什么品类，展示什么支付方式组合
但是，随着公司的发展，业务越来越复杂，终端种类越来越多，支持的支付方式越来越多，收银台支付方式组合的逻辑更加复杂因为，你不能频繁去调整非常重要的支付入口收银台的展示，不能因为一个小的策略变动，就把收银台代码改一遍，这肯定需要变革将平台支持的支付方式抽象出来，比如经过分析，共接入了下列的支付方式这些支付方式由于开头的那些原因需要进行不同的组合和排序每一种组合和排序都可以认为是一个收银台模版，而支付场景我们可以认为就是一组条件，有的是可以抽象和固化配置的条件，有的可能是需要逻辑和策略实现的条件上图中每一条就是一个收银台模版，其配置决定了本次命中支持的支付方式，支付方式的排序等内容
应用不同支付方式不同，业务线不同、品类不同、交易类型不同支付方式也可以不同，我们甚至可以为某一个具体的用户或者商家提供个性化的支付方式组合
根据新的策略去配置新的模版，让收银台的丰富性变得更加灵活从配置中可以看出，我们可以进行更加多样化的策略配置，可以配置支付方式的可用性，可以配置不同的排序，可以配置支付方式的推荐等等
整个交易、支付、清结算、账务体系柔和到一起，会产生很多的单据、单号，他们之间存在着错综复杂的关系如果再把正向、逆向考虑进来，他们之间的关系就更加复杂了下面我们就把订单、账单、支付记录、支付单、支付请求、卡消费记录、券核销记录等单据，他们在交易正、逆向中是如何联系的，又有怎么样的数据关系
我们先设定个场景，比如在某平台购买了一次做饭保姆服务，总价是120元，并且分2次支付，“先预付80元，再后付40元”，预付时用了一张20元的优惠券，微信支付了60元以上场景的发生并不是依赖一个系统实现，而是通过3个核心实现，分别是交易核心、支付核心、卡券营销核心，每个核心内会产生相应的单据
交易核心安排交易流程，包含了订单子系统和账单子系统其中订单子系统内会生成订单，订单记录了平台跟用户的本次交易信息，买了什么商品、一共多少钱、用户要用什么支付等账单子系统会产生账单，账单记录了订单要如何结算的信息，为后面的支付、卡券核销等做准备，案例中会产生2笔账单，预付账单和后付账单一笔账单需要被用户支付（结算），而账单中的支付方式是广义的支付方式，包括卡、券、满减、积分以及渠道支付等，如案例中的预付账单优惠了20元，渠道支付了60，假设用户选择了微信支付，则账单的支付记录如下因此在交易核心有3个单据，分别是订单、账单、账单支付记录，他们之间是一对多对多的关系，如下所示券系统内记录的用户的券绑定信息、冻结及核销记录；卡系统记录了用户卡余额的消耗记录、卡余额退回记录
而卡券的变动记录依赖交易核心的推动，交易核心如何推动卡券建立联系呢？靠的就是账单支付记录单据
案例中因为用了一张20元的券，所以券系统核销了该券，我们假设有一笔核销记录上述案例中有60元走微信支付，也就是请求外部支付渠道完成支付，这部分支付走的就是支付核心
而在支付核心会产生2类单据，一类是正向支付的支付单和支付请求明细；第二类是退款单和退款请求明细而一笔支付可能会请求渠道多次，因此我们还会建立一个支付请求的明细上述就是本案例支付在3个核心内产生的全部单据，那么他们之间形成了如下的关系上面讲清楚了正向所形成的单据，以及单据之间的关系；那么再考虑逆向订单退款就容易多了因为逆向是正向的反方向，所以涉及到的依然是3个核心，依然是上述的单据维度，只不过单据变成了逆向单，即订单变成了退单，账单变成了退款账单、账单支付记录变成了账单退款记录、支付单变成了退款单等
如下图所示，这是直播过程中直接的板书，这里的关系看得更加直观一些，上面的用表结构标识，这里就直接可视化了，更能看出单据之间的关系
没有正向的单据就不会有逆向的单据，比如用户没有下单，就不会取消订单、也不会操作订单退回，支付也是如此，没有原来的支付成功，就不会有退款
支付核心的退款，必然是支付单，不能摆脱原支付单的控制，退款可以全部退、部分退或者分多次退，但都不会超过原支付金额订单是逆向的起点，就是只有业务产生了逆向处理，比如退了部分商品、或者订单差评产生了部分退回等，才会产生支付的逆向因此，退款不一定有订单逆向，也可能是订单产生的差评罚款或者其他原因，但不管怎样，都是基于订单，所以说，退款基于订单发起订单产生了逆向，因为订单用了卡、券、积分、微信支付等多种支付方式
那么逆向发生以后，先处理谁，先退券还是先退积分，还是先退微信支付的金额如果是全额退还好说，毕竟最终都会逆向处理，但是部分退呢？支付了80，用了20元的券，微信支付了60，现在要退40，怎么退？是退20的券微信退20，还是微信退40？
因此需要一个逆向顺序的控制，如案例中，我们设置了这样的顺序，以及设置了券不返还的策略
这样的规则下，如果预付单只退50元，那么看预付单的情况
按照“券>卡>渠道”的退款顺序逆向的话，先处理20元的券，因为券不返还，所以就只是将券变成以取消即可，这样就会从营销成本中核销掉
所以，用户部分退50元，在这样的逆向策略下，只能拿回30元如果文字看起来比较费劲，还理不清单据的关系，那么看以下视频，听我解析各单据之间的关系，总时长11分钟但是退款不是说什么时候想退就能退，不同的渠道不同类型的支付有不同的退款时效
过了退款时效，还能把钱退出去么？或者说，过了退款时效，怎么样才能把钱退回去呢？
渠道的退款时效是渠道开放给商户的权益，而商户和用户的退款协议是另一回事，二者难免存在错配
比如，某平台就是敢承诺，永久可退，那么我想没有任何一个支付渠道可以满足他这个诉求，怎么办？产品经理的神奇魔力就是，交给他，啥事都能给你办，不就是把超退款时效的款退回去么
既然原渠道退不了了，那么......就得整点幺蛾子了
退款的本质就是“把钱给他”，真想退，那就打破原路退的禁锢支付的逆向是退款，而退款也有几种基础的模式，我们先把这个了解清楚
一笔订单的内容构成是多样化的，那么也必然造成一笔退款的构成也是多样化的
订单包含多个商家，多款商品，多种费用，那么退款的花样就多了
从退款的基础能力上来说，一般的渠道会提供以下几种退款模式，我们可以把每一种退款模式当成一种退款产品对于平台来说，又可以基于渠道的基础退款模式，封装出更多场景的退款产品
比如，可以将按商品退封装出一个按“商家退”的模式，将一个订单中的同一个商家的商品打包进行退款，从效果上就是按商家退这种处理手段，就是产品经理在设计上的灵活性；没有出路，也要基于手头的能力创造出新出路钱不一定都在一个篮子里，那退款也就不一定从一个账户往回退退款的本质也不是必须原路退款到指定账户，而是将钱从收款者手里退回付款者手里在渠道签约产品时，往往会开通多个账户，比如基本户、运营账户、手续费账户、营销账户等，都属于该商户而同一个账户也可能有多种资金属性，比如可用余额、冻结余额、待结算余额等
所以，在退款时，有的渠道会提供指定出款账户和资金类型的能力当然，对于一个交易体量很大的平台来说，对这一能力并没有太强的诉求，从原基本户退回足够了前面我们讲了，退款的本质是退给付款的人，而不一定非得是付款的账户
因为付款人在该平台可能有多个收款路径，比如在微信有绑定的银行卡、也有微信零钱，如果原路退回绑定的卡失败，那么微信可以决定退回用户的零钱账户开头介绍了，退款有退款时效，过了这个时效，原支付不再支持通过渠道退回
但是，本身的业务存在这样的超时效退款场景，比如平台的退款协议就是比渠道的退款时效长比如家政行业，有的客户一次签约3年，那么其中的客户服务费就是在三年内可退，当2年半时要退剩下的半年单子，那么服务费就需要退回半年的
这个时候很明显已经过了渠道的退款时效了，但是从业务上来说又必须退款基于退款的本质是退回付款人这一点，我们不难想到——走付款
该退款产品的核心职能就是将超过退款时效的退款申请，转换成付款，将钱付给付款人要想实现这一退款产品能力，还有几件重要的事情要做，毕竟你要打破常规
因为原渠道退回本身就有一个隐藏属性，那就是我们知道用户用哪个账户付的款，渠道就会退回这个已知的账户
但是，付款给用户，难度就大了，因为我们不一定知道用户的收款账户信息将退款业务转换成付款要做的第一件事就是“采集用户的收款账户信息”
如此，就将第一个难题转换成了一个可落地的需求，采集用户收款信息
也可以在用户订单中心增加一个提示：已超原路退款的时效，需要您提交银行卡信息，平台将在3个工作日以内将款项打到该卡中一个真正的产品难题会被一层层的分解，直到找到了答案，产品设计的过程其实就是这样一个过程
那么怎么发起上述的采集动作呢？就是当后台点击“退转付”时，当然这个发起动作可以是人为触发，也可以是系统自动触发
当退款失败的原因是“超过退款时效”同时用户退款协议约定又可退时，自动触发该退款路径当然了，在发起采集时可以先判断平台有没有用户的收款卡信息，如果有的话可以选择合适的付款通道将钱支付出去
该付款单是明确的“退转付”，与原退款单关联，付款类型定义为“退款转付款”
还有非常重要的一个问题需要解决，就是付款与原退款在信息上的强关联，特别是状态的联动
因为退款业务是受到原支付单强制性限制，就是总退款金额不能超过原支付金额，而且，退款付的付款发起的前提是原退款单失败是由于超时效了如果退转付的付款业务不受上述条件的强制约，那么就可能发生资金损失，产生超额退款基于上述的控制链，那么退款状态和付款状态之间应该构建起联动性，退转付的状态去更新原退款失败的退款单的状态，原退款单的状态开始了新的流转最后要说明的是，退转付的付款业务应该归属于“退款”模块，或者说退款业务，而不是付款业务更精确的描述这个能力，我觉得应该是“基于付款能力的退款产品”基于支付通道的属性特点和业务系统的要求，为支付交易筛选出符合业务要求的最优的通道；简单的说就是业务系统要收款，你路由器帮我选一条最好的通道吧！这就是路由的职能，为通道选择做决策
近期我要去三亚看海，找去过的朋友以及在网上了解怎么去比较划算和舒适；一个朋友告诉我，坐飞机比较好，用时短，还能看看天空的云；有的朋友说火车比较好，有足够的时间体验漫长和一路风景人文；还有的朋友说骑自行车比较好，既能锻炼身体又能一路吃遍南北......
当你有一个目的的时候，就会有很多条路放在你的面前，或者说，就算你没有目的，这些路都在哪里，只是等待一个时刻你去选择
而我们选择都是有条件和依据的，比如我要时间最短，比如我要最便宜，比如我要风景最美，比如我要在那个时间段可以......当这些条件都满足以后，我决定我选择从北京骑自行车去三亚，你觉得合理么？
同样路由亦是如此，它是一个帮助你选择的管家，你告诉他你要干嘛，他告诉你走那条路，而这个过程你要提供给他足够的“要求”，比如我要成功率最高的，我要成本最低的，我要最稳定的，我还要......最后他告诉你，这是你要的，去吧......
支付路由就是这样，来了一笔支付请求要提交渠道，走哪条渠道呢？这个时候路由就问你“这笔支付什么特征”，你告诉它，这是工行卡支付的，北京的一位用户，是信用卡，在A商户买了一件衣服......路由开始选择，工行的那招商的通道就不用了，这是工行的所有通道；北京的用户，那河南的这条工行通道就不用了，这是所有北京的工行通道，A商户是vvvvvip指定了2条独家专用通道，而且今天其中一条休假，那就只能这条了......这样，我们就选出来了
路由选择场景有2个，一个是收银台展示那些支付方式的路由，不同的用户，不同的商品组合可能用户要看到不同的支付方式以及排序；另一类是选择那条支付通道去提交用户的支付请求，根据支付的属性去匹配通道的属性，选择最适合该笔支付的请求
如果你善于撮合爱情，那就大概率善于设计路由规则，因为路由就是撮合了支付对通道的爱
7.1路由的架构解析
对一个事物的认识我们先从整体去认识，会有利于需把控其中每一个环节以及细节，更可以让你对它有更强的控制力以及灵活能力；接下来我们从各个整体维度去认识和把握路由系统的设计。这将为今后其他子环节的设计打下基础，例如每个规则的设计，运营后台设计，通道返回码设计，对不同场景下的路由的设计演变等等
既然你要筛选某个群体，那你必然要知道这个群体的画像；路由是对通道的筛选，那么我们就需要知道通道有什么样的属性和特点，都有哪些类型的通道；当然不同的公司基于自己的发展需要可能对通道的分类方法不同，但关键是“你总归有一个属于你的分类方法”
（1）支付类通道
这是我们非常清楚的通道类型，为支付的核心通道，也是支付指令提交的通道，种类和数量最繁多的通道，也是路由的核心筛选对象；对于支付通道我们又可以分出快捷通道、网银通道、代扣通道、垫资通道等等，当然对于一个普通企业来说，也可以按支付品牌去分，比如微信通道、支付宝通道、银行卡支付通道
对用通道我们还要关注其支持的卡类型，谁发起交易，有无行业限制，交易需要的要素等等
（2）鉴权类通道
我们常听说的四要素鉴权，三要素鉴权，五要素鉴权，用户在绑卡支付时需要进行银行的鉴权，来判断卡的有效性；在结算卡绑定时同样需要通过鉴权去判断卡的有效性
为了成功率、备份、成本考虑，一个机构也会接入多个鉴权通道，所以也需要基于鉴权请求路由出最有的鉴权通道
（3）实名类通道
对于一些业务场景需要进行实名认证，比如你要到一个家政平台去做兼职，你需要实名认证签约，就需要上传身份证照片，人脸识别等
同理也会接入多条实名通道，需要进行路由
那么我们常见的用于对通道进行分类或者筛选的通道属性有哪些呢？这些属性有些维护在通道管理，是通道的本身属性，有些是支付信息里是支付单据的内容
交易类型：网银支付，快捷支付，pos支付，聚合支付等等
银行：招商银行，农业银行，北京银行
账户类型：对公账户，对私账户，政府专户，备付金账户等
卡种：借记卡，贷记卡
通道状态：通道是开启状态还是关闭状态
限额：通道有交易限额，不满足交易限额的支付不选择，比如单笔限额2万，2.5万的支付不能选择
签约：如果某条通道需要用户提前签约，则不签约用户发起的支付不选择
银行短验：如果这笔支付不能接收银行下发的短信验证，不选择
最少鉴权项优先：选择需要鉴权的要素数最少的通道
营业时间：有些通道有固定的维护时间，在维护时间内不选择
行业准入：有行业限制的通道不选择，比如某通道不允许借贷还款支付，则不选择
商户白名单：如果通道只允许在名单里的商户的交易使用，则不在名单里的商户的交易不能选择
通道黑名单卡：该卡种如果在某些通道的卡黑名单里，则不能选择
签约通道优先：优先选择需要银行签约的通道
优先级最高优先：通道固有属性，当多条通道可用时，选择其中优先级属性最高的通道
成本最低优先：多条可用时，选择预计算成本最低的通道
三方通道微信优先：如果多条三方通道可用时，优先选择微信通道
在不同的行业，不同的公司，不同的业务模式，接了不同的通道矩阵的情况下，基于实际会设定不同的路由规则，这是个无限的过程，但是我们要掌握基础的方法，那就是“选择的艺术”，如果你懂了选择的逻辑，那么再复杂的事物，你都能选出最佳的哪一个
7.2路由的实现原理
路由的目的是基于交易特征筛选最匹配的通道，所以这里我们就发现了关键
（1）路由三要素
交易特征就是你要知道用户发起的这笔支付的画像，什么类型的支付，用的什么卡，买的什么品类的商品，商户是谁等等
通道就是上面我们讲的他也有他的画像，这个是什么类型的通道，支付还是鉴权，网银还是快捷，有没有行业限制，对公还是对私，成本如何等等
然后就是匹配，通过什么样的匹配模型去将具有一定交易特征的支付匹配到可用的通道上，这也是路由的核心原理所在
（2）要素准备
所以我们要对通道进行管理，维护全部通道的基础属性，就像你去一个婚恋网站去填一些资料一样，身高，体重，学历，有无特殊要求，便于系统帮你匹配最合适的人，也便于匹配到的人对你再次筛选
然后就是路由的规则体系，我们知道匹配的时候关注什么内容，如何去执行这个规则条件；我们的规则可以分两类，一类是分组规则，另一类是筛选规则，并且对每一类规则我们都需要一个模块进行管理，比如成本最优规则，你就需要一个每个通道成本管理的地方去维护计费模式以及费率等，便于去计算本笔支付的通道成本
这样我们就知道了路由的实现原理就是，交易将特征传入路由系统，路由系统针对每项规则去过滤已经维护的全部通道，直到挑选出最合适的那个
7.3路由原理模型
调用系统比如支付网关、业务系统、支付系统等，传入交易特征，路由系统先根据规则树快速定位到可用通道，然后再通过一组筛选规则注意筛选，最终输出一条可用通道给到请求方
7.4路由的规则体系
即使不做路由系统，完全依靠代码实现，但依然需要路由模型和逻辑
那么，路由筛选最优通道就需要一系列的筛选规则，路由规则就成了路由系统的重中之重
我们就来梳理一下，常见的路由规则有哪些，以及这些规则的内容是什么
我们知道，路由筛选是多种类的，不仅仅是筛选收款通道，还有付款通道、鉴权通道、实名通道等等因此，如果一笔请求是付款业务，那么你就完全没必要去判断鉴权通道，否则你将全部通道都做一次判断，那路由的效率损失和性能消耗是非常大的这样的话，在请求来了以后，通过分组条件对通道快速进行分组筛选，先精确过滤掉大部分通道以后，再进行精细筛选，效果就更好了其实分组条件一般不会太多，就如对人群进行分组一样，可以通过性别进行分组，男性、女性；可以通过籍贯进行分组，南方人、北方人通道分组条件常见的如：交易类型，账户类型，卡种，银行等
你看我们在收银台选择银行卡付款时，会有2个分组，B2C还是B2B，信用卡还是借记卡，这就是明显的分组
因此，如果用户是信用卡，那么仅支持借记卡交易的通道就肯定不适用进行分组以后，剩下的更少的几个通道，再进行筛选规则的筛选比如通过卡种做了分组以后，剩下的全部是支持信用卡的通道，再进一步筛选，这时候的要筛选的通道数量明显减少每经过一个筛选规则的过滤，都会剔除掉一部分通道，直到最后剩下1条通道或者0条，如果是0条的话，这笔交易可能就无法完成支付了上面我们讲了通道规则往往会分为分组规则和筛选规则2大类，二者共同构成一个逻辑链条如果你是一家非常小的公司，或者支付业务非常单一的公司，只有收款业务，那么一条链就够了，就是判断这笔收款走哪条收款通道
但是，如果你是一家业务种类非常多，通道种类非常多的公司，一条链可能就不够了
从支付产品来看，可能不同的支付产品需要的规则链不同，例如网银支付、快捷支付，通道的属性不同，需要校验条件不一样；但大部分条件是一样的，比如快捷支付设置了用户等级筛选条件，只有VIP用户才配用快捷支付，而网银不受这个限制，那么快捷支付的规则链中就多了一个“用户VIP筛选”从业务种类来看，支付、付款、鉴权、实名等不同的业务，其分组条件和筛选条件就完全不同例如，鉴权类业务，需要路由筛选出最优的鉴权通道，那么，鉴权类筛选里就有如“鉴权项数量”的筛选过滤，你要鉴权3项，而一条仅支持2项鉴权的鉴权通道就不满足了不同类型的企业通道类型不同，整个规则体系的设计方法论一样，只不过具体规则内容不同为了更好分析下面的内容，我们假设是一家三方支付机构三方支付机构的通道来自网联、银联、银行以及其他的三方机构，通道种类非常多，数量也比较多，能分析的规则就比较多路由的基本逻辑是匹配，根据交易参数，匹配通道的属性，以获得最合适的通道所以，研究路由规则就不得不研究匹配逻辑，而研究匹配逻辑就不得不了解交易参数和通道的基本属性
其实就是路由的请求接口要求传进来的参数，可能不同的路由业务要求的参数不同，比如支付传参和鉴权传参就不一样比如支付参数，你必须传进来商户号吧，这样路由系统才知道是哪个商户的交易，你必须传进来银行卡种吧，毕竟借记卡和信用卡所能用的通道不同，等等当然了，传什么不是机械的，是由你的路由规则决定的，换句话说就是路由需要什么就传什么
通道属性也可以认为是通道的画像，支持什么类型的支付，支付什么行业，什么时候维护，哪家银行的通道等等
分组条件往往是交易在请求路由系统时的必传参数，而且多是通道的可枚举的离散属性什么是离散呢，就是一个一个的，比如卡种，就是信用卡、借记卡
相对于离散就是连续，如时间，成本，就是连续条件，你不能用成本对通道进行分组，除非通过设定成本区间将成本这种连续的属性，变成离散属性如将通道成本分成三个区间[0,0.5)[0.5,0.8)[0.8,+∞)，就可以通过成本区间将通道进行分组交易类型，是消费支付、还是付款、还是鉴权；也就是这条通道支持的交易属性是什么，是支付通道、付款通道还是鉴权通道
账户类型，是对个人还是对公账户；就是这条通道是支持个人支付还是企业支付
卡种，是借记卡还是信用卡，这也是通道的属性之一，支持借记卡支付还是信用卡支付，当然，有些通道两类卡都支持
银行，这是哪家银行的，招商、工行还是农行，因为像银行卡类交易或者付款，往往同行支付体验更好，成本更低，跨行的支付成本更高一些通过上述4个分组条件对通道进行分组，可以快速缩小要筛选通道的数量
不同的规则链可以选择对应的分组条件，如鉴权规则链，如果接的都是银联的服务，那么就不需要银行这个分组条件了在通道完成分组以后，那么就需要在剩下的通道当中进行更精细的筛选了
比如，通道状态可不可用啊，需不需要报备啊，有没有白名单限制啊，营业时间到没到啊，有没有行业限制啊，这个商家有没有特别定制啊......其中，有些是通道的固有属性，例如有效状态；有些是需要进行加工计算的属性，列如本笔交易在某一条通道的交易成本经过一系列井然有序的筛选以后，能用的通道越来越少，最后几条筛选规则彻底杀死筛选比如成本最低优先，会出现一个排序，除非有2条通道的成本一样，否则一般能选出唯一的通道
如果最后所有规则都执行完了还没选出唯一的，还剩3条，怎么办那么这个时候，要不就是你的路由规则设定有瑕疵，要不就是通道过于重复，这时候就需要优化路由规则链，比如对同类通道强制性增加一个优先级排序，当都满足时，谁最优先
这是通道的固有属性，配置在通道信息中，一般是开通、关闭两个值，每次交易要过滤掉处于“关闭”状态的通道不管怎样，你得等别人开始营业才能去办理业务，也就是通道的营业时间维护，7*24小时的通道就不用说了，那些有固定营业时间的通道不是所有时间都支持交易的，比如人行的大额系统就有固定的营业时间在银行卡支付时，需要填写付款卡信息，用户填了多少决定了能走哪些通道，有的通道可能需要都填，有的通道可能不太严格；一般可以执行，必填必验，可填可验，必填不验有些通道会下发短信验证，有些通道不会，根据业务的诉求可能有些交易需要短信强验证，那么根据交易是否需要验证来过滤通道；如果你选了一个不会下发短信的通道执行一个需要进行短信验证的交易处理，那么通道就选错了通道有时候也术业有专攻，有些行业的交易风险高，可能就不允许，所以需要根据交易的行业类型，过滤掉不支持该行业的通道过滤掉有些通道需要用户的卡进行签约，没有签约的卡的支付便不支持对于经过一系列筛选剩下的通道去看其需不需要签约，如果不需要那么就直接可用，留下该通道；如果需要签约并且不需要短信验证，那么也留下；如果需要签约也需要短信验证，那么就通过交易传进来的卡号判断该卡在此通道是否已经签约，如果没有签约，就过滤掉该通道每一类通道都有限额，不是所有金额的支付都能走所有的通道
根据交易传进来的金额，和通道本身的限额区间进行比对，决定该通道是否可用有些通道需要设置商户白名单，名单之外的商户的支付请求不能走该通道
通过交易传进来的商户编号来判断该商户在不在通道的白名单里，如果在则可以走该通道，如果不在则不能走该通道有些卡比较奇怪，在某些通道就是支付成功率低，就是老出问题，那么就强制性把该卡种或者一张具体的卡添加到通道的卡黑名单中
只要是交易传进来的卡信息在某条通道的卡黑名单中，那么就不走该通道了肯定是鉴权项越少越便宜，用户支付体验越好，支付成功率越高
所以，都满足的情况下，选择验证项少的通道，根据通道属性的验证项进行筛选优先选择那些需要签约的通道，这个可能不太好理解，不是签约就比较繁琐么，为啥要选需要签约的通道呢？
这个还是长远考虑，签约以后今后的支付体验会更好，更容易成功
通过通道优先级这个属性对通道进行排序，选择优先级最高的通道
通道优先级的设定一般根据通道的历史支付成功率、成本优势等等完成，优先级越高越说明通道质量越高，选择高优先级通道往往可以提高支付成功率降低支付成本
比如同样是快捷支付通道，同类卡种，某些通道就是好，成本低，支付成功率又高，那么它的优先级就更高
这个就像选择供应商一样，商品质量好、价格低、配货时效快，如果同一个商品多家供应商都能提供时，那你肯定优先选择该供应商支付机构肯定要赚钱，所以支付成本越低利润空间就越高
那必然会选择成本最低的通道完成支付请求，根据通道的成本维护和交易传进来的金额，实时计算该笔交易走该通道的成本是多少
当然还有一些其他的规则，比如商户定制、银行定制、行业定制、直联签约优先等等，可以根据实际的需求，设置更多的分组规则和筛选规则不管怎样，无论多少规则基本逻辑都是一样的，就是通过交易特征去匹配通道特征或者进行某方面的优先性判断支付离不开通道，接入通道就需要跨过各个渠道的网关；当接入众多通道时，基于不同的交易场景要选择不同的通道提交支付，这时候就需要路由随着网上支付的发展，越来越多的业务实现网上的直接支付；而电子支付的基础提供者银行有专门的封闭的金融专用网络，而普通企业和大众消费者都是在开放的因特网进行交易和消费；电子支付对数据安全、隐私保护、通信安全、金融体系的安全有极高的要求，所以在这两个网络之间需要一个安全的屏障，通过加密技术、数字签名、实名机制、支付协议等技术手段，确保整个支付链路的安全可靠
8.1网关的定义
这个屏障就是支付网关，它是公开网络和银行专用网络之间的接口。就像你去公园要出示预约凭证和门票、出国要通过海关一样，支付网关就是一个关口，确保进入银行专用网络的通信不会对金融网络造成威胁，对调用者进行验证、对数据信息进行校验等随着电子支付业的发展，越来越多的非金融支付服务组织产生了，像三方支付机构，四方支付机构等，其帮助银行完成了支付网关的封装和更稳定和安全的技术手段，将封装后的支付网关提供给接入的电子商务平台，而这些服务机构的支付网关内联通着各大银行的支付网关；这就意味着企业不需要逐家去接入各个银行，接入一个三方支付的网关既可以接入众多银行随着断直连的实施，三方支付机构断开了跟银行的直接联系，而是通过网联银联接入各类支付服务；所以网关的层级变得更加复杂所以我们可以认为，支付网关除了单个机构网关之外，也是中国电子支付体系众多支付参与组织之间相关通信和传输支付指令的层层屏障，维护着整个我国电子支付体系的安全和各方参与者和用户的安全网关打造了一个个的围城，有的参与者在关内，有的参与者在关外；关内的参与者向关外的接入者提供了支付网关，要想与关内通信必须通过这层支付网关
站在某一个组织的角度来说需要接入多个支付网关，而这个组织对内需要提供统一的服务，这些服务通过接入的网关与外部机构之间实现通讯
所以对于一个组织的支付网关来说就是“对内提供统一支付服务，对外封装众多支付服务网关”的集合体，支付网关往往是一个网关矩阵的结合体，以链接众多支付服务机构的支付服务矩阵与内部系统之间的通信链路对于一个企业的支付网关来说，核心要解决的问题就是封装接入的众多支付网关，也就是接口，实现相互通信；并将各支付网关提供的各类支付服务，统一对内提供支付服务，比如支付、退款、下载账单等等；除此之外还需要提供数据校验，数字签名，加密解密，协议转换，支付协议封装转发等等服务
当然这是网关的基础能力，有些企业将支付系统也划归到支付网关内部，这样支付网关的职能边界被加大，承载着支付业务系统的职能，需要与内部风控，路由，交易等系统交互，这样做没什么不好，只不过显得笨重而已，这里我们将支付网关和支付系统单独研究，做一个小清新的纯粹的支付网关我们去公园或者饭店都有限流的情况，比如特殊时期某公园限流50%，饭店不能超过30%等政策；这些场景限流就是限制的人的数量，限流的原因除了特殊因素以外也是受场所里的空间以及设施的承载量所决定；这些场景的限流，通过控制门票数量或者进出的人流速度得到控制，或者座位的可用数量也可以得到控制。本质原理就是有一个池子（门票）资源控制有多少人可以进出
支付也会限流 跟处理性能 并发承载 网关需要做限流控制 保证内部稳定 工行查询 每5分钟一次 每次 多少条对于支付同样也是，小的支付机构因为本身技术能力，系统健壮性，服务处理能力，物理存储能力等各方面因素决定了一个能够承载并发的上限，超过这个上限系统就会崩溃，支付被延迟，成功率急速下降等不良后果
曾经接过一个通道，其查询限制在频次上不能低于2分钟1次，在单次查询的数据条数上不能超过1000条；同样各种云也会有下载的数据条数限制；这些都是为了保证良好的业务性能。你可以想想支付宝在双11的支付请求切到某一个普通的三方支付公司会怎么样，必然会瞬间瘫痪，大量用户支付超时、失败；这就是支付为何需要做限流的原因
当然限流是一个技术范畴的问题，产品经理也无法去评估和设计应该限流多少；除了那些基于商业模式需要做流量特殊限制的场景之外，产品可以去做方案设定，比如某些网盘非会员的下载速度是多少，充了会员又是多少，这些更多就是商业模式使然，其技术能力肯定是足够的
我们先树立对要限制的对象的限制维度的认识，就像我们认识物理上的速度、重量、长度一样，可以限制速度、限制重量、限制高度；支付上我们要限制的维度也可以很丰富，比如可以限制请求频次、请求文件的大小、请求的条数等等
对于支付网关来说，承载着内部网络和体系的安全和稳定，所以需要控制请求网关的频次以及数量，那如何实现支付的限流呢，这里我们介绍一个“令牌桶”的模型；了解其基本原理和模型，也有助于理解日常工作中各类场景的并发设定
令牌桶大家可以想象存在一个有固定容量的桶，并且往里面以稳定的速度或者可以被控制的速度存放“令牌”，而当数据来请求时需要先为请求分发令牌，这个跟门票很类似，有足够的令牌时请求才会被接受，没有足够令牌时，请求的数据要不被拒绝丢弃，要不放入缓存或者排队队列当中；这就是令牌桶限流的基本原理基于更复杂的工作场景以及限流诉求，我们可以基于以上的基础限流桶，做更复杂的限流控制，比如可以控制速度、控制频次、控制数量、控制大小等等，实现一个复杂的更智能策略的“令牌桶矩阵”
掌握基本原理的意义就是可以去应对复杂多变的场景和需求，支付限流也是，这个需求可能是性能瓶颈本身产生的，也可能是业务的商业模式产生的，或者是政策要求产生的；但无论多么复杂的场景，都离不开基础原理；这也是为什么基础学科非常重要了本部分
主编：陈天宇宙
作者：别字君、陈天宇宙
从最初的现金支付到当下的电子支付，支付通道已然是日常生活和商业交易中不可或缺的部分，也是各种支付业务的基础。本文将详细解析如何接入支付通道及规划通道管理系统相关功能 9.1什么是支付通道
以运输货物为例，要将一批货从A地运到B地，可实现的运输方式有路运、海运、铁运、空运。相同的目的地，不同的运输方式，往往还有许多不同的航道、铁道和公路可供选择，只不过过程中耗费的时间、承担的风险、金钱成本不同而已。
9.1.1支付通道概念
类似于运输，支付通道的本质是通过构建一个个信息交换的环境，用于支持交易过程中多方之间的信息的传递和验证，以实现交易资金的流动，最终促进交易的完成。
狭义上支付通道是指交易时连接消费者、商家和银行各方钱包账户的网络通路，而从广义上来看，只要能需满足支付的需求，并将信息、资金成功安全地转移给对应的收款方的路径，即使是企业的用积分去支付、利用虚拟卡、利用虚拟账户等内部的资产形式来支付，与这些管理资产的系统对接接入，我们可以说接入了“内部的虚拟支付通道”9.1.2支付通道的分类
随着支付行业的发展，不同支付场景催生出多种多样的支付通道，不同的通道细分出了不同的特点，我们可以从多个不同的维度进行分类，来更好地感知支付通道的差异。例如支持不同卡类型的通道：仅支持借记卡的通道、仅支持贷记卡的通道、借贷卡都支持的通道；扣款交互模式不同的通道：扣款前需要签约、鉴权的快捷通道、可建立预付授权关系，用于信用卡还款和水电煤缴费的代扣通道、需跳转银行页面进行付款的网银通道、通常被用于手机话费支付和流量充值等业务的手机运营商鉴权通道、支付时使用微信、支付宝等第三方支付平台输入支付密码或者进行指纹识别等进行认证的身份认证通道交易支持不同发起方的通道：持卡人（用户）发起、商户（平台）发起；有不同行业限制的通道：微信代扣就仅限符合周期扣费和先享后付场景的行业使用，会员续费、水电煤民生类行业、打车、酒店类行业、停车场或高速公路无人缴费；扣款要素不同的通道：如网银需要卡号和密码二要素、快捷则需要验证卡号/账号、户名、证件号、手机号四要素；支付标的物不同的通道：比如用积分来支付、银行卡支付、代币支付、虚拟币支付、银行卡支付等（1）根据通道的用途
通道的用途，顾名思义就是通道的功能，直白一点就是用来干嘛的，分为收款、付款、认证、跨境等收款通道：常说做支付要先做收单，收款通道就是实现让别人的“资产”付给自己的通道，打比方有早餐店“扫码支付”收钱立牌、线下商超的POS机支付、各类公交地铁卡和乘车码。出款通道：“出来混总是要还的”，出款通道能够实现把自己的钱付给别人，好比公司给我们发工资的代付通道、灵活用工通道、银企直连通道。鉴权通道：鉴权通道可以被想象成一条连接交易双方之间的安全通道，要先经过验证，才能通往支付之门。常见有银行卡签约验证；身份信息认证（四要素等），像账户的一些实名认证以及银行卡的绑定都需要用到；3D-Secure（3DS），一种用于网上支付的安全协议；指纹识别、面部识别等生物识别技术，通过授权人的生物特征来进行鉴权。（2）根据通道支持的对象
通道支持的对象，指的是支付交易的双方是谁，可以是个人、企业、组织等，通常我们区分为对公和对私。对公通道：用于企业账户支付，包括企业网银，企业账户代扣，企业转账等等。对私通道：用于个人账户支付，包括银行卡支付，微信、支付宝等三方个人账户支付。（3）按渠道提供方分类
其实支付通道是分层次的，下层为上层服务。不同的角色（按有无支付牌照、金融资质区分）对应所需的通道提供方是不同的。对于普通企业：通道的提供方是具有支付牌照的三方公司如支付宝、微信支付；各个银行；或者是企业自己内部搭建的虚拟账户支付通道、卡券支付通道、积分支付通道等。对于三方支付机构：那些有支付牌照，能对外提供支付能力的三方机构，他们需要的通道则是金融机构（银行、网联、银联）的核心系统。对于银行：银行所需的通道就是央行（也就是人行）的大小额系统、超级网银系统，这几个通道也是金融活动的根基。根据支付方式：就是用户在平台下单后调起收银台看到各种各样支付方式，包括云闪付、支付宝、微信支付、Apple Pay等。如下图京东PC收银台就有2个支付品牌，京东支付和微信支付；3个支付方式，白条、小金库、微信扫码支付。根据支付场景：包括线上支付、线下支付、跨境支付等。假设你深夜饿了，通过饿了么点外卖之后支付宝线上支付，或者出去楼下实体店面吃一碗隆江猪脚饭用二维码线下支付，然后早上醒来后像梁朝伟一样去伦敦喂鸽子，想喝一杯咖啡就需要用到跨境支付了。根据支付保障机制：包括担保交易（拍卖网站的拍卖交易就是一种担保交易方式）、中介支付（像电商支付平台，买家付款后会将资金冻结，待确认收货后才会把钱付给卖家）、风控评估（例如，贷款公司对借款人进行风险评估，判断其还款能力和信用水平）等。对支付通道有了初步的认识之后，我们来假定以下这样一个场景。假如你的公司要上线一个新业务，涉及到线上交易，需要你来负责接入支付，你会怎么处理9.1.3 支付通道的结构关系
要深如了解支付通道，我们还需要知道一个通道在支付体系中所存在的结构关系，这也是很多人容易混淆的，特别是支付方式、支付通道、支付品牌、支付产品、支付合作方之间的关系。支付方式、通道和品牌上文已经释义过，而什么是支付产品呢，我们借用微信支付的定义，支付产品其实就是支付机构针对某个支付场景，提供给外放使用的一套“解决方案”，其最基础也是最核心需要包含“支付通道”和“账户”两个服务，然后才能结合不同的场景包装出不同的产品。（1）支付通道-支付方式的关系
同一个支付方式，除了自身的官方通道，往往也会授权其他机构合作封装出对应通道，所以一个支付方式是由多个支付通道可以选择。（2）支付通道-支付合作方的关系
支付通道跟不同的合作方，又是处于什么关系呢。假设“光企业”要通过易票联接入微信支付的通道，那这条通道跟各个机构的关系如下。（3）支付通道-收付账户的关系
文章开头咱们也讲过，通道最终目的就算将不同收付账户之间的资金进行转移。以微信支付通道举例，可以看到通道和账户之间的关系和资金的转移。作为一个普通的企业，是有可能同时接入多个支付方式，因此也会有多条支付通道，那么这之间整体的关系又是怎么样的呢。（5）普通商户与金融机构的支付通道结构关系
通过上面的结构关系分析，我们可以初步看出一个从用户支付方式到各层支付支付组织之间的关系。假设你是光企业的物流运输部，你需要采购一辆货车，那你肯定需要关注对应货车的属性有哪些对吧？车型是普通货车还是牵引车、载重总量是多少、要燃油车还是新能源等。选通道也是，要知道通道都有哪些属性，这些属性就是我们在选择时要思考的维度，这些属性也是后续路由去判断的维度依据。了解了通道的属性，就对通道有了更直观的认识，那么就可以基于需求区选择所需要的通道了。 9.2.1基于业务和交易场景做选择
要选择什么通道，要先了解业务的场景，不同的业务模式需要不同的支付方式。例如，传统的线下零售业务可以选择POS机、微信支付宝的主扫、扫脸等，而线上平台则需要根据不同的平台进行选择。打比方公司准备依托微信小程序开发一款“针对园区等高密度打工人区域的午餐外卖”产品，则肯定是需要选择接入“微信小程序支付”方式的通道，而不可能选择支付宝。当产品成熟了有余力了再考虑拓展其他平台或者接入其他支付方式的通道。9.2.2多维度指标评估预选通道
选定好合作机构之后，可以根据下表，评估该通道是否符合公司业务需求，评估满足需求的话，就可以着手接入了。9.2.3通道的接入流程
（1）参与的团队成员及分工
（2）对接准备
对接之前，先确定自己的功能需求，比如我们是做演唱会票务，用户抢票之后是不允许退款的，那此时没有退款功能也不影响第一期上线。另外如果咱们是租赁场景比如租房，需要向用户收押金，但是退款往往有时限，这个时候就需要思考其他退款办法了，比如接入打款通道。一般的支付公司为了方便广大用户使用,提供各种不同的接口,相同的功能也进行多变的实现。所以我们跟对方讲清需求后，对方开发人员通常比你更熟悉接口的使用和效果，他们很可以帮助我们快速找到最优的接口方案。另外，很多合作方的文档都可能存在更新不及时问题，可以跟对方确定清楚用哪个板本的文档。必须弄清你需要哪些接口后，我们要看清楚接口字段值怎么传、是否必传，以及有什么响应码。另外注意要和对方确定好返回结果是以码为准，还是以描述为准。这里先强调一个支付中和退款中的问题，一定要牢记设计支付状态要考虑中间状态，以免产生线上问题。此外安全类对接准备也需要提前沟通清楚，如IP地址白名单是否配置，怎么配置；公私钥加签验签；接口加密解密；是否需要专网、前置机堡垒机等，作为普通企业，如果不是对接银行核心系统的话，一般是不需要前置机堡垒机。这个环节你也可以拉上开发大哥协助评估。选择好要接入的之后，我们就需要规划我们的通道管理模块，以避免后续支付业务壮大了，最基础的模块却一团糟，因为很多人都是图快，先干上线，等到发现好乱了的时候，已经为时已晚。规划通道管理模块之前，我们先看下通道管理在整个业务系统中是在哪里发挥作用的。上游系统选择完通道，就可以拉起对应的支付、退款、打款请求了。接着我们就来分析，我需要为通道管理规划什么样的功能。管理管理，首先咱们肯定得知道有什么通道，才能管理吧，因此肯定需要有一个通道管理列表。9.3.1通道管理列表
这里以入金通道举例子，接入通道之后，每一条通道都有唯一的通道名称和编码，这个好理解，就像每个人都有身份证和名称一样。然后再把通道关联上支付方式和状态，没有其他追求的话，这个通道管理也就能用起来了。不过咱们还是要为以后打好基础，站在企业的角度，咱们是不是需要核算每一次支付产生，企业所要付出的成本，也就是通道手续费，此时我们就需要为该通道关联对应的“成本规则”；比如站在运营/维护通道人员的角度，通道的一些商户号、回调地址有时候也需要变更，我们是不是做成配置化会显得更人性化；假设我们财务要知道每一笔支付是去到哪个账户，好去核对每天的账目，那我们是不是需要在通道关联“入账账户”会让后续的对账更方便（注意这里不是指定真实的资金流渠道哪个账户，而是纯粹的记录，方便后续核账）。至于“映射通道代码编码”和“权重”，没有也行。“权重”主要是为了方便路由去兜底一个支付通道。而“映射通道代码编码”作用是让运营和后续接手的开发知道，这一条我们“定义的通道”对应是走那一套真实的通道代码。阐述一个具体情况，当我们公司接入某家公司同一条通道，但是出于商务等原因开通了几个商户号，这几个商户号要参与路由切换，而背后对应的代码，则是同一套。所以一开始设计的时候，个人建议把我“不同真实通道+不同商户号”为最小颗粒度，定义我们通道管理里的唯一通道。通道成本规则我们设计成单独配置规则，然后再从通道关联对应的成本规则，这样就不用新增通道的时候反复配置同样的成本规则。遇到银行卡通道的时候，不同的银行收的费用可能会不一样，所以可以根据自身需求定义一个特殊银行特殊配置，如果特殊银行多的话，建议用导入配置文件的交互形式。至于通道成本怎么用呢，其实就是在我们发起交易和退款的时候，读取对应通道的成本规则，计算出这一笔交易所产生的成本，并记录在每一笔支付记录里面，以后统计就可以很方便拉。9.3.3通道参数配置
通道参数配置，一般是配置比较敏感的内容，商户号、请求地址等，记得做好菜单或者功能权限，专人专用。9.4.1接入背景
为给客户提供更快捷、更优秀的支付体验，我们团队决定开发上线一个银行卡代扣支付功能，让用户实现账单的自动代扣支付，免去繁琐的操作。经过公司领导层商议，决定接入PAF协议支付这条通道。9.4.2研读接口文档
（1）接口调用流程
通过接口调用流程，我们可以看出要银行卡代扣通道，要完成支付之前，还需要进行签约两步。第一步调用协议签约接口进行签约请求，下发短信给用户，用户输入短信后调用协议签约短信验证接口验证验证码，完成签约；第二步通过协议签约返回的信息（签约号）进行协议扣款，并同步返回交易状态。（2）签约环节
就是发起协议签约申请，发起成功后会给持卡人下发一条短信。
可以看到这条通道申请协议签约的时候，需要上送一个银行编码，并且这个编码是要根据这条通道的定义来，看到这里我们就要联想起两个问题第一点，卡签约的时候需要知道这张卡是什么银行卡，这个后续跟大家介绍卡bin模块。第二点是，不同无卡通道有可能存在的特殊标准，使用的银行编码标准与其他不相同，这时可以回想我们的通道属性和特征，就存在通道银行编码的对应维护了。这里再说一个点，有一些通道签约信用卡的时候，需要上送CCV和有效期，而刚好这条通道不需要，因此前端签约页面也需要根据不同的通道进行路由，从这里又印证了咱们通道管理和维护还是蛮重要的。调用签约申请之后，合作方会给持卡人手机发送短信，并接口返回一个令牌号。用户输入短信验证码后，接口上送验证码和令牌号，就可以完成短信验证，验证通过就可以签约成功，获取对应的协议号。（3）扣款和退款环节
拿到签约协议号，则可以根据该协议号进行发起扣款，咱们看接口说明，需要特别注意交易金额这个字段，单位是分，千万要搞清楚交易金额的单位，别摆大乌龙。另外咱们看到有一个后台通知地址，他是我们发起扣款交易时，指定一个交易结果的通知地址，当交易有结果后，通道方会将结果告诉我们，按照上述地址。像更严密的通道方还会要求接入方进行结果响应，并且有一套完整的通知策略。发起扣款之后，我们就需要关注扣款是否成功，可以看到响应信息已经说明这个操作成功仅代表请求成功，不代表交易成功。因此这里重点说一声，支付状态一定要有支付中这个中间状态，以及要对支付中这个状态有对应的补偿机制，不然很容易发生线上交易事故。当你发起一笔交易的时候，还没收到通道方的结果之前这一笔交易就是支付中，等到有回调结果或者主动查询，再根据结果更改状态。另外我们也要关注，单笔交易有无最低金额限制，以及并发量最多是多少，能不能多线程。顺便再提一嘴，最好建议开发大哥在封装支付和退款接口的时候，即使接入了很多不同的通道，建议也尽量封装成一个统一的下单接口和回调接口给业务层用，可以避免很多麻烦。退款也可以看到，金额单位是分，以及退款也需要加退款中状态，同扣款一样就不赘述。这种退款是原路退回，通道方会做好校验，一般不太可能一笔支付多退了钱，倒是要考虑退款时效是多长（有的合作方限制交易半年或一年后就不能退款）、能不能部分退款、退款次数有没有限制、同一笔支付能不能同时发起2次退款。（4）响应码
一般响应码有公共响应码和不同接口对应的业务响应码，这里建议前期梳理出一些常见通用的响应码，并“翻译”出用户可读懂的文字，以供展示。以及可以在报错类的提示前面加上通道合作方英文，以方便定位是我们系统报错，还是哪个通道方报错。如我们公司定义为DM，某通道方定义为PAF，则报错内容展示为PAF:XXXXX，就可以很快速定位到是通道方的报错。9.4.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)))
for i in range(len(num_list)-2, -1, -2):
num_list[i] <<= 1
if num_list[i] > 9:
num_list[i] -= 9
if sum(num_list) % 10 == 0:
return True
else:
return False
```
其中，str(card_num)将card_num转换为字符串，map(int, str(card_num))将字符串转换为由每位数字组成的列表，然后进行逆向乘积求和，并进行校验。目前银联卡几乎都支持校验码算法，但是也不排除极个别不支持此算法的，如杭州银行早期发行的西湖卡和浙江民泰商业银行。银行卡号检测正确之后，就从10位开始遍历卡bin表，依次递减至6位，直到找到唯一卡bin为止，并返回该卡bin对应的银行卡信息和所属银行。（目前国内银联卡,因银行众多,特别是村镇银行的存在,BIN长度以6位占绝大部分,另外还存在7、8、9、10等位数卡BIN）。（3）银行管理
银行管理用于维护企业自己系统的标准银行及编码，为什么要加自己内部的标准？还记得上文说过的不同通道可能有不同的银行编码标准吗？如果我们接了多个通道都有不同标准的银行编码，那么我们要根据我们自己的卡BIN，匹配我们标准的银行编码，再去映射不同的通道编码。再者当我们没有接入多个通道的时候，不用复杂的路由的时候，哪些银行的储蓄卡、信用卡是否支持签约代扣，也可以放在此处去维护管理，当前端识别到不支持的银行的时候，则直接提示用户换卡即可。（4）签约记录
签约记录，方便运营/客服人员核实某个用户某张卡的签约状态，以应对用户的进件咨询和对外合作。签约数据结构大家可以根据实际场景来设计，一种是卡号+商户、一种是用户+卡号+商户。两者灵活度不一样，举个场景，一个车队老板名下挂靠了很多太车，分别不同司机在管理，但是都用老板或者公司的账户签约代扣ETC通行费，如果某台车离职了，如果签约结构是卡号+商户，那把离职的司机的签约关系解绑了，那老板名下所有签约关系都解绑了。然后关于签约数据，建议一开始就让开发大哥们维护一份独立的、统一的通道签约数据层，用于记录卡/账户信息在不同通道上的签约或者验证结果，以便路由层及其他业务场景可以据此来进行重新签约或者支付路由。如果部维护统一的签约数据，而是业务各自去维护，就会出现一个比较尴尬的现象，以我司举例子，我们有客车和货车业务线，但是同一个用户同一张卡可能同时办理了客车和货车，签约数据如果各自维护，存在先后的签约关系，在通道方旧的签约号就会失效，失效的那一条业务线对应的用户就会扣款失败。同一张卡的签约策略也是值得考究的，比如通道方是否允许重复签约，重复签约会返回什么样的结果，这些都是要搞清楚的。然后基于企业自身，重复签约的时候是自己内部走个验证即可，还是重新上送通道方进行签约，这些也都要考虑好。如果通道方没有限制，个人倾向重新上送通道方去做签约，这样可以及时更新已过期的签约号。有了统一的签约数据的话，同一张卡我甚至可以根据业务需求，在用户不同绑卡场景下判断是否走另外的通道进行签约，为同一张卡增加多一个扣款通道。（5）通道异常应急处理机制
最后再建议大家，可以在前期就考虑规划下异常预警机制，比如某个通道连续签约、扣款失败，就要及时发出通知。我们可以秉承下列3个原则设定处理机制，在通道出了异常之后快速响应，确保交易正常、规避损失、维护用户体验。专业：应急规范及角色分工清晰；有序：应急流程清楚简单、为可执行的标准化流程；快速：优先恢复通道交易稳定性，其次定位问题和提出解决方案。万丈高楼平地起，对于支付而言，支付通道管理是不可或缺的一环，其他第三方底层服务也可沿用该思路进行管理，希望本文能对大家带来帮助。我们知道支付是付款人向收款人的资金转移，而支付系统就是实现这一目标的处理系统“转移”可以是用户要在平台下单购买商品向平台支付资金，也可以是平台要向商家结算经营款而发起了付款因为要转移的资金存储在外部非金融或者金融机构的结算账户或者支付账户中，因此如果想实现资金转移的目标，就需要接入能与这类机构进行通讯的通道，通过通道发起支付指令和接收资金的处理结果从图中可以看出来，支付通道要解决2个核心问题，一个是发起支付指令，另一个是接收支付结果；收款业务发起收款指令接收收款结果，通过收款通道实现；付款业务发起付款指令接收付款结果，通过付款通道实现以上是我们知道的常规通道，三方支付机构的收付通道，网联银联的各类通道，银行的各类通道，都是支付正规军，标准化的支付业务可以看如下的支付架构图，在通道层的常见通道位置，以此实现上述的收付业务图中有一个标红的通道种类，也就是有没有非正规军或者非常规的支付通道呢？
为了完成“支付业务”，能不能跳出三界之外，不拘泥于传统，在保持上述框架的基础上，而更加灵活多变
这就是接下来要谈的“广义通道”，即只要能实现“广义收付指令发起”“广义收付结果接收”二者中的任何之一的职能，我们都称之为“通道”
能查账户流水通过系统匹配实现支付确认，其中的“查询流水的接口”，可以认为是一种通道可以人工导入线下凭证以确认待收付单据，其中“线下凭证的导入”，可以认为是一种通道可以人工确认支付结果、其中“确认按钮”的结果确认，可以认为是一种通道接入账户系统发起余额增减并接收增减结果、可以认为“账户系统提供的接口”是一种支付通道接入仓储，可以通过变更寄存商品的归属权，进行债权转移以完成价值交换或者应收应付的核销，其中的接入仓储可以认为是一种通道因此，支付是资金的转移，交易是价值的交换，而支付其实就是资金与价值的交换，因此广义支付就是构建价值交换的通路，而广义的通道就是价值交换通路的交换信息发起和交换最终结果的接收那么回到上面的支付架构图，将红色带“？”地通道模块展开如此架构，可以将更多的支付“相关类似业务”兼容到支付系统的架构中，让支付系统架构更具灵活性，并为支付业务的拓展提供了在架构上的指导和设计规范
图中的某些处理在常规情况下，我们一般不会放到通道层，比如调用内部账户系统的余额支付，很多时候我们会直接由支付核心去调用，而不是通道层去调用，这时，支付核心将会在主流程之外构建一个特殊的分支，就像在人的体外插了一个输液的管子一样，这样做，看似没什么，但总归是对“整体架构的损害”
下面通过1个例子来强化上面的5类或者更多特殊支付通道构建支付业务的思维有些场景用户会直接汇款至对公户，即线下支付，最大的弊端就是资金处理和线上的业务单据割裂这部分款项的核对以及领取相比全流程线上交易来说，比较繁琐，一方面是核对困难，另一方面就是款项和业务单据对应上比较麻烦当线下汇入体量较大时，该部分工作成本更高；如果线下进行汇款，而需要线上履约时，这部分匹配工作如何提升效率，能否自动化实现而依托“广义通道和支付架构”的引导，我们将对账能力认为是一种支付能力，通过支付核心构建出来，因此就形成了这样一种结构即业务系统请求支付核心，支付方式为“线下汇入”，支付核心创建线下汇入待支付单通过银企直联获取银行账户流水作为支付结果信息，在线下汇入支付的处理中进行结果的匹配，从而获得线下汇入支付单的最终支付结果，并将该结果告知业务系统，业务系统收到结果后进行后续的业务处理
那么，我们怎么将线下汇入业务融入到整个支付核心的架构中呢？如下图在支付接入层增加线下汇入支付方式，业务系统可以进行调用，在支付核心创建“线下汇入支付方式的支付单”，最初的单据状态为待支付
而通道层的“广义特殊通道”为“查询银行流水”；是建设在银行通道的“银企直联”之上我是你的最强支付军师——陈天宇宙。10年大厂支付产品专家，代表作《支付32真经》《上帝视角看支付》《支付之门》等，为您提供深度支付内容和服务！