2. 多银行付款基础
在动手设计付款路由之前，必须先建立一张“资金地图”：钱从企业账户出发，经过哪条通道、落到哪个清算网络、最终到达收款人账户。很多路由事故并非算法问题，而是对账户体系与通道边界理解不清。本节把多银行付款的底层要素拆成四块：账户、通道、清算网络、业务场景与术语。
一、核心原理：账户体系是路由的“起点坐标”
企业付款的起点不是“公司”，而是具体的银行账户。一个企业通常持有多个账户，它们分属不同银行、不同城市、不同币种，并承担不同用途。理解账户体系，关键看三个维度：
- 账户归属层级：基本户、一般户、专用户、临时户。基本户可办理日常转账与现金收付，一般户可转账但通常不能取现，专用户用于特定用途资金管理。
- 账户物理位置：开户行、开户网点、联行号（CNAPS）、大额行号、小额行号。路由时若填错联行号，付款会被退回或挂账。
- 账户能力标签：是否支持对公、是否支持跨行、是否支持实时、单笔限额、日累计限额、是否允许代付。这些标签直接决定一条路由是否可用。
支付通道则是企业连接银行的“接口形态”。常见有四类：银企直连（前置机/专线）、银行开放平台API、第三方支付机构代付、以及银联/网联等清算通道。通道不是越多越好，而是要看其覆盖的银行范围、到账时效、限额与失败返回码是否可解析。
通道选择的第一原则：先看“收款行是否在通道覆盖名单内”，再看“金额是否在限额内”，最后才比较费率与时效。顺序颠倒会导致大量无效请求。
二、方法流程：一笔付款如何穿过通道与清算网络
以企业向供应商跨行付款为例，典型链路如下：
- 业务系统生成付款指令，包含付款账户、收款账户、金额、用途。
- 路由模块根据收款行、金额、时效要求，选择一条可用通道。
- 通道适配层将指令转换为该通道的报文格式（如银企直连XML、开放平台JSON）。
- 付款行受理后，通过行内系统进入清算网络：大额实时支付系统（HVPS）、小额批量支付系统（BEPS）或网上支付跨行清算系统（IBPS/超级网银）。
- 清算网络将资金划至收款行，收款行入账并返回回执。
- 企业系统根据回执更新付款状态：成功、失败、处理中、退票。
其中，清算网络决定了到账时效与金额上限。大额系统实时全额、单笔无上限（受行内限额约束）；小额系统批量、有金额上限、定时清算；超级网银支持实时跨行且7×24小时，但单笔限额通常较低。路由策略必须把“清算网络能力”作为硬约束。
三、案例/场景：三种典型付款场景的通道差异
不同业务场景对通道的要求差异很大，下面用清单对比：
| 场景 | 典型金额 | 时效要求 | 推荐清算网络 | 通道关注点 |
|---|---|---|---|---|
| 供应商货款 | 大额、批量 | 当日到账 | HVPS 大额实时 | 限额高、回执明确、支持批量文件 |
| 员工报销 | 小额、高频 | 准实时 | IBPS 超级网银 | 7×24、单笔限额、失败码可解析 |
| 平台商户分账 | 小额、海量 | 批量定时 | BEPS 小额批量 | 批量代付、手续费低、支持汇总回执 |
例如某电商平台给入驻商户分账，单笔平均80元、日均20万笔。若走大额实时通道，成本高且无必要；走小额批量通道，虽然到账为T+0定时，但成本可控、批量文件处理效率高。这就是“场景决定通道”的典型判断。
四、误区/复盘：常见术语与踩坑点
多银行付款中，术语混淆是高频事故源。以下术语必须分清：
- 联行号 vs 行号：联行号是12位CNAPS号，用于跨行清算；行号可能是银行内部编号，两者不可混用。
- 退票 vs 失败：失败是通道未受理；退票是已受理但收款行无法入账，资金原路退回，状态需单独处理。
- 处理中 vs 成功：很多通道返回“已受理”不等于到账，必须等最终回执，否则会重复付款。
- 限额：分单笔、单日、单月，且银行侧与企业侧限额取小值，路由前必须校验。
常见误区：把“通道可用”等同于“一定能付成功”。实际上收款账户状态（冻结、销户、户名不符）也会导致退票。路由只能解决“走哪条路”，不能解决“收款方是否可入账”。
复盘建议：为每条通道建立“覆盖银行清单+限额表+失败码字典”三件套，并定期更新。路由策略的准确性，80%取决于这三份基础数据的维护质量。
掌握账户体系、通道能力、清算网络边界与业务场景匹配关系后，后续的付款路由算法与通道切换策略才有可靠的输入。基础数据越清晰，切换时的决策就越稳定。