我之前写过的企业数字化转型需要打造的支付结算产品，总体来说讲的比较详细，2021年参与过几个企业数字化转型项目，并且专注于支付结算领域，参与过售前、业务方案、产品设计开发，从完整的产品周期到交付运营，这里就简单分享一下支付结算产品（方案）设计方法（很多东西只是简单提了一下）。

从产品角度来说，支付结算产品的核心是解决用户（企业/个人，本文除特别说明外，默认用户为企业客户）在交易过程中的收付款问题，因此需要了解业务场景（企业的业务模式：有哪些参与者、如何交易、如何盈利以及如何做账），提供合适的支付结算业务解决方案（针对企业的业务策略，进入哪些交易场景，需要哪些业务模块，设计匹配的业务架构），支付结算需要哪些资源？（中心化的处理方式决定了支付结算必须依赖绝对的资源（如境内的资金清结算规则），了解这些资源的运行规则，如何对接和运营它们。）

从企业数字化角度看，支付结算贯穿交易和财务管理，是企业交易在线、资源在线、财务在线、资金管理在线的路由器。

1.支付结算概念

术语有专业性，了解专业术语是提供专业解决方案/产品的基础。

1.1 术语

支付：字面意思就是支付，基于交易至少需要买方和卖方两个对象，买方以自己的资产、股权或者债务（理论上只要卖方同意，一切皆可支付，本质我理解为信用凭证）作为支付凭证，实现交易支付；

清算：一笔交易可能涉及多方，记录各方基于这笔交易的应收应付（例如国内金融体系有独立的支付结算，需要先清算核算，然后才能进行实际的资金结算）；

结算：了解交易维度的实际资金结算以及金融中债权的转移情况；

对账：账务确认金额的对账，本质上是为了确保同一笔交易的数据描述在不同业务或系统中记录一致（比较的对象可以是单据或账目，比较维度可以是明细、总计或计算统计量）；

往来账户：往来维度（单式核算）中产生的每一个往来账户，都以该往来账户为依据生成一个账簿；

财务账簿：财务维度产生的每一笔会计交易（模型核算时要明确借贷关系），根据会计交易生成账簿；

渠道与路由：支付结算需要有处理源，谁提供处理，谁就是渠道，路由是根据规则（静态或动态规则）来明确指定使用哪个渠道实现支付结算。

1.2 产品战略与策略

不要用勤奋的产品策略（埋头于流程和功能）来掩盖战略上的懒惰。

企业只有通过交易才能获得利润，实现可持续发展，支付结算产品也需要战略规划和战术实施，才能不断创造客户价值，实现永续经营。

企业战略：了解企业战略（企业数字化转型已经成为很多企业的基本战略，以更好地支撑业务战略），包括商业模式的演进。核心是规划支付结算产品，以可持续匹配企业战略。

企业策略：了解目前的交易模式、核心业务、核心客户、阶段性业务目标、未来业务规划及核心服务对象。核心是促成切入具体交易场景，提供支付结算产品，支撑现有交易线上化，打造通用支付结算服务，完成支付结算产品的服务运作。

理解了企业战略战术之后，支付结算产品的规划一般包含：从产品定位来看，是支撑企业完成交易收付闭环（业务交易闭环、财务管理闭环，这个是支撑业务闭环）；后者是有效灵活地支撑线上交易（满足企业服务需求，灵活触达B端、C端用户，这是产品赋能业务）；最后是数据赋能，交易持续产生有效数据赋能业务（无论是交易、财务维度的客户画像，还是业财融合、自动化）。重点：规划是规划，但实际设计要根据企业的数字化程度和转型重点来定。

2. 业务场景

不同行业有不同的商业模式，但抽象来说，无非就是交易对象（服务提供方提供服务，消费者获得服务）、产品交易（交易后履约，实体产品有物流，虚拟产品一般都是简单服务），从交易结算中赚取利润，做业务核算。

有了业务抽象的能力，就可以站在用户的角度去分析业务，输出产品解决方案。

1.1 业务场景分析

从商业模式的角度看，其实就是商业参与方的利益分配。我习惯从交易对象的角度来锁定商业，分为二方交易和多方交易（二方交易的多种组合）。二方交易很容易理解：就是交易。在交易的生命周期中，只有买家和卖家参与并完成（比如街边卖菜的大妈和我付现金买菜）。

多方交易理解为：多方参与到一笔交易的生命周期中，形成多个“二方交易”（比如我在饿了么选择盒马生鲜，用支付宝下单买菜，蜂鸟配送一个场景，就会产生：我和盒马，盒马与饿了么（假设蜂鸟属于饿了么，交易佣金与配送费），我与饿了么，盒马与支付宝渠道费（假设支付宝根据订单直接扣除商家支付费）至少一笔二方交易。

通过明确交易对象，我们可以更好地理解一个交易场景是如何完成的，涉及多少笔交易业务，以及如何根据交易进行支付、清结算，如何处理发票和税务。下图是一个典型的BBC平台交易。

1.2 交易模型

任何交易都有三种交易类型：先付款后发货；先付款后发货；先发货后付款。这些本质上都是不同的信用处理方式。在一个商业场景中，多种交易模式并存（例如，在很多供应链中，采购由销售决定，企业和供应商约定采购协议，企业销售给客户，但货物由采购方直接发货，客户发给企业付款，同时触发企业向供应商付款。上述三种付款方式都可能存在）。

交钱交货：可以说是实体纸币时代的主流交易支付方式，适合信用体系下的交易，无论是现金还是后来发展起来的银企直连或者企业网银支付，效率都有限。

先货后款：适用于信用体系完善的市场交易。对公授信典型有企业内部赊销，私募授信典型有个人银行信用卡、支付宝花呗、京东白条等。授信额度是需要偿还的债务。

先款后发货：对于公端，适用于有品牌议价能力的企业，下游分销渠道需先进行预付款，再用预付款进行采购；对于私端，适用于会员充值、充值卡等业务。

从商业模式来看，显然先款后发货是最好的做法，但这涉及到预付费资金监管的问题，特别是为C端会员提供预付费充值服务的问题。

1.3 交易凭证

基于交易对象、交易模式，只有在交易过程中生成不同维度的交易凭证来记录它们，才能支撑交易的合规性、有效性和可追溯性，一般包括：经营交易凭证（锁定交易对象及责任，形成订单或合同明细）；物流凭证（实物交易履行凭证）；发票流转：买家收到发票，卖家开具发票；税务流转：交易中产生的各类税务凭证。

正常有效的交易，一般都有一致的信息流、物流、资金流、发票流和税流（既有1：1的关系，也有N：N的关系）。

3. 领域设计

业务需要边界，产品、开发设计都需要边界，这是我对领域概念的理解，作为支付结算产品，就应该做好支付结算领域，什么都做就等于什么都不做，好的领域设计要保证独立性和可扩展性。

我把领域设计分为两个维度：横向的业务领域，通过定义不同的业务对象来区分；纵向的架构领域，通过分层来解耦业务对象处理问题的复杂性（业务驱动领域设计，所以不是业务驱动，设计得越分层越好。比如你只是通过微信小程序试点自营商城业务，为了快速验证业务，能做微信小程序支付就够了）。

1.1 领域业务边界

经历过几个大型项目的业务中台、数据中台的设计，理论上一个业务对象的业务闭环的边界可以设计成独立的域（业界更喜欢叫中心，然后多个中心组成一个大区域：比如交易域下一般会有一个订单中心（核心业务对象是业务订单）、一个支付中心（核心业务对象是支付订单）等等）。

在了解了企业客户整体业务和未来战略规划之后，我们可以规划需要设计哪些业务领域来支撑现在的业务，并满足未来的扩展性（需要平衡效率和成本，分工越细，技术越复杂，分布式事物的一致性设计就越关键，从产品角度验证和打磨新业务就显得越关键）。

在支付结算领域，通常分为支付、清结算、对账、交易/财务核算、商户几个常见的中心，围绕企业一笔交易的整体流程，形成完整的上下游业务闭环。

支付的核心是支付指令，主要明确支付来源、收付款人、财务、支付方式以及最终执行支付的处理来源（支付渠道）。

清算结算的核心是结算单据，主要明确交易基础上的应收应付以及资金结算的结算渠道；

会计的核心是账户（一般涉及财务端的银行结算账户、支付机构的支付账户、交易端的账簿）；

对账的核心是报表，涉及对账数据的接入、清理、对账处理、差异处理、报表输出等；

商户是参与交易的交易方，基本分为个人、企业、个体户，所有账户都需要关联对应的商户（商户识别根据账户权限进行，例如专门收单支付的商户需要进行实体识别）。

1.2 领域架构设计

我对业务架构的理解就是通过层来定义同一个业务的输入输出边界，通过模块来定义同一层的不同能力或者服务。比如很多架构有应用层，有逻辑层，有物理层。

在支付结算领域，我习惯于应用层、逻辑层、核心层的3层或者2层设计，应用层负责服务输出，逻辑层负责领域内的业务分析和逻辑处理，核心层定义业务对象的核心能力和属性。

以聚合支付服务为例，应用层是标准的聚合支付服务接口输出，外部应用通过调用接口获取聚合支付服务，获取支付业务订单数据后进行业务分析，明确收款人、收款人、支付方式等信息，通过支付路由规则明确支付方式对应的渠道。

有些场景（比如组合支付）还涉及到逻辑处理（组合支付需要根据主支付订单，拆分成多个支付通道流，需要所有支付通道流都成功，组合支付才算成功），核心层就是使用明确的支付方式、支付通道、收款人及收款人、金额等信息来调用支付通道进行最终的支付处理。

业务驱动的支付产品设计。

几种支付产品的典型设计分割。

四、资源

前面提到，支付方式本质上是信用处理的不同方式。资源代表着处理的权利，比如一个国家发行法定货币，背后有这个国家的信用支撑，所以法定货币资金的结算都是由央行统一处理的（处理的结果是相对的）。信任是层层递进的，比如电商支付收款的资金流向：央行清算-商业银行清算结算-支付机构清算结算-交易系统清算结算。体系层级都是中心化的设计。

1.1 财政资源

支付结算一旦涉及到实际资金，就需要对接金融资源。首先要了解金融资源的规则，我个人的理解是集中管理+专业化（不同专业需要不同的金融牌照），金字塔顶端是央行、银监会（保监会合并）和证监会，一个网络支付的资金流向。下面我以使用支付宝（花呗）在天猫支付为例，做一个简单的说明。

交易场景（天猫交易订单）-业务层（生成支付订单、支付方式花呗、支付渠道支付宝）-支付宝支付处理（1、通知蚂蚁微贷扣减我的花呗信用额度，蚂蚁微贷会对我花呗的信用额度进行查询并扣减，然后反馈给支付宝，支付宝反馈支付处理结果，这个过程现在需要经过银联）-银联走小额支付系统/超级网银-央行做资金清算（蚂蚁微贷花呗专户清算到支付宝备付金账户，按日处理差额）-支付宝生成账单（通过银联获取账单后进行对账，支付订单完成资金清算）-业务层获取支付宝账单并做对账核销，等待天猫业务订单闭环触发支付订单资金结算给商户（一般当我支付成功的时候，商户可以看到余额收益资金（冻结资金，但根据天猫支付结算规则，需在业务订单关闭后方可提现）。

1.2 企业资源

除了对接金融资源，还涉及到对接一些企业内部资源，包括但不限于内部信贷（赊销）、返利（成本折算）、营销补贴（成本折算）、价格补贴（成本折算）、预付款（预付款）等。客户获得这些企业内部资源后，就可以在企业业务闭环内正常进行交易、付款。

正常情况下很多企业都会用ERP来管理这些内部资源，这就涉及到业务解耦了，核心就是把资源的业务逻辑解耦成独立的领域模块，让ERP只做核心的记录核算（解耦后的整体解决方案、数据迁移等这里就不详细讨论了）。

1.3 运营资源

交易驱动型的产品往往是更多的运营驱动型的产品。因此，在设计产品的时候，需要考虑公司的运营能力，是否有足够的资源支撑产品的运营管理。很多时候，这正是决定产品的客户价值所在（千万不要最后产品上线了，却发现用处不大，这也是很多项目没有后续的主要原因）。

5. 数字支付与结算案例研究

哈电集团是中国最大的家电企业之一，战略上开始从传统分销向赋能经销商、直达终端客户提供零售服务转型，通过企业数字化，实现库存在线、交易在线、资源在线、营销在线、组织在线，以更好地支撑多样化的交易场景，尝试新的服务业务，通过标准化业务获取完整有效的数据，驱动数据化业务。

支付结算以平台化开发的产品形式，统一财务和企业内部资源，输出标准化的支付结算和账户服务，满足2B、2C不同的交易场景（对很多细节感兴趣的可以看一篇去年同期发表的文章，讲企业数字化转型需要打造的支付结算产品）。

具体的产品形态可根据企业客户实际业务及项目范围进行设计，单一业务场景无需支付结算开发平台，也无需详细字段，可快速满足业务场景，实现交易支付结算闭环。

6. 继续前进

未来当支付结算领域基本建立起来之后，我会更加注重产融结合，推行产业金融产品。

以上内容是我自己在企业数字化项目支付结算产品从售前到交付过程中的一些经验总结，内容主要侧重方法论，希望对读者有所帮助，后续会继续补充一些具体的实施内容，谢谢大家。