支付结算创新「数字化产品开发与制造」

今天给大家普及一下支付结算创新「数字化产品开发与制造」相关知识，最近很多在问支付结算创新「数字化产品开发与制造」，希望能帮助到您。

编辑导语：在数字化时代，企业是如何进行支付交易？这篇文章从四个方面，详细阐述了企业数字化建设的支付结算产品设计，推荐想要了解数字化支付结算产品的童鞋阅读。

之前写的聊聊企业数字化转型需要建的支付结算产品整体上比较细节琐碎，2021年又参与了几个企业数字化转型项目，并专注于支付结算领域参与了从售前，业务方案，产品设计开发到交付运营落地的完整产品周期，在此做个支付结算产品（方案）设计方法的简单分享（很多东西点到为止哦）。

从产品角度讲，支付结算产品核心是解决用户（企业/个人，本篇用户非特别说明，默认为企业客户）交易环节收付钱的问题，所以你需要了解业务场景（企业的业务模式：有哪些参与方，怎么交易，怎么赚取利润到怎么做账），并提供合适的支付结算业务方案（针对企业的业务战略，切入哪些交易场景，需要哪些业务模块，设计匹配的业务架构），支付结算的资源有哪些（中心化的处理思路，决定了支付结算必须依赖于绝对的资源（比如国内资金的清结算规则），了解这些资源的运行规则，怎么对接和运营）。

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

一、支付结算概念

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

1.1术语说明

支付：字面意思就是付钱，基于交易，至少需要买方和卖方2个对象，买方消耗自己拥有的资产，权益或债务（理论上只要卖方认可，一切皆可支付，本质上我理解为是信用凭证），实现交易支付；

清分：一笔交易，可能有多方参与，记录各方基于这笔交易的应收应付（比如：国内金融体系支付结算独立，需要先清分记账，再做实际的资金结算）；

结算：交易维度做实际资金结算理解，财务上做债权关系转移理解；

对账：账证实的额对，本质上说是为了确保同一个事务的数据描述在不同业务或系统下记录一致而进行的相互之间的一致性比对（对比的对象可以是单据或账户，对比的维度可以是明细，总数或计算后的统计数据）；

交易账：交易维度生成的每一条交易账务（单式记账），基于交易账务生成账簿；

财务账：财务维度生成的每一条会计账务（明确借贷关系做模式记账），基于会计账务生成账簿；

渠道和路由：支付结算需要有处理来源，谁提供处理谁就是渠道，路由基于规则（静态或动态规则）明确走哪条渠道实现支付结算。

1.2 产品战略和战术

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

企业只有通过交易才能赚取利润，做可持续的发展，支付结算产品也需要有战略规划和战术落地，才能不断产生客户价值，做可持续运营。

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

企业战术：了解当前交易模式，核心业务，核心客户，阶段业务目标，后面的业务规划和核心服务对象，核心是便于切入具体的交易场景，提供支付结算产品支持现有交易的在线化，来打造通用的支付结算服务，完成支付结算产品的服务运营。

了解完企业战略和战术后，支付结算产品的规划一般由：从产品定位上就是支撑企业完成交易收钱和付钱的闭环（业务交易闭环，财务管理闭环，此为支撑业务闭环）；再往后看就是有效并灵活的支撑交易在线（满足企业服务可以灵活的触达B端和C端用户，此为产品赋能业务）；最后就是数据赋能，交易通过标准的支付结算不断产生有效的数据赋能业务（不管是交易，金融维度的客户画像；还是业财一体化，自动化）。重点：规划归规划，实际要以企业数字化程度和转型的重点来设计。

二、业务场景

行业不同，企业的业务模式不同，但抽象的看，无非交易对象（服务方提供服务，消费方获取服务），产品交易（交易后履约，实体产品有物流，虚拟产品一般为单纯的服务），交易结算赚取利润，做企业账。

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

1.1业务场景分析

从业务模式的角度看，其实就是业务参与方的利益分配，我习惯用交易对象的角度来锁定业务，分为双方交易和多方交易（双方交易的多个组合），双方交易好理解：就是交易的生命周期中只有买方和卖方2方参与并完成（比如街道上摆菜摊的大妈，我付现金买菜）。

多方交易理解为：交易的生命周期中有多方参与，形成了多个“双方交易”（比如我在饿了吗选择盒马生鲜使用支付宝下单买菜，蜂鸟配送一个场景，会产生：我和盒马，盒马和饿了吗（假设蜂鸟属于饿了吗，交易抽佣和配送费），我和饿了吗，盒马和支付宝渠道手续费（假设支付宝按单直接扣商家收单手续费）至少个双方交易。

明确交易对象，可以更好的理解涉完成一个交易场景，涉及多少交易业务，理解基于交易怎么做支付，清结算，发票和税要怎么走。下图是典型的BBC平台交易。

1.2 交易模式

任何交易，万变不离其中就是3种交易模式：一手交钱一手交货；先款后货；先货后款，本质就是信用的不同处理方式。而实际的交易中，可能因为多方交易，在一个业务场景中，出现多个交易模式并存的情况（比如供应链中很多都是以销定采，企业和供应商定采购协议，由企业面向客户销售，但商品由采购商直接发货，客户向企业支付并同时触发企业向供应商支付，支付方式以上3种都可能存在）。

一手交钱一手交货：可以说是实物纸币时代下来的主流交易支付方式，适合在信用体系下交易，不管是现金还是后面发展的银企直联或企业网银支付，都效率有限。

先货后款：适合在信用体系健全的市场交易，对公端典型的有企业内部的赊销授信，对私端典型的有个人银行信用卡，支付宝花呗，京东白条等，交易闭环后需要使用的信用额度作为债务需要做还款。

先款后货：对公端适用于有品牌议价权的企业，下游分销渠道需要先打款预付，再使用预付款采购，对私端适用于会员充值，预付卡等业务。

从商业模式上看，很明显先款后货最优，但涉及到先款资金监管的问题，特别是提供面向C端会员的预付充值。

1.3 交易凭证

基于交易对象，交易模式，只有产生交易过程中不同维度的交易凭证做记录，才可支撑交易的合规，有效和可追溯，一般包括：业务交易凭证（锁定交易对象和职责，形成订单或合同明细）；物流凭证（实物交易履约凭证）；发票流：买方收票，卖方开票；税务流：交易中产生的各种税务凭证。

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

三、领域设计

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

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

1.1领域业务边界

经历过几个大型项目业务中台和数据中台设计，理论上以1个业务对象完成自身业务闭环的边界都可以设计成独立的领域（行业内更喜欢叫中心，然后多个中心形成1个大的领域：比如交易领域下面一般会有订单中心（核心业务对象为业务订单），支付中心（核心业务对象为支付订单）等）。

当了解了企业客户的整体业务和后面的战略规划后，就可以规划需要做哪些业务领域的设计来支撑当前业务，又满足后面的可扩展（需要平衡效率和成本，分的越细，技术上分布式事物的一致性设计越复杂，产品上看新业务的验证和打磨更关键）。

支付结算领域，正常都会分为支付，清结算，对账，交易/财务账务，商户这几个常见的中心，基于企业一笔交易的整体流程形成完整的业务上下游闭环。

其中支付核心是支付订单，主要是明确交易的支付来源，收付款方，金融，支付方式和最终执行支付的处理源（支付渠道）；

清结算核心是结算单，主要是明确基于交易的应收应付，结算的渠道做资金结算；

账务核心是账户（一般涉及到金融端的银行结算户，支付机构的支付账户，交易端的账簿）；

对账核心是对账单，涉及对账数据的接入，清洗，对账处理，差异处理，账单输出；

商户就是参与到交易的交易对象，基本分为个人，企业和个体户，账户都需要关联到对应的商户下面（按账户权限做商户认知，比如收单特殊商户需要做实体认知）。

1.2领域架构设计

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

对于支付结算领域来说，个人习惯应用层，逻辑层到核心层的3层或2层设计，应用层做服务的输出，逻辑层做业务解析和领域内的逻辑处理，核心层定义业务对象的核心能力和属性。

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

有些场景（比如组合支付）还涉及逻辑的处理（组合支付需要基于主支付订单，拆分多条支付渠道流水，并要求所有的支付渠道流水成功才算组合支付成功），核心层就是拿着明确的支付方式，支付渠道，收付款方和金额等信息调用支付渠道做最终的支付处理。

业务驱动支付产品设计。

典型的几个支付产品设计拆分。

四、资源

前面讲了，支付方式本质上其实是信用的不同处理方式，资源代表了处理的权利，比如国家发行法币，背后就是国家的信用，所以法币的资金结算由央行统一处理（处理的结果是相对的信任是逐层的，比如电商收单支付资金的流转：央行清算-商业银行清结算-支付机构清结算-交易系统清结算，系统层面就是中心化设计。

1.1 金融资源

支付结算一旦涉及到实际资金，就需要对接金融资源，首选需要了解金融资源玩的规则，个人理解就是中心化管理&专业化各司其职（不同专业要有不同的金融牌照），金字塔顶端就是央行，银监会（保监会合并）和证监会，一笔线上支付的资金整体流程，下面我以在天猫使用支付宝（花呗）支付为例做个简单说明。

交易场景（天猫交易订单）—业务层（生成支付订单，支付方式花呗，支付渠道支付宝）—支付宝支付处理（1.通知蚂蚁小贷要扣我的花呗额度，蚂蚁小贷做我的花呗额度查询并扣减记账，反馈给支付宝，支付宝反馈支付处理结果，此过程现需要走网联）—由网联走小额支付系统/超级网银—央行做资金清算（蚂蚁小贷花呗专户清算给支付宝备付金账户，按日軋差一笔处理）——支付宝生成账单（通过网联获取账单后做对账核销，支付订单完成资金结算）——业务层获取支付宝账单并做对账核销，并等待天猫业务订单闭环触发支付订单资金结算给商户（一般是我支付成功，商户就能看到余额的收益资金（冻结资金），但基于天猫货款结算规则，需要业务订单闭环后才能提现）。

1.2企业资源

除了对接金融资源外，也涉及到一些企业内部资源的对接，包括但不限于内部授信（赊销），返利（费用转化），营销补贴（费用转化），价格补贴（费用转化），预收款（先款后货）等等。客户获取到这些企业内部资源，正常都可以在企业业务闭环内做交易支付。

正常情况，很多企业都使用ERP做这些内部资源的管理，中间涉及到业务的解耦，核心是解耦资源的业务逻辑到独立的领域模块中，让ERP只做核心的记录核算（解耦的整体方案，数据迁移等都不在这细讲）。

1.3 运营资源

交易驱动的产品更偏向于是运营驱动的产品，因此产品设计的时候需要考虑企业的运营能力，有没有足够的资源支持产品的运营管理，很多时候真是这块决定了时间产品的客户价值（不要到最后产品上线，发现一直没什么用，很多项目没有下文的主要原因）。

五、支付结算数字化案例

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

支付结算以开发平台的产品形态，统一对接金融和企业内部资源，输出标准的支付结算和账户服务来满足2B,2C的不同交易场景（很多细节有兴趣的可以看看差不多去年同一时间的文章聊聊企业数字化转型需要建的支付结算产品）。

具体的产品形态，可以基于企业客户的实际业务和项目范围来设计，单一的业务场景不需要做支付结算开发平台，不需要细化领域，能够快速满足业务场景，实现交易的支付结算闭环即可。

六、继续前行

后续在支付结算领域基本定型的情况下，我会更多往业财一体，产业金融产品的落地靠。

以上内容基于自身企业数字化项目支付结算产品从售前到交付的经历，内容上主要以方法论拉通为主，希望可以给广大读者待来帮助，后续会不断补充具体落地的一些内容，非常感谢。

本文由 @哈哈的鲸鱼 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于 CC0 协议