支付渠道的资产建模支付渠道网络的核心资产是渠道建模，支付过程中，从支付机构到下游银行机构的金融资产交换、资金清算都是基于

序言

在任何一个互联网业务领域内，领域建模永远是构建互联网技术架构的关键一环，其代表着真实社会中的各类商业活动在计算机信息数字化领域内的抽象映射。建模作为业务系统API服务的支撑基础，合理而精确地构建业务领域模型往往能对业务系统架构的演进正确性起到至关重要的作用。

学习一个互联网业务领域首先学习其核心资产的领域建模，即资产建模。核心资产就是该业务领域存在的意义，简单来说即为该业务领域带来核心价值利益的资源。识别该业务域的核心资产及其建模理论就能完整全面的认识该域的对外价值所在及其内部的运作原理，例如支付业务中的支付方式之于收银系统，商户结算合约之于结算系统，抑或是本文介绍的渠道建模之于支付渠道网络。

支付渠道网络的核心资产是渠道建模，支付过程中，从支付机构到下游银行机构的金融资产交换、资金清算都是基于渠道领域建模进行构建的。本文将帮助读者正确理解渠道的建模结构和原理，从而对支付核心链路中收单、支付、渠道中的渠道环节能够有更加深入的理解。

业务活动剖析

了解数字业务领域内核心领域资产如何进行构建，不如回到现实社会中该业务领域所对应的真实商业活动中，看看其在真实世界中是如何进行运作的，从而推演到到线上的互联网数字领域内，该如何将真实的商业活动准确映射为计算机语言，构建该业务活动的“线上化版本”。

还是拿英国同学Mike的例子举例：

英国的Mike同学在跨境电商平台上看中了某欧洲商家的一双皮鞋，标价100欧元，随即下单，在支付机构上选择了VISA信用卡支付，支付了87英镑买下了这双皮鞋。
商家在收到交易完成通知后，将皮鞋进行发货。
Mike在一周后收到了皮鞋，商家在一个月后收到了跨境电商平台的结算打款，收到了扣除结算手续费后的99欧元。

英国的Mike同学在跨境电商平台上看中了某欧洲商家的一双皮鞋，标价100欧元，随即下单，在支付机构上选择了VISA信用卡支付，支付了87英镑买下了这双皮鞋。

商家在收到交易完成通知后，将皮鞋进行发货。

Mike在一周后收到了皮鞋，商家在一个月后收到了跨境电商平台的结算打款，收到了扣除结算手续费后的99欧元。

从中可以总结出以下和支付渠道相关的核心业务功能。这些功能可能会直接影响渠道的建模设计，以实现在计算机世界表达此类业务功能。

渠道咨询能力，支付机构在展示支付收银台时，会对支付渠道进行咨询，咨询可用的支付渠道，从而对支付收银台进行渲染。
渠道决策路由能力， Mike在进行支付的过程中，支付机构发现有多个下游支付渠道都支持VISA信用卡的支付受理，此时支付机构需要通过渠道路由决策能力决策出最合适的下游支付渠道，受理支付需求。
渠道支付能力， 无论是Mike支付87英镑，还是商家收到的99欧元的结算打款，都需要支付结构对接下游渠道的支付接口，完成整个支付交易的过程。
汇兑能力， Mike支付了87英镑，而商家的结算打款却是99欧元，英镑到欧元的兑换需要支付机构对接下游的外汇机构，通过汇率的查询、锁汇、换汇等能力实现多币种兑换，完成跨币种的支付交易。
清算能力，Mike通过VISA信用卡完成了87英镑的支付后，支付机构会收到来自下游支付渠道的清算文件，其中包含了Mike本次交易的交易明细，支付机构会将渠道的交易明细和内部的交易明细进行对账，对账完成后，才会将款项入账至商户的待结算账户，在结算周期结尾打款给商户。

对渠道涉及到的核心业务功能进行整合分类，主要可以分为以下三类：

咨询链路，主要负责对机构支持的渠道进行收银台咨询或者进行资产交换前的路由查询，属于资产查询链路。
信息流链路，和下游的渠道机构进行指令的联机交互，以支持支付、汇兑等业务服务，属于资产在信息流层面的操作链路。
资金流链路，渠道主要负责以文件交互的方式进行资金流处理。在进行资金清算时，渠道侧在接收到外部渠道的清算文件后，会对文件进行规则解析，并将解析出的清算明细投递给资金域进行清算对账。

渠道的领域建模需对于渠道涉及的核心业务能力——渠道咨询、渠道信息流交互、渠道资金流交互进行实体和实体关系的支持，接下来将通过对渠道操作链路——资金流、信息流以及渠道咨询链路的实体关系的分析，以对渠道建模进行理论支撑。

渠道建模实体关系

【操作链路】三机构模型

三机构原理

着重分析支付机构和下游渠道在操作链路层面的交互模型，大概涉及到三个渠道机构实体，如下图所示：

完整的一次外部渠道调用，从调用外部机构的集成接口开始，到清算文件异步通知回执支付机构结束，由信息流和资金流共同构成支付链路数据流的闭环。其中一共会涉及到三个角色：

集成机构，提供系统集成转接服务。支付机构调用外部某个渠道的支付能力的时候，有时不会进行直连的方式直接联机调用该渠道，而是调用第三方的集成转接支付机构，由该集成机构转接至下游的目标渠道机构。例如Alipay通过集成机构Cybersource接通VISA卡组渠道，此处Cybersource就是担任集成机构的角色。
业务机构，承担业务提供方角色的机构，也称之为目标机构。该机构为本次支付服务真正的提供方，向支付机构提供支付、汇兑等服务能力。
资金机构，承担资金清算角色的机构。在支付链路中提供资金清算的服务，负责处理支付机构侧的资金流动，归集资金。

三机构共同构成一个支付渠道调用的完整闭环，当然，在一些简单场景下，集成机构和业务机构可以是同一个，例如机构直连场景；资金机构也可以和业务机构是同一个(大多数情况下都是这样），例如对于某些持有收单牌照的收单机构。但从完整性和通用性的角度考虑，在领域建模层面三机构是相互解耦的，是三个独立的模型实体。

所以，当我们在谈论外部渠道的时候，其实它不仅仅单指某个提供支付服务的外部机构，而是由三个担任不同角色的机构组成的——集成机构、资金机构、业务机构，以上三个机构共同构成一个完整的外部渠道。即渠道的三机构模型。

三机构视图

根据三机构模型——基本可以推出以下渠道的建模初版视图，该图主要描述了支付渠道组成结构。

【操作链路】渠道合约

渠道合约介绍

渠道由三机构构成，那在技术领域如何对与各类机构之间的交互方式进行定义和描述呢？此处主要依赖于渠道合约。渠道合约，即支付机构和外部机构签约而形成的业务约定。该业务约定决定了支付机构和外部机构之间的交互模式，以及交互所需要的关键参数。

渠道合约结构

根据外部渠道的三机构模型，渠道合约也可以分为三个部分：

集成机构合约，定义了支付机构和外部机构的集成方式相关信息，例如我方角色信息（主体、模式等）、渠道角色信息（主体等）、收款方账户信息等。
业务机构合约，定义了外部机构所提供的业务服务能力明细，例如业务机构提供的支付能力明细（支持哪些支付方式）、退款能力明细（退款的方式和细则）等。
资金机构合约，定义了外部机构和支付机构之间的清算交互信息，例如清算周期信息、清算币种信息、清算方式等。

渠道合约视图

引入渠道合约后，可以在初版渠道建模视图的基础上增加渠道合约部分，描述渠道和机构之间的交互配置信息。其中，物理渠道和渠道合约之间为1:N的关系，整体上有以下两个一对多关系：

渠道多主体复用，由于渠道可能在支付机构的多个业务线进行复用，使用不同的业务主体，每个主体签约一份合约，就会存在一个物理渠道对应多渠道合约的情况
渠道多交互模式，渠道可能支持多种业务交互模式——收银台支付、订阅制扣款等，不同的业务交互模式需要不同的合约信息进行支撑，也会存在物理渠道和合约的一对多场景。

【操作链路】逻辑渠道和物理渠道

逻辑渠道和物理渠道区分

无论是三机构模型还是渠道合约，其实都是在支撑的支付链路中的“最后一公里”，即我们如何去描述和定义一个外部机构，以承载外部机构和支付机构之间的信息流交互能力并对海量的下游机构进行管理。但其实对于渠道域而言，外部机构的定义和管理只是其中的一部分，还有另一部分非常重要的问题等待我们去回答——即对于我们支付机构内部的渠道相关系统而言，如何描述和通用化编排对接下游支付渠道的交互流程，达到封装渠道差异性，构建渠道产品，实现渠道标准化调用和接入的目的。如下图所示：

为了处理支付机构和支付渠道之间的业务流程和调用关系，此处我们引入逻辑渠道和物理渠道的概念。

物理渠道，即定义支付渠道的实体，是支付渠道的“自身画像”。描述了这个渠道的业务属性和集成信息，例如上文提到的渠道三机构、渠道合约等物理渠道的相关概念，都是其组成部分。
逻辑渠道，即对于物理渠道的产品化构建，结合支付机构内部的系统设计，丰富了技术要素，对物理渠道进行“充血”，在渠道基本属性的基础上进一步描述了外部渠道在全球支付渠道网络各系统内的标准化业务流程、接入规范等、资金清算规则等信息，实现渠道的标准化、高效化、规模化接入。

由于一个物理渠道支持多种渠道交互模式（例如订阅制扣款、卡支付等），每种渠道交互模式都需要一个逻辑渠道描述其业务交互的关键参数。因此整体上物理渠道和逻辑渠道之间呈现1:N的关系

逻辑渠道原理

物理渠道在上述的三机构模型、渠道合约中已有详细介绍。下面重点介绍逻辑渠道，逻辑渠道主要定义由三部分业务信息构成：

信息流交互参数，描述了支付、汇兑、转账等指令的业务流程。
资金流参数，描述了资金流清算链路的文件解析和文件消息投放流程。
渠道集成参数，描述了和外部渠道的接口集成格式明细和文件交换格式明细等。

逻辑渠道的三部分，信息流参数用于描述业务机构提供的服务的交互流程、资金流参数用于描述资金机构的清算文件解析方式和投放方式、渠道集成参数用于描述集成机构的集成配置信息包括接口配置、文件交换格式、密钥信息等。以上三部分参数将三机构和渠道域的业务系统进行深度结合，详细描述了外部渠道在渠道域内部的集成和使用方式。

逻辑渠道的核心原理为关键参数的配置化，通过抽象业务流程中的关键参数并对参数进行配置化，从而实现标准业务模式的沉淀，渠道和渠道之间的交互区别仅体现在配置参数的不同上，从而构建出逻辑渠道的概念，达到以逻辑渠道描述渠道的交互模式和流程的目的。

逻辑渠道的本质就是高可读性的配置组，以通过配置组还原整个和外部渠道相关的所有业务流程和集成信息。

如何描述信息流交互

对渠道进行信息流交互流程的实现方式有很多，例如：

硬编码方式，每个渠道的每种业务交互流程均通过硬编码的方式进行执行，此为最原始的渠道信息流管理模式，是最低效渠道接入方式。
脚本化编程，使用脚本化的编程语言进行渠道交互脚本的编写并通过统一的脚本执行引擎进行管理，此种方式相较于硬编码会灵活很多，同时渠道的接入速度会因脚本化的敏捷开发特性而提升不少，但由于过于灵活也会导致疏于管理。
流程编排， 基于流程编排引擎进行流程编排，抽象出各个业务交互场景（即时支付、订阅制扣款、扫码扣款等）常用的流程节点封装成流程组件，根据不同的渠道特性进行流程组件的灵活组装。这种方式相较于硬编码保留了灵活性和可维护性，同时又不会因为脚本化编程导致的过于灵活而疏于管控，是目前较为主流的渠道信息流交互方式。

虽然渠道信息流交互的实现方式有很多，但不影响的逻辑渠道目的和价值，即描述渠道交互流程并以此实现渠道交互高效化、规模化、标准化管理。无论使用哪种交互实现方式，逻辑渠道的概念都不能少，无非是逻辑渠道的构建手段的区别。若为硬编码方式，逻辑渠道的渠道交互部分可能就仅由一个服务ID组成；若为脚本化编程，可能是整个渠道交互脚本；若为流程编排，那就是流程组件的列表。

如何描述资金流解析

资金流部分渠道域主要涉及到资金清算文件的解析，并将解析完成的清算明细投递至资金域发起资金清算流程。对于一个成熟的渠道资金清算文件解析系统而言，文件的解析规则需要以配置化的方式进行管理，以保证资金文件解析的系统流程的可复用性，此时就引出了逻辑渠道除描述信息流交互之外的另一大作用——描述渠道资金链路的业务交互流程（渠道域内）。

渠道域内资金流的交互逻辑不像信息流那般灵活多变，主要涉及两个部分——文件内容解析、文件消息投放，目的是将外部渠道的各类文件例如清算文件解析成文件消息，投放至其他业务域进行业务处理（例如将清算文件消息投放至清算域进行资金清算）。

基于以上渠道域资金流的交互链路，可以得到逻辑渠道需要描述的关键能力。

文件解析，基于文件解析规则对文件进行解析。
消息构建，将文件解析结果通过消息模版构建成文件消息，投递至下游进行消息处理。

由此得到逻辑渠道的文件解析部分视图

如何描述渠道集成参数信息

渠道集成主要分为两种方式：

接口集成，主要适用于流入渠道，例如支付、扣款等场景，通过与下游渠道之间的联机接口交互完成业务服务。
文件交换，主要适用于流出渠道、汇兑渠道，对外资金转账和换汇的发起通常通过文件交换的方式异步发起。

逻辑渠道在渠道集成参数信息的描述上，主要需要管理渠道网络和外部渠道之间的接口集成必要配置信息以及文件交换的格式相关信息，以实现和外部渠道的指令互通。

在接口集成配置信息部分，主要涉及接口配置的结果码映射、字段映射、密钥管理、加密解密算法等配置资产。

在文件交换格式信息部分，主要涉及文件构建模版、文件批处理规则等文件交互能力。

综上，逻辑渠道在渠道集成描述上的视图如下：

逻辑渠道和物理渠道视图

结合逻辑渠道和物理渠道的完整结构，可以得到在渠道的操作链路上一个较为完善的模型视图，涵盖了渠道自身结构定义到渠道各个业务场景下的流程关系以及渠道集成到金融渠道网络所需的必要规则配置，对于渠道在操作链路上的能力和结构关系有了全方位的覆盖。

【咨询链路】支付方式

渠道咨询链路要从收银域的支付方式建模聊起，支付方式和支付渠道息息相关，甚至部分支付公司的技术架构直接将支付方式归位于渠道网络域。了解支付方式，首先需要回答为什么为什么要在渠道的基础上封装出支付方式，渠道和支付方式的区别在哪？首先我们从一个新概念——目标机构谈起。

什么是目标机构

渠道作为支付机构的支付业务的基础能力提供方，其核心职责在于“通路”，即一条支付机构到下游目标机构的支付通路，能够通过该渠道进行服务执行。

此处为了更好的描述“通路”，需要引出一个新的概念——目标机构，即一次支付发起的真正调用目标。

举个简单的支付交易案例——Mike通过Alipay使用VISA进行支付。此处，Alipay就是支付机构，而VISA就是支付的目标机构。通常情况下，目标机构即渠道，即目标机构和渠道是同一个外部机构。例如这个例子中的VISA就是Alipay的卡组渠道。

但在某些场景下，目标机构并不是渠道，例如小王在东南亚电商购买了一双鞋，该电商平台对接的收单机构是Adyen，小王支付时选择的支付方式是支付宝，而Adyen是通过对接外部支付渠道机构Antom进行支付宝付款的。

在这个case里，对于收单支付机构adyen而言，支付渠道是antom，目标机构是支付宝，两者并不是同一个机构。为了在支付业务中覆盖这种场景，我们需要抽象出目标机构的实体概念，作为用户支付的真实交易处理机构。目标机构通常在渠道的业务机构背后，并不一定与支付机构自身有任何签约合作，因此渠道建模中会将业务机构所支持的目标机构设置于业务机构合约中，定义出每种渠道交互模式所支持的目标机构列表。目标机构和物理渠道的关系如下所示：

什么是支付方式类别

支付方式类别即支付机构所支持的支付的种类，例如钱包支付和卡支付就是不同的支付种类，目前常见的支付方式种类有余额支付、卡支付、钱包支付、信用卡支付、营销支付（红包）等类别。

支付方式介绍

当支付机构向用户提供支付服务时，用户的支付需求其实就可以总结为以下两点：

我用什么种类的支付方式进行支付？卡支付？钱包支付？
我用什么支付公司提供的支付能力进行支付？微信？招商银行？

因此，支付机构在向用户提供支付收银台的时候就需要回答以上两个问题——用户使用什么支付种类？用户使用的是什么下游的目标机构？

支付方式的建模由此诞生，支付方式面向支付收银台，用于向用户展示机构所提供的可用的支付能力。同时，支付方式由两个关键要素组成：支付方式类别、目标机构

因此可以得到支付方式的定义公式：

支付方式（PaymentMethod）= 支付方式类别（PaymentOption）+ 目标机构（TargetInst）

【咨询链路】支付通路

支付通路的建模初衷

支付方式是收银域的建模，但和渠道网络域息息相关，支付方式的构建强依赖于支付渠道的能力，用户能使用哪些支付类别、使用哪些目标机构的支付能力完全取决于渠道网络是否打通了该目标机构的对应交互模式通路。因此，渠道网络需要贴合支付方式的模型进行针对性的建模支撑——支付通路由此诞生。

支付通路定义——描述渠道网络对于目标机构的交互模式的连通性。

支付通路结构

支付方式聚焦于目标机构和支付方式类别。其本质都来源于支付渠道的建模要素：

目标机构，支付方式中的目标机构直接和物理渠道中业务机构所支持的目标结构所一一对应。
支付方式类别，支付方式类别脱胎于支付渠道中的渠道交互模式的概念，渠道交互模式即描述了不同的支付方式类别在渠道域的业务流程。

除此之外，渠道网络还需提供物理渠道的相关信息，以确定一份支持该目标机构的交互模式的渠道合约，以保证该支付方式的可用性。

由此，支付通路可由以下公式描述：

支付通路（PayChannelView）= 目标机构（TargetInst）+ 渠道交互模式（ChannelMode）+ 物理渠道（PhysicalChannel）

支付通路视图

支付通路作为渠道域描述目标机构的交互模式连通性的建模，整体上和支付方式呈现一对多的关系，每个支付方式可能有多条支付通路进行支持，需要通过渠道路由对支付方式的通路进行择优决策。具体的视图结构如下所示：

渠道资产建模视图

完整视图

通过对渠道在各个场景下的实体关系的分析，可以得到以下完整的渠道资产建模，该资产建模基本涵盖了所有渠道域的主要业务场景，并可以基于该建模衍生出各种渠道网络横向技术课题例如渠道产品化、一站式渠道接入、渠道资产数字地图等。建模的精确与完整性是发挥杠杆效应，以小见大撬动技术难点的基石。

（图中的比例关系N:M，N对应箭头起点，M对应箭头终点）

核心视图

对完整视图进行裁剪，只保留渠道网络的核心实体，更利于理解整个渠道业务，同时提高建模的稳定性，避免业务发展过程中衍生的复杂关系对渠道网络的关键实体要素造成破坏，引发模型不可控的熵增。

渠道核心视图包括五个核心实体：物理渠道、渠道合约、逻辑渠道、支付方式、支付通路，以物理渠道为中心，核心实体间的相互组合可以向上支撑覆盖不同的渠道场景：

渠道金融交换，和物理渠道与逻辑渠道相关。和外部渠道发生实质性的金融交换（信息流交互和资金流动）
渠道路由，和支付通路与物理渠道相关。渠道金融交换的前置步骤，在多个支付通路中对通路进行择优选取以发起业务交互。
渠道咨询，和支付方式、支付通路与物理渠道相关。将支付通路封装成支付方式提供给收银台，供用户对支付方式进行咨询选择。
渠道运营运维，和渠道合约、逻辑渠道和物理渠道相关。主要覆盖从渠道集成接入、渠道配置运营到渠道状态运维的一站式渠道管理。

由此可见，渠道的核心实体组合可以推导出几乎所有的渠道场景，掌握渠道核心实体是理解渠道业务的万能钥匙。

后记

渠道是支付机构的命脉所在，渠道业务风险高，业务场景纷繁复杂，渠道的建模稳定性至关重要。无论业务场景如何变化和演进，渠道资产建模永远需要维持在一个稳定的状态，从而保证支付机构的业务根基稳固。物理渠道、渠道合约、逻辑渠道等概念可能随着支付公司的不同有着细微的命名差异或者结构差异，但从建模目的来看永远是殊途同归的。领域建模的变更和演进相较于领域行为和服务都需要更加谨慎，在建模目的不清晰的情况下任何的模型变更和新增行为都是在画蛇添足。正如奥卡姆剃刀原理所描述的：如无必要，勿增实体。