跨境支付：通道出岔子，千万资金一夜蒸发！

从最初的现金支付到如今便捷高效的电子支付，支付通道已经深深融入了我们的日常生活和商业活动中，成为各种支付业务不可或缺的基石。今天，新媒网跨境就和大家聊聊支付通道那些事儿，一起深入了解如何接入支付通道，并如何规划一套实用的通道管理系统。

1. 支付通道，到底是个啥？

想把一批货物从甲地运到乙地，我们可以选择陆运、海运、铁路或者空运。即便目的地相同，不同的运输方式，还会有许多具体的航线、铁路线和公路可供挑选。当然，选择不同，耗费的时间、承担的风险以及金钱成本自然也就不一样。

1.1 支付通道，就是资金流动的“高速公路”

和实物运输的道理一样，支付通道的本质，就是搭建起一个个安全、高效的信息交换环境。它承载着交易过程中多方信息的传递和验证，最终实现资金的顺畅流动，让每一笔交易都能圆满完成。

狭义上来讲，支付通道指的是连接消费者、商家和银行各方账户的网络通路。但如果放宽视野，从广义角度来看，只要能满足支付需求，并将信息和资金安全、准确地转移给收款方，那它就是一条“支付通道”。哪怕是企业内部用积分支付、虚拟卡支付，或是利用虚拟账户等内部资产形式进行支付，只要与这些管理资产的系统对接，我们也可以将其视为接入了“内部的虚拟支付通道”。

1.2 支付通道的五花八门

随着支付行业的飞速发展，各种支付场景层出不穷，也催生出了琳琅满目的支付通道。这些通道各具特色，我们可以从不同的维度来观察它们，更好地理解其中的差异。

比如，有的通道仅支持借记卡，有的仅支持贷记卡，还有的则借记卡、贷记卡都能用，这就是根据“支持的卡类型”来划分。

再比如，按照“扣款交互模式”的不同，支付通道也有很多玩法：

快捷支付通道： 扣款前需要先完成签约和鉴权，操作起来非常方便快捷。
代扣通道： 可以建立预付授权关系，常用于信用卡还款、水电煤缴费等定期扣费的场景。
网银通道： 付款时需要跳转到银行页面进行操作，相对传统。
手机运营商鉴权通道： 常见于手机话费充值、流量购买等业务，通过手机运营商进行身份验证。
身份认证通道： 在支付时需要通过微信、支付宝等第三方支付平台输入支付密码，或者进行指纹、面部识别等生物认证。

我们还可以根据“交易发起方”来划分，有持卡人（也就是用户）发起的，也有商户（或平台）发起的。

“行业限制”也是一个重要维度。例如，微信代扣就并非所有行业都适用，它主要限定于符合周期性扣费和“先享后付”场景的行业，比如会员续费、水电煤等民生类服务、打车、酒店住宿、停车场或高速公路的无人缴费等。

“扣款要素”也有不同。像网银支付通常需要卡号和密码这两个要素，而快捷支付则可能需要验证卡号/账号、户名、证件号、手机号这“四要素”。

最后，按照“支付标的物”来分，可以是积分支付、银行卡支付、代币支付，甚至是虚拟币支付等。

1.2.1 看通道的“用途”

通道的用途，说白了就是它能干什么。主要可以分为收款、付款、认证和跨境几大类。

收款通道： 俗话说“做支付要先做收单”，收款通道就是让别人的钱能付到自己账上的渠道。举个例子，早餐店里贴着的“扫码支付”牌子，线下商超里用的POS机，各种公交地铁的刷卡或乘车码，它们都属于收款通道。

出款通道： “出来混总是要还的”，出款通道就是把自己的钱付给别人。比如公司给我们发工资用的代付通道、面向灵活用工人员的结算通道，或者直接通过银企直连进行的转账等。

鉴权通道： 鉴权通道就像连接交易双方之间的一条安全验证的“门槛”。它要求交易先经过验证，确认身份无误后，才能顺利进入支付环节。常见的鉴权方式包括：银行卡签约验证；身份信息认证（比如四要素验证），像我们开账户时的实名认证和银行卡绑定就需要；3D-Secure（3DS），这是网上支付常用的一种安全协议；还有指纹识别、面部识别等生物识别技术，通过授权人的独有生物特征进行验证。

1.2.2 看通道支持的“对象”

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

对公通道： 专门用于企业账户之间的支付，包括企业网银、企业账户代扣、企业间转账等。

对私通道： 主要用于个人账户之间的支付，比如银行卡支付，以及大家常用的微信、支付宝等第三方个人账户支付。

1.2.3 看通道的“提供方”

支付通道其实是分层级的，下层为上层提供服务。不同的角色（主要是看有没有支付牌照、金融资质）所需要的通道提供方也是不一样的。

对于普通企业： 它们需要的通道提供方，通常是拥有支付牌照的第三方公司（比如支付宝、微信支付），或者是各大银行。此外，企业自己内部搭建的虚拟账户支付通道、卡券支付通道、积分支付通道等，也属于这个范畴。
对于第三方支付机构： 那些拥有支付牌照、能够对外提供支付服务的第三方机构，它们所需的通道，则是直接与金融机构（如银行、网联、银联）的核心系统对接。
对于银行： 银行作为金融体系的核心，它们所依赖的通道就是国家央行（也就是人民银行）的大小额支付系统、超级网银系统。这些通道构成了整个国家金融活动的根基，是金融体系最底层、最核心的支付基础设施。

1.2.4 其他分类方式

根据支付方式： 当用户在平台下单后，支付页面（收银台）会列出各种各样的支付选项，比如云闪付、支付宝、微信支付、Apple Pay等。就拿我们日常网购来说，一个电商平台的电脑端收银台，可能会同时显示多个支付品牌，比如平台自有的支付，以及微信支付；同时提供多种支付方式，比如分期支付、零钱支付，还有微信扫码支付。

根据支付场景： 这包括线上支付、线下支付、跨境支付等。
假设你深夜肚子饿了，用手机通过外卖平台点餐，然后用支付宝在线上完成支付。或者，你出去家附近的实体店吃碗美味的隆江猪脚饭，用二维码在线下支付。等到第二天早上，你心血来潮，想学英国知名影星在英国伦敦街头喂鸽子，顺便想买杯咖啡，这时就需要用到跨境支付了。

根据支付保障机制： 这类通道旨在为交易提供额外的安全保障。

担保交易： 比如拍卖网站上的交易，买家付款后，资金会先由平台保管，等买家确认收到货物并满意后，资金才会支付给卖家。
中介支付： 像电商平台的支付系统，买家付款后资金会被冻结，直到确认收货，钱款才会打给卖家。
风控评估： 比如贷款公司在向借款人提供贷款前，会对借款人进行风险评估，判断其还款能力和信用水平，这也是一种支付保障机制。

对支付通道有了初步认识后，我们不妨设想这样一个场景：如果你的公司要上线一个新业务，涉及线上交易，需要你来负责接入支付功能，你会怎么处理呢？

1.3 支付通道的“家族关系”

要深入理解支付通道，我们还得搞清楚它在整个支付体系中的结构关系，这是很多人容易混淆的地方，特别是支付方式、支付通道、支付品牌、支付产品和支付合作方之间的关系。支付方式、通道和品牌我们前面已经解释过，那什么是支付产品呢？借用微信支付的定义，支付产品其实就是支付机构针对某个支付场景，提供给外部使用的一整套“解决方案”。它最基础、最核心的部分需要包含“支付通道”和“账户”这两个服务，然后才能结合不同的场景，包装出各种各样的产品。

1.3.1 支付通道与支付方式的关系

同一个支付方式，除了其官方提供的通道，往往还会授权其他机构合作，封装出对应的通道。因此，一个支付方式通常会有多个支付通道可供选择。

1.3.2 支付通道与支付合作方的关系

支付通道与不同的合作方，又是怎样一种关系呢？假设一家“光彩企业”想要通过“易连支付”接入微信支付的通道，那么这条通道与各个机构之间的关系可以这样理解：首先，“光彩企业”是实际发起支付需求的一方；它会与“易连支付”这样的第三方支付服务商合作，由“易连支付”提供技术对接和服务；“易连支付”再通过其已有的接口，连接到“微信支付”的通道；最终，“微信支付”的通道会与用户选择的银行账户进行交互，完成资金的转移。在这个过程中，各方环环相扣，共同构成了完整的支付链路。

1.3.3 支付通道与收付账户的关系

文章开头我们提到，通道的最终目的就是实现不同收付账户之间的资金转移。以微信支付通道为例，当用户通过微信支付向商家付款时，资金首先从用户的微信零钱账户或绑定的银行卡账户扣除；接着，通过微信支付通道内部的清结算体系，这笔资金最终会被结算到商家的微信收款账户或其指定的银行账户中。整个过程，支付通道就像一座桥梁，安全高效地连接着资金的来处和去向。

1.3.4 普通商户的支付通道“全景图”

作为一个普通的商家，很可能需要同时接入多种支付方式，因此也会对应多条支付通道。那么，这些支付方式和通道之间，整体的结构关系又是怎样的呢？可以想象，用户通过不同的支付方式（如微信、支付宝、银行卡），会触发各自对应的支付通道。这些通道再统一接入到商户的支付系统中，商户的支付系统负责将这些来自不同通道的资金进行汇总处理，并最终结算到商户的对公账户。整个流程，就像一个复杂的交通枢纽，管理着四面八方涌来的资金流。

1.3.5 普通商户与金融机构的支付通道“进阶版”

如果再往深一层看，就涉及到支付机构和清结算机构了。当普通商户接收到用户的支付，这些支付信息首先会传递给与商户合作的支付机构（比如支付宝、微信支付或者其他第三方支付服务商）。支付机构收到信息后，会进行初步处理，然后将这些交易数据提交给清结算机构（如网联、银联）。清结算机构负责将来自不同银行的交易进行汇总、对账和清算，确保资金在银行之间准确无误地划拨。最终，资金会从用户的开户银行划拨到商户的开户银行，完成整个交易链条。这个过程体现了我国金融体系的严谨和高效。

通过上述结构关系的分析，我们初步勾勒出了从用户选择支付方式，到各层支付组织之间层层递进的关系。

2. 如何慧眼识“通道”？

在寻找合适的通道之前，我们先来探讨一下究竟该怎么选。假设你是“光彩企业”的物流运输部负责人，需要采购一辆货车。你肯定会关注货车的各种属性，比如它是普通货车还是牵引车？总载重是多少？是燃油车还是新能源车？选择支付通道也是同样的道理。我们需要了解通道有哪些属性，这些属性就是我们在选择时要考虑的维度，也是后续进行路由判断的依据。只有了解了通道的“基因”，才能基于自身需求，精准选择到最适合的通道。

2.1 跟着业务和交易场景走

选择什么通道，首先得看业务的场景。不同的业务模式需要搭配不同的支付方式。例如，传统的线下零售门店，可以选择POS机、微信支付宝的扫码支付、扫脸支付等；而线上平台则需要根据其自身特点和用户习惯进行选择。打个比方，如果公司计划依托微信小程序开发一款“专为园区高密度办公人群打造的午餐外卖”产品，那么毫无疑问，首选肯定是接入“微信小程序支付”方式的通道，不可能一开始就去考虑支付宝。等到产品成熟，有了足够的余力，再考虑拓展其他平台或接入其他支付方式的通道，这才是稳扎稳打的发展策略。

2.2 多维度指标，全面评估预选通道

选定潜在的合作机构后，我们可以从多个维度对预选通道进行全面评估，看看它是否符合公司的业务需求。如果评估下来都满意，就可以着手准备接入了。在评估时，我们通常会考虑以下几个关键指标：

交易费率： 这是最直接的成本，包括支付手续费率、提现费率等。需要仔细对比不同通道的费率结构，计算出实际的交易成本。
结算周期： 资金从交易发生到最终结算到公司账户需要多长时间，比如T+0、T+1、周结等。这直接影响公司的现金流。
通道稳定性： 通道在高峰期或日常运营中是否稳定可靠，是否有频繁的故障或延迟。高稳定性的通道能保障用户支付体验和交易成功率。
安全合规性： 通道是否符合国家相关的支付法规和安全标准，是否具备完善的风控系统，能够有效防范欺诈风险。这是支付业务的生命线。
易用性： 接入流程是否便捷，接口文档是否清晰，开发对接难度如何。良好的易用性可以节省开发和维护成本。
风控能力： 通道提供方是否有强大的风控能力，能帮助商户识别和拦截风险交易，降低坏账率。
客服响应速度： 在遇到问题时，通道提供方的客服响应是否及时，解决问题的效率如何。
支持币种与地区： 对于有跨境业务需求的公司，需要关注通道是否支持多币种交易，以及覆盖的地区范围。
退款与差错处理机制： 退款流程是否顺畅，差错交易如何处理，是否有明确的争议解决机制。
交易限额： 通道对单笔交易、每日交易或每月交易是否有金额限制，这会影响业务的规模和用户的消费能力。

新媒网跨境了解到，综合考量这些因素，才能选出最适合自身业务发展，同时兼顾成本与效率的支付通道。

2.3 支付通道接入“路线图”

2.3.1 团队协作，各司其职

接入支付通道并非一蹴而就，需要多个团队成员紧密配合，才能顺利完成。
商务团队： 负责与通道提供方进行商务谈判，明确合作条款、费率、结算方式等，最终签订合作协议。
产品团队： 负责梳理业务需求，定义支付流程、用户体验，并输出详细的产品需求文档。
研发团队： 根据产品需求文档，进行技术选型、接口开发、系统集成，确保支付功能的实现。
测试团队： 对接支付通道后，进行全面的功能测试、性能测试和安全测试，验证支付系统的稳定性和可靠性。
财务团队： 关注资金结算流程、对账机制，确保每一笔交易的资金流向清晰、账目准确无误。

2.3.2 对接准备，步步为营

在正式对接之前，充分的准备工作能让整个过程事半功倍。

第一步：明确自身需求。 在对接任何通道前，首先要清楚自己的业务到底需要什么功能。比如，我们是做演唱会票务的，用户抢票成功后是不允许退款的，那么第一期上线时没有退款功能也完全不影响。但如果我们的场景是租房，需要向用户收取押金，而退款往往有时限性，这时候就需要提前思考是否有其他退款解决方案，比如接入一个主动打款通道。

第二步：明确接口文档。 一般的支付公司为了方便广大用户使用，会提供各种不同的接口，甚至相同的功能也会有多种实现方式。所以，当我们向合作方讲清楚需求后，对方的开发人员通常比我们更熟悉接口的使用和效果，他们能帮助我们快速找到最优的接口方案。此外，很多合作方的文档可能存在更新不及时的问题，所以一定要和对方确认清楚当前使用的是哪个版本的文档。

第三步：研读接口文档。 明确了需要哪些接口后，我们就必须仔细研读接口文档，弄清楚每个字段的值应该怎么传输、是否为必传项，以及各种响应码的含义。另外，还需要和对方确认好，判断交易结果是以响应码为准，还是以具体的文字描述为准，避免后续产生歧义。

第四步：输出需求文档。 这份文档应该包含接入的背景、罗列所有功能点，并明确第一期要实现哪些核心功能。这里要特别强调一个关于支付中和退款中的问题：在设计支付状态时，一定要牢记考虑各种“中间状态”，以免产生线上问题。此外，安全类的对接准备也需要提前沟通清楚，比如IP地址白名单是否需要配置，如何配置；公私钥的加签验签机制；接口加密解密的具体方案；是否需要专网、前置机、堡垒机等。作为普通企业，如果不是直接对接银行核心系统，一般情况下是不需要前置机和堡垒机的。在这个环节，建议可以拉上开发同事一起协助评估，确保技术方案的合理性和可行性。

3. 支付通道管理系统，让复杂变得简单

选择好要接入的通道之后，我们就需要规划自己的通道管理模块了。这样做能有效避免后续支付业务壮大时，最基础的模块却一团糟的局面——很多人都是为了图快，先上线再说，等到发现系统混乱时，往往已经为时已晚。在规划通道管理模块之前，我们先来了解一下通道管理在整个业务系统中扮演着怎样的角色。

简单来说，当上游业务系统（比如电商订单系统）完成支付通道的选择后，就可以通过通道管理模块拉起对应的支付、退款或打款请求。接着，我们就要深入分析，需要为通道管理模块规划哪些功能。既然是“管理”，那首先肯定得知道有哪些通道才能进行管理，因此，一个清晰的通道管理列表是必不可少的。

3.1 清晰明了的通道管理列表

我们以“入金通道”为例来聊聊。接入通道后，每一条通道都应该有一个唯一的通道名称和编码，这就像每个人都有自己的名字和身份证一样，方便识别。然后，再将通道关联上支付方式和启用状态，如果只是满足基本需求，这样的通道管理也就能用起来了。

但为了长远发展，我们还是要打好基础。从企业的角度看，我们是不是需要核算每一笔支付交易产生的成本，也就是“通道手续费”？这时，我们就需要为每条通道关联对应的“成本规则”。再者，从运营或维护人员的角度，通道的一些商户号、回调地址有时需要变更，如果做成“配置化”管理，是不是会显得更人性化？假设财务部门需要知道每一笔支付最终是进入了哪个账户，以便后续核对账目，那么在通道管理中关联“入账账户”，无疑会让对账工作变得更加便捷（这里指的是纯粹的记录，方便核账，并非指定真实的资金流向）。

至于“映射通道代码编码”和“权重”，没有也无妨。其中，“权重”主要是为了方便支付路由系统在多个通道可用时进行智能选择或兜底。而“映射通道代码编码”的作用，则是让运营人员和后续接手的开发人员清楚，我们自己定义的这条“通道”，对应的是哪一套真实的通道代码。

举个具体例子，如果我们公司通过同一家合作方接入了同一条通道，但出于商务原因开通了几个不同的商户号，这些商户号需要参与路由切换，而它们背后对应的代码，实际上是同一套。所以，在设计之初，我个人建议将“不同真实通道 + 不同商户号”作为最小颗粒度，来定义我们通道管理系统中的唯一通道。这样既能精细化管理，又能保持底层技术实现的简洁。

3.2 灵活的通道成本规则

通道成本规则，我们建议设计成单独配置的模块。这样，在新增通道时就无需反复配置相同的成本规则，只需从已有的规则中选择关联即可。当遇到银行卡通道时，不同银行收取的费用可能会有所不同，因此我们可以根据自身需求，定义一些针对特殊银行的特殊配置。如果特殊银行较多，建议采用导入配置文件的方式，提高配置效率。那通道成本规则具体怎么用呢？其实很简单，当用户发起交易或退款时，系统会读取对应通道的成本规则，自动计算出这笔交易所产生的成本，并记录在每一笔支付记录中。这样一来，后续进行成本统计和分析就非常方便了。

3.3 严谨的通道参数配置

通道参数配置，通常用来管理一些比较敏感的内容，比如商户号、请求地址等关键信息。因此，务必做好菜单或功能权限管理，确保只有经过授权的专职人员才能进行配置和修改，从而保障系统的安全和稳定。

4. 银行卡代扣通道接入的“实战演练”

4.1 接入背景

为了给客户提供更快捷、更优秀的支付体验，我们团队决定开发上线一项银行卡代扣支付功能。这项功能将允许用户实现账单的自动代扣支付，免去繁琐的手动操作，大大提升便利性。经过公司领导层商议，我们决定接入某协议支付通道来实现这一目标。

4.2 研读接口文档，洞察其“奥秘”

4.2.1 接口调用“路线图”

通过仔细研读接口调用流程说明，我们了解到，要完成银行卡代扣支付，需要分两步走，首先是“签约”，然后才是“扣款”。第一步，需要调用“协议签约接口”发起签约请求，通道方会向用户手机下发短信；用户收到短信后，输入验证码，再调用“协议签约短信验证接口”进行验证，验证通过后，签约就完成了。第二步，我们可以凭协议签约成功后返回的信息（即“签约号”）发起“协议扣款”，通道方会同步返回交易状态。弄清楚这个清晰的流程后，我们继续细看接口文档的具体细节。

4.2.2 签约环节，解锁支付权限

(1) 协议签约接口
这个接口主要用于发起协议签约申请，成功发起后，通道方会给持卡人的手机发送一条验证短信。我们注意到，这条通道在申请协议签约时，需要上送一个“银行编码”，而且这个编码必须符合该通道的定义标准。看到这里，我们立刻联想到两个关键问题：第一，用户进行银行卡签约时，需要识别这张卡属于哪个银行，这就引出了我们后面要讲的“卡bin模块”；第二，不同的无卡支付通道，其银行编码标准可能存在差异。这时，我们之前设计的通道属性和特征，以及通道银行编码的对应维护就显得尤为重要了。

这里再补充一点，有些通道在签约信用卡时，需要用户输入信用卡的CCV码和有效期。而我们当前对接的这条通道则不需要这些信息。因此，用户端（前端）的签约页面也需要根据所选通道的不同，进行相应的路由和展示，这也进一步印证了通道管理和维护的精细化是多么重要。

调用签约申请接口后，合作方会给持卡人手机发送短信，同时接口会返回一个“令牌号”，用于后续的短信验证。

(2) 短信验证接口
用户收到短信验证码后，将其输入到前端页面，系统会将验证码和之前获取的“令牌号”一起上送给短信验证接口。验证通过后，就意味着签约成功，系统会获得对应的“协议号”，这也是后续进行扣款的关键凭证。

4.2.3 扣款与退款，资金的“进出”之道

(1) 扣款接口
拿到签约协议号后，我们就可以依据这个协议号发起扣款操作了。在接口说明中，我们需要特别留意“交易金额”这个字段，它的单位是“分”，务必搞清楚，否则可能酿成大错。另外，文档中还会提到一个“后台通知地址”，这是我们在发起扣款交易时，指定的一个接收交易结果通知的地址。当交易有最终结果后，通道方会按照这个地址将结果告诉我们。更严谨的通道方甚至会要求接入方对通知进行响应，并且会有一套完整的通知策略，以确保信息不丢失。

发起扣款之后，我们最关心的就是扣款是否成功。但响应信息通常会明确说明“操作成功仅代表请求成功，不代表交易成功”。因此，这里要重点强调：支付状态一定要有“支付中”这个中间状态！同时，还要对“支付中”状态设计相应的补偿机制，否则很容易发生线上交易事故。当你发起一笔交易，但在尚未收到通道方的最终结果之前，这笔交易就处于“支付中”状态。等到有回调结果或我们主动查询后，再根据结果更新状态。另外，我们还要关注单笔交易是否有最低金额限制，以及通道的最大并发量是多少，是否支持多线程操作。

顺便提一嘴，最好建议开发同事在封装支付和退款接口时，即使接入了许多不同的通道，也要尽量封装成一个统一的下单接口和回调接口供业务层调用，这样可以避免很多不必要的麻烦。此外，务必提醒前后端同事们记得做好“防抖”处理，防止用户重复提交订单！

(2) 退款接口
退款接口的逻辑与扣款类似，同样需要注意“金额单位是分”。退款操作也必须引入“退款中”状态，其重要性与扣款环节的“支付中”状态相同，此处不再赘述。这种“原路退回”的退款方式，通道方会做好严格的校验，一般不太可能出现一笔支付多退了钱的情况。我们需要重点关注的是：退款的时效是多长（有的合作方会限制交易半年或一年后就不能退款）、是否支持部分退款、以及同一笔支付能否多次发起退款等问题。

4.2.4 响应码，交易的“晴雨表”

一般的支付响应码会分为“公共响应码”和针对不同接口的“业务响应码”。这里建议前期梳理出一些常见、通用的响应码，并将其“翻译”成用户能读懂的文字，以便在前端页面进行展示。此外，为了方便定位问题，可以在报错类的提示信息前面加上通道合作方的英文缩写。例如，如果我们公司内部定义为“DM”，某通道方定义为“通道方A”，那么报错内容可以展示为“通道方A：交易失败，请稍后再试”，这样就能快速定位到是哪个通道方出了问题。

4.3 功能规划，让系统“有条不紊”

4.3.1 用户端签约，便捷体验从这里开始

考虑到用户的操作体验，在用户绑卡签约时，最好能实现自动识别卡号，并自动匹配所属银行，而不是让用户手动输入和选择。这就需要我们引入“银行卡OCR识别”功能。通过OCR技术识别出卡号后，还需要一个“卡bin模块”来匹配该卡号所属的银行以及银行卡的类型（如储蓄卡、信用卡），这样才能根据通道方的要求，准确上送银行编码和卡类型。具体的用户端交互体验，大家可以参考支付宝、微信等主流产品的设计。

此外，为了应对OCR识别可能出现的误差，建议在用户端保留手动选择或更改银行卡所属银行的功能，避免因识别错误导致用户无法顺利签约。

4.3.2 卡bin管理，银行卡的“身份证信息”

卡BIN，全称银行识别码，是银行卡的一种编码方式。它通常由6到9位数字组成，通过卡BIN的前几位数字，我们就能识别出这张卡所属的银行、卡的种类（如借记卡、贷记卡）以及卡的国际标准组织代码等信息。卡BIN在银行卡处理流程中非常重要，可以用来验证卡的有效性，确定卡的类型及所属银行等关键信息。国内的卡表信息通常可以从通道方获取。

经过数据清洗和整理后，提取出我们所需的信息，一套银行卡中心的“卡BIN管理系统”就初步搭建起来了。更专业的公司甚至会配置卡BIN对应的银行图标，并将通道与卡BIN进行匹配关联维护，从而实现对通道所支持能力的更加精细化管理。

有了卡BIN数据后，我们就能根据用户输入的银行卡号，自动匹配该卡所属的银行。匹配逻辑可以这样设计：
首先，使用 Luhn 算法（也称莫迪法）校验银行卡号的正确性。如果校验不通过，可以提示用户检查修改卡号。Luhn 算法的原理是：从银行卡号的倒数第二位数字开始，每隔一位数字（即从右往左的偶数位）乘以2。如果乘积大于9，则将乘积的两个数字相加（例如12变成1+2=3）。然后，将所有处理后的数字与未处理的奇数位数字全部相加。如果最终的总和能被10整除，则银行卡号有效，否则卡号无效。

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

银行卡号通过Luhn算法检测正确后，我们就可以从10位开始遍历卡BIN表，然后依次递减至6位，直到找到唯一匹配的卡BIN信息为止，并返回该卡BIN对应的银行卡信息和所属银行。（目前国内银联卡因银行众多，特别是村镇银行的存在，BIN长度以6位占绝大部分，但也存在7、8、9、10等位数的卡BIN）。如果要更严谨，还可以同时匹配银行卡号的长度是否对应得上。

4.3.3 银行管理，内部标准的“制定者”

银行管理模块用于维护企业自己系统的标准银行及其编码。为什么要建立自己内部的标准呢？还记得我们前面说过，不同的通道可能存在不同的银行编码标准吗？如果我们接入了多个通道，它们各有不同的银行编码标准，那么我们就可以根据自己系统的卡BIN信息，先匹配到我们内部的标准银行编码，然后再将这个标准编码映射到不同通道所要求的编码。再者，即使在没有接入多个通道、无需复杂路由的初期，哪些银行的储蓄卡、信用卡支持签约代扣，也可以在此处进行维护管理。这样，当前端识别到不支持的银行时，就可以直接提示用户更换银行卡，提升用户体验。

4.3.4 签约记录，交易的“账本”

签约记录是方便运营和客服人员核实某个用户某张银行卡的签约状态的关键。这对于解答用户的咨询和对外合作都至关重要。签约数据结构可以根据实际场景来设计，一种是以“卡号+商户”为维度，另一种是以“用户+卡号+商户”为维度。两者的灵活性不同。举个场景：一个车队老板名下挂靠了多辆车，分别由不同司机管理，但都使用老板或公司的账户签约代扣ETC通行费。如果某个司机离职了，如果签约结构是“卡号+商户”，那么把离职司机的签约关系解绑后，老板名下所有车的签约关系可能都会被解绑。而如果结构是“用户+卡号+商户”，则可以更精细化地管理。

关于签约数据，我建议从一开始就让开发团队维护一份独立的、统一的“通道签约数据层”。这份数据层专门用于记录银行卡或账户信息在不同通道上的签约或验证结果，以便支付路由层和其他业务场景可以据此进行重新签约或智能支付路由。如果业务线各自维护签约数据，就可能出现比较尴尬的现象。以我们公司为例，我们有客车和货车两条业务线，但同一个用户同一张银行卡可能同时办理了客车和货车的业务。如果签约数据各自维护，当有新的签约关系产生时，通道方旧的签约号就可能失效，导致失效的那条业务线对应的用户扣款失败。

同一张卡的签约策略也值得仔细考究。例如，通道方是否允许重复签约？重复签约会返回什么样的结果？这些都需要提前搞清楚。然后，基于企业自身考量，当出现重复签约时，是自己内部走个验证即可，还是重新上送通道方进行签约？这些也都需要周全考虑。如果通道方没有限制，个人倾向于重新上送通道方进行签约，这样可以及时更新可能已过期的签约号。有了统一的签约数据层，同一张卡我们甚至可以根据业务需求，在用户不同的绑卡场景下判断是否要走另外的通道进行签约，从而为同一张卡增加多一个扣款通道的备选项，提高业务的韧性。