编辑导语：随着互联网的不断发展，数字化进程也在不断的进步，各行业都在不停的向数字化转型，搭建互联网平台以及新的渠道；比如一些企业会向电商平台发展，在电商平台继续交易类内容；本文作者分享了关于企业数字化转型需要的支付结算产品，我们一起来看一下。

2020年的疫情，加速了很多企业的数字化转型步伐，企业基于各自战略目标纷纷投入到传统渠道升级，新零售转型，电商平台搭建，社区团购及依托于社交网络的分销体系建设中，这里需要搭建1套合适的支付结算产品来支撑企业面向交易和财务的数字化共享。

一、支付结算平台做啥，场景来说话

企业除了入驻天猫，京东等三方渠道触达用户，一般都会自己自建渠道，这条线上角色主要由大的经销商（渠道分销），小的零售店（渠道零售）和终端客户；基于各自之间的交易关系，企业往往搭建了对应的交易入口，实现商家（包括自己自营）的收款，付款和财务出入账。

我们可以从2个维度来定义这些场景，1个是交易维度， 关心的是交易双方之间怎么交易（支付结算，利益分配）；1个是资金维度，关心的是怎么收款，付款，和财务做账（需要符合各种监管）。

基于这2个核心场景，结算平台依托于外部金融资源，实现资金的监管和流通，面向交易提供支付收银（聚焦C端收款），企业支付（聚焦B端收付），清分结算（聚焦面向交易的分账）和账户服务（搭建账户体系，支持支付结算）。

特别强调：平台搭建必须和各方明确边界，不然平台搭建过程中由于强依赖于业务或者什么都做，导致中心定位模糊，能力不稳定，无法标准化，这块会在后续中心化设计中重点说明。

二、商家收付款场景

1）商家线上收款

基于交易对象不同，我们区分2C支付和2B支付，基于交易订单是否和支付订单挂钩，我们区分线上支付和线下支付（线下支付往往需要做资金和订单的匹配核销）。

线上收款2C：

商家面向C端用户做线上收款，统一由结算平台的支付收银模块提供收款服务，提供的方式主要由2种：收银台方式和聚合支付API，核心都是1次对接，获取N种线上支付方式。

特别强调1：门店零售收银，需要基于收银是否是基于订单还是直接收款来区分是线上支付还是线下支付，从收单能力上都是B2C扫码支付。

特别强调2：数字人名币已经上线，作为点对点支付渠道还需要不断优化，当前属于小白鼠试验节点，比较适合纯收款场景，还不支持基于智能合约的清分做资金分账。

这里需要结算平台统一对接外部金融资源获取支付渠道，并基于支付渠道提供支付方式，核心就是提供支付路由的能力；平台搭建初期，建议从手动路由开始做，有了多渠道，多场景和匹配策略后，逐渐迭代路由模型。

线上收款2B：

B端收款大额为主，支付机构不能做代收代付，无法像C端一样封装成快捷支付做线上收单，线上支付还是以企业网银，银企直连转账等方式实现，统一由结算平台企业支付模块提供收款服务。

特别注意1：很多企业针对传统渠道都会有自己的授信体系，政策返利体系，品牌溢价能力高的都需要先款后货，针对这些企业，搭建统一的企业钱包，通过搭建统一的信用账户，返利账户和预付款账户（预付款账户往往需要和已有ERP系统对接，或者通过银行账户体系解耦ERP）来实现支付结算。

特别注意2：很多企业和外部金融机构合作，建立了以核心企业为交易闭环的供应链金融产品，典型的有订单贷，仓单融资，应收账款融资等，都可以作为统一的支付方式融入到在线支付当中。

2）商家线下收款

线下收款2C：

前面我们把所有脱离交易订单的收款定义为线下收款，面向C端用户的线下收款形式主要由商家主动扫码和用户主动扫码2种方式，包括已经越来越少见的付现金，和看起来很时髦的数字人名币支付。

线下收款2B：

基于金融监管和企业出款财务管理需要，当前2B交易绝大部分还是以线下支付为主，但企业收款必须票款一致，所以核心是怎么让交易订单和资金一致，做到资金流，信息流一致（物流先站一边），有些企业还要考虑和合同的一致性。

特别备注1：大额转账的叫法来源于网商银行，人家网商银行把线上下单，按单生成唯一的收款账户，然后线下统一打款给这个账户的方式叫大额转账，可以很好的解决交易订单和资金的匹配，问题是每次下单都是新的账号，有点雷人。

特别备注2：很多B端交易是按周期结算，针对这类场景，可以给固定的一些交易企业建专户，专户可以基于某个具体的交易场景；比如AA采购户，CC采购户，按打款到账户后，做周期自动归集结算（财务最厌烦，不信任业务手动做订单核销）。

特别备注3：当然如果你足够强大，可以对接N多银企直联，就可以直接把业务订单推送到企业网银，支付关联。

3）企业付款场景

纯付款：

搭建支付结算平台核心是为了赋能业务系统，很多企业搭建了银企直连，没有搭建的基本也开通了企业网银；面向纯付款业务，如果没有必要，建议不走支付结算平台，资金的事要专门的资金系统负责，特别是很多资金系统还要和企业内部的费用预算体系联动。

以销定采付款场景：

很多企业做面向行业的B2B交易平台，会选择先做自营（但不是先采购后销售的重模式），会统一和上游企业签订采购合作，由企业自己面向买家做销售，信息流上基于销售单生成对应的采购单，由供应商直接发货给买家，企业收买家的钱再给供应商结算，赚中间差价。

特别备注：为了解耦业务做手工订单核销，特别是企业没有统一的订单中心时，往往会要求结算平台做供应商付款的校验，校验逻辑包括2个维度：

• 采购单是否有匹配的销售单，也就是订单是否能付钱；
• 基于原来销售单或总销售金额做可付金额的校验。

整体上建议这块可以做成独立的订单核销模块，而不是放到结算平台来做，核销完成后，再给到结算平台调用外部资源渠道做结算划分。

4）交易分账场景

不管是2B还是2C场景，在整个交易过程中，为了促成交易闭环，除了买方和卖方，多多少少都会存在其它服务方参与活动获取服务分润。

几个典型的场景：平台引入分销机制，做社会化分销，所有通过分销链接成功交易的订单都需要按一定规则按单获取分销佣金；平台提供了交易场所和服务，需要获取交易佣金；物流提供了物流服务，需要获得物流费用；支付渠道提供了支付服务，需要获得渠道额用等等。

当前不管怎么分账，资金流上都要是谁提供服务，钱先到谁（谁开发票），再按订单清分，并基于不同业务规则做结算，可以是一次性结算，也可以做多次结算。

特别备注1：在没有统一的清结算规则配置能力前，把所有的分账规则都放到具体业务系统吧，这边边界就很清晰，结算平台就是基于业务系统指令做清结算划分，生成结算单（理论上按单分账分账金额不能超过订单金额）。

 特别备注2：做好内部对账，从支付开始，到各个节点清结算，再到账户落账生成账务流水，都需要有内部对账，确保内部体系的稳定和正确。

5）财务出入账

企业交易过程中，所有涉及到收款，付款都需要在财务层面做账（一般通过ERP做财务账），而财务做账不管是记收入，还是出款，都需要有对应的发票，资金流水，业务订单，包括合同合一才能做账。这里的核心是明确2个点：

• 结算平台账户的定位，你是做面向交易的业务账（账户无科目属性，单式记账），还是财务账（有科目属性，复式记账），正常情况企业都会有自己的ERP和分录系统做财务账；
• 基于整个交易场景，明确哪些场景会涉及到真实资金的变动，有变动，就得有基于场景在分录系统做分录模板，按业务需要以固定周期或实时进行抛账。

三、企业支付结算运营场景

针对企业经营多元化，不同的业务独立发展，需要有针对不同业务的支付结算管理，运营后台孕育而生。

1）渠道管理，支付方式管理

针对支付场景，前面已经明确了2种输出的方式，收银台和聚合支付API ，这块的运营主要就是针对不同业务应用做支付渠道，支付方式或收银台的配置。

2）看板，报表，对账

运营后台除了提供支付维度的配置外，还会支持看板，实现按日，月等时间周期展示运营层面的一些统计数据，包括但不限于：支付申请的订单量，支持成功的笔数，支付成功的金额，开户数等。

报表更多是统计一些明细维度的数据，也可以按账户和清结算来做大类区分，特别要注意的是一些跨多个中心维度的数据报表，如果企业有专门的数据中心，可以由数据中心来做统一输出；对账，核心对的是和外部金融资源的对账，包括各支付渠道，账户金额，账务流水等，涉及账单的获取，轧账和对差异数据的凭证（本文就不对具体细节进行说明）。

四、支付结算的中心化设计

1）能力边界，中心建设

任何产品脱离了边界，就是无序，定位不清楚，所以在了解了企业的整体支付结算需求后，我们需要在业务层面去框定边界，以实现边界范围内服务的稳定，才能为后面的服务做沉淀和标准化的输出。

整体边界上这里按业务系统，支付，结算，账户，财务和三方外部资源来划分的，然后定义好各自的边界，核心对象，这里强调1点必须拿几个实际的交易场景，把流程跑通。

整个结算平台可以分为支付中心，结算中心和账户中心：

支付中心：基于业务订单发起收单支付，调用支付渠道，完成支付。

输入：业务订单（订单金额等信息）；输出：支付结果；核心对象：支付订单

结算中心：基于业务订单明确的分账信息，做清结算划账，并依托于银行等外部渠道实现资金的清结算。

输入：清结算指令（业务订单，分账对象和金额）；输出：清结算结果；核心对象：结算单

账户中心：业务交易过程中，以账户为载体，记录现金或现金等价物变动情况及结果（虚拟账户）

输出结果：账户余额，交易流水；核心对象：账户。

2）基础能力+标准服务接入/输出

支付结算平台作为通用服务中心，核心就是为了赋能企业的不同交易业务场景，做到服务能力的复用，外部资源的快捷对接，交易数据的完整性，是灵活多变的。

作为中心化的能力又应该是基本固定的，稳定的，不会因为几个场景的对接就做变动，所以在平台搭建的过程中需要考虑服务的分层，核心能力层沉掉支付，结算和账户的核心能力，之上基于这些核心能力，可以封装成可标准的服务来统一对接业务系统和外部金融资源。

特别备注1：建议把高复用的，边界范围内的服务作为标准服务输出，后续这些服务就是标准的接口，业务系统统一对接即可，个性化，又不在边界范围内的，尽量不接，或以独立的微服务来承接，而不是直接落到平台上；

特别备注2：理想状态，外部金融资源也应该是标准化接入，实在有特殊性的做适配层兼容。

五、总结

企业的数字化转型，也是基于企业的战略目标，把所有可管理的内容逐渐落到数字层面执行，支付结算产品的搭建也不是一撮而就，需要不断的迭代完善。

不同企业的业务场景不同，资源能力不同，不是越复杂完整的产品就适合自己，还是需要从自身的转型阶段来看，需要发展什么业务，搭建什么样的支付结算产品。

以上内容基于自身企业数字化零售转账经历，内容上主要以整体拉通为主，希望可以给广大读者待来帮助，后续会不断补充具体落地的一些内容，非常感谢。

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

题图来自Unsplash，基于 CC0 协议