1. 写在开头
支付是社会经济活动所引起的货币债权转移过程。从流程环节的角度来看，包括三个基本过程：交易、清分、结算。而如果从宏观的整体架构的角度出发，可以分类为三大功能域：1. 交易信息的处理（信息流） 2. 支付指令的处理（信息流和资金流的衔接） 2. 资金账务的处理（资金流）。
无论是站在支付流程环节的看支付还是站在宏观的整体架构的角度看支付，支付渠道都是其中的重要一环，堪称支撑数字支付服务的基石。
作为第三方支付机构而言，由于自身不属于银行范畴，无法触及操作真正的资金流动，其支付所需的真实货币债权转移过程需要通过与其合作的银行渠道实现，同时出于扩展自身支付服务方式多样性的角度考虑，也需要和外部的其他银行或者三方支付机构合作，接入其支付服务能力。由此来看，支付渠道对于支付机构而言的重要性不言而喻。
既然对于支付机构而言支付渠道如此关键，那么对支付渠道的全流程、全生命周期、全方位能力进行合理高效的管控就显得尤为的重要，直接决定了支付机构能否做大做强。
文章接下来会从渠道的核心能力范围、渠道管理域的整体架构设计、渠道管理的一些通用设计思路三个维度，从整体的角度聊一聊渠道管理该如何设计和演进。
2. 支付渠道的核心能力
对一个技术概念进行维护和管控的必要条件是了解该技术概念的核心功能和作用，而要初步了解一个技术概念的核心功能和作用最好是从实际案例出发，分析实际案例背后所发生的数字业务活动，了解技术概念在其中发挥的作用，从而对该技术概念的功能作用进行总结和提炼。
体现到支付渠道的核心能力理解上面来，实际的案例如下：
- 英国的Mike同学在跨境电商平台上看中了某欧洲商家的一双皮鞋，标价100欧元，随即下单，在支付机构上选择了VISA信用卡支付，支付了87英镑买下了这双皮鞋。
- 商家在收到交易完成通知后，将皮鞋进行发货。
- Mike在一周后收到了皮鞋，商家在一个月后收到了跨境电商平台的结算打款，收到了扣除结算手续费后的99欧元。
从中可以总结出以下支付渠道的核心能力：
-
渠道咨询能力，支付机构在展示支付收银台时，会对支付渠道进行咨询，咨询可用的支付渠道，从而对支付收银台进行渲染。
-
渠道决策路由能力， Mike在进行支付的过程中，支付机构发现有多个下游支付渠道都支持VISA信用卡的支付受理，此时支付机构需要通过渠道路由决策能力决策出最合适的下游支付渠道，受理支付需求。
-
渠道支付能力， 无论是Mike支付87英镑，还是商家收到的99欧元的结算打款，都需要支付结构对接下游渠道的支付接口，完成整个支付交易的过程。
-
汇兑能力， Mike支付了87英镑，而商家的结算打款却是99欧元，英镑到欧元的兑换需要支付机构对接下游的外汇机构，通过汇率的查询、锁汇、换汇等能力实现多币种兑换，完成跨币种的支付交易。
-
清算能力，Mike通过VISA信用卡完成了87英镑的支付后，支付机构会收到来自下游支付渠道的清算文件，其中包含了Mike本次交易的交易明细，支付机构会将渠道的交易明细和内部的交易明细进行对账，对账完成后，才会将款项入账至商户的待结算账户，在结算周期结尾打款给商户。
以上即为渠道管理域所涉及的渠道核心能力范围。可以看到渠道作为核心资产，其衍生出来的各种能力横跨信息流和资金流以及离线数据流，几乎遍布整个支付全链路，其重要性不言而喻。因此渠道管理的架构设计的合理性和完整性就显得尤为重要，是支付机构最核心的架构域。
3. 支付渠道的架构设计
架构的本质其实就是关系梳理和功能分类。
要构建合理的支付渠道域架构其实就是对渠道的核心能力进行分类整合，同时考虑非功能性层面的运营运维能力的设计，即渠道核心功能架构 + 渠道运营运维架构 = 支付渠道架构。
3.1. 渠道核心功能架构
渠道的核心功能在此前已有详细介绍，如果需要针对渠道核心功能进行架构设计，首先需要支付渠道核心功能进行分类和整合。
3.1.1. 读写分离
按照技术维度的读写分离的架构思想进行初步分类，即可分为：
-
支付渠道咨询架构，仅涉及支付渠道的查询，不涉及实际和下游渠道的通讯交互
-
支付渠道交互架构，与支付渠道进行实际的联机交互，包括渠道支付、渠道汇兑、渠道清算文件交换以及其前置动作——渠道决策路由。
3.1.2. 主链路与旁路分离
对于支付渠道的交互架构，根据主链路和旁路的区别主要可以分为两类：
-
支付主链路的渠道联机交互，主要涉及渠道路由决策、渠道支付、渠道汇兑能力，此类交互直接影响了支付成功率，是支付渠道能力中的“重中之重”。
-
支付主链路之外的渠道文件流交互，此类文件流的传输主要涉及支付机构和渠道之间的文件交互，例如渠道侧下发给支付机构的清算文件，其不属于支付主链路的组成部分，不会直接影响支付成功率，同时其文件流处理模式与支付主链路涉及的HTTP或者RPC通讯模式有着较大区别，所以无论从风险级别还是交互模式出发，都需要将文件处理能力和联机交互能力进行拆分。
3.1.3. 整体架构设计
通过读写分离、主链路与旁路分离的分类整合思想进行支付渠道核心功能架构的解构与构建，可以衍生出以下三大平台应用：
-
渠道核心交互中心，主要受理对于下游渠道的核心交互指令，对接下游各类渠道实现支付机构所需的各种核心服务功能。
-
渠道文件流处理中心，主要负责接收和上传各类渠道侧和支付机构之间的文件内容，实现支付主链路之外的各类异步旁路能力。
-
渠道能力中心，主要负责支付机构的渠道功能管理和维护，并对外提供渠道的咨询服务，以及作为渠道路由决策的渠道信息支撑。
3.1.4. 架构关系梳理
通过核心功能的分类完成架构设计后，需要对各个应用平台的依赖关系进行梳理，从而验证整体架构设计的合理性。关系的梳理需要从业务场景入手，下面通过支付扣款、交易清算、渠道咨询三个核心场景对整体的渠道核心功能架构关系进行说明。
3.1.4.1. 支付扣款
3.1.4.2. 交易清算
3.1.4.3. 渠道咨询
通过以上场景梳理，可以看出渠道能力中心是渠道核心功能域的渠道参数管理中心，主要负责向上提供渠道基本的领域信息，以维护“渠道”这一最为核心的领域资产。而渠道核心交互中心以及渠道文件处理中心主要负责围绕渠道能力中心以核心链路和旁支链路的维度分别构建渠道的服务能力具体关系如下所示：
3.2. 渠道运营运维架构
支付渠道的核心功能架构并不能覆盖渠道管理的全生命周期，除此之外，渠道运营和渠道运维也是支付渠道管理的重要一环。
渠道运营主要针对于渠道的一站式的全流程接入能力，包括渠道的机构入驻、机构接口登记、机构角色和产品能力的登记和管理，主要的面向对象是渠道产品运营人员/渠道BD/以及相关技术研发。
渠道运维主要用于渠道接入后的长尾维护工作，主要负责维护渠道的稳定性、可用性，包括渠道的开关控制，渠道的状态检测控制等。
3.2.1. 渠道运营
渠道运营作为对于渠道这一核心资产的集成接入和信息管理模块，主要由渠道DB、运营、产品人员以及部分业务一线研发人员所使用，因此，打造一个完整、易上手、稳定的渠道一体化运营平台是渠道运营高效化、规模化、标准化的必要条件。
如果将渠道运营的功能需求进行细化，大致分为以下三大部分
- 渠道标准化集成，打造从需求受理、合约签署、接口集成、到功能验收的标准化渠道接入流程
- 渠道视图，对支付机构的完整渠道资产大图进行全方位的可视化管理，全面看清支付机构的能力范围
- 渠道路由管理，打造渠道的运行时路由规则引擎，实现支付渠道的高可用路由决策能力
渠道一体化运营平台从上述三个部分对渠道能力中心的渠道资产进行管理和维护，完成渠道运营全流程。
3.2.2. 渠道运维
渠道运维区别于渠道运营的地方在于两者的服务对象有着本质上的区别，渠道运营主要面向于渠道资产这一核心领域模型的管理和维护。而渠道运维主要关注于渠道的运行状态，目的是保证渠道在运行时的稳定性和可用性，以及业务处理异常场景下的人工介入处理，从而维持支付机构服务能力的成功率高水位。
常见的渠道运维手段如下所示：
- 故障应急能力，在下游渠道出现故障时能通过主动关闭渠道开关或者基于自动检测弹性开关渠道的方式进行故障应急。
- 差错处理，因网络异常、系统故障、账户问题或规则限制等导致交易失败、资金异常或状态不一致时，通过人工介入的方式对此类问题进行分析，修复和补偿。
- 渠道保护能力，在日常大流量或者大促尖刺流量场景下通过支付缓冲或者限流等能力对下游渠道进行保护。
- 支付监控大盘，对支付成功率、支付总量等支付系统指标进行全方位监控分析，从而能够第一时间发现问题，应对问题。
渠道运维平台需囊括主要的渠道运维能力，由渠道的技术研发人员和技术运维人员对渠道的运行时状态进行维护、应急以及人工介入。
