B2B支付建设

概述

本文中有些业务细节点会做虚化处理，有些技术组件替换成其它技术栈，但大体设计思路类似。

业务背景

概述

本文描述的整体架构主要是针对b2b平台。业务场景：供应商可在平台发布商品，分销商可购买。

b2b平台通常有不同的行业，如对于实物b2b会有消费品，电器，服饰等。旅游行业则会有酒店，线路等业务。不同的业务所需的支付也会有所不同，如对于自营的电器业务可能会用到预付款的支付模式。

支付定义

帮助业务参与方通过某种货币完成债权债务转移。

通俗点就是买家买了一个货物，要支付钱给卖家,支付钱给卖家以什么结及什么时候结给卖家就是支付要做的事。

与支付机构对比

与传统的纯支付机构相比，b2b业务平台的支付目标及架构上会有所差异。

传统支付机构目标

提供通用的支付及清结算能力给到商户或第三方平台，而支付机构需要对接清结构机构(银联或网联)。

b2b业务平台支付目标

提供上层业务 B端所需要的支付与清结算的能力，帮助业务完成交易中债权与债务的转移，并在此之上提供业务特性需要的支付能力。

b2b业务平台支付是不具备支付牌照的不能独立完成清结算。所以b2b业务平台支付主要是通过不同的支付平台来完成支付及清结算。

b2b业务平台对于支付会有单阶段或多阶段付款，如多阶段会分定金和尾款阶段。对于结算则会有实时结和周期结。同时结算计费也会有阶梯计费等复杂逻辑。

一笔支付涉及全链路流程图

例子中：电商平台消费者A用招商银行卡支付了100元给卖家。

详细步骤

• 收单阶段

1.电商平台通过支付机构提供收单接口创建订单，消费者根据收银接口完成支付（扫码或收银支付）

2.支付机构会告诉清算机构说我要扣消费者A招商银行卡的100元，清算机构会将信息告诉发卡行招商银行

3.发卡行会记录支付信息

• 支付机构清结算阶段

1. T+1清算机构向央行清算系统发起清算：告诉央行发卡行要付多少，支付机构收多少

1. 央行将发卡机构钱划到清算机构，同时清算机构扣除手续费将剩余钱打给支付机构在央行的备付款账号

• 电商平台发起业务结算

在T+1前电商平台发起结算，此时支付机构会接收信息指令。

D+0实时结算，此时结算参与方是能实时收到钱，但这种是需要支付机构垫资。

T+1结算，则此时结算参与方只能T+1收到钱。

从图中可以看出支付机构重点建设分2大块

向上提供收单产品，以及向下对接清算机构。

• 向上提供收单产品

主要是封装不同的支付产品能力给到客户，如微信支付有提供微信收付通能力提供完整的支付清结算产品能力。

• 向下对接清算机构

主要是和清算机构完成不同银行渠道的支付能力对接。

b2b平台支付建设重点

• 向上提供b2b交易支付清结算能力

这里涉及到提供业务具有行业特性的支付结算能力，比如多阶段支付及周期结算等能力。

• 向下连接不同的支付机构

B端支付特性

本文重点讲B端支付。所以会深入看B端支付特性。

B端支付特性如下

• 金额大：比toc的交易金额要大很多

• 支付多样性

支付方式多：比如微信支付，支付宝支付，预付支付以及供应链金融支付

支付形式多：如单阶段支付，多阶段支付

• 结算多样性

• 周期多性：实时结，周/月结

• 计费多样式：如固定费率计费，阶梯计费；通常阶梯计费用于与供应商的对赌协议完成多少交易量就按多少费率扣佣。

B端支付限制与痛点

限制

2b支付央行规定

1、禁止查询企业余额

2、禁止第三方支付公司开展大额对公账户代收代付业务

税务机关对第三方支付公司出具的付款凭证不予认可，不予开具增值税发票，企业无发票则无法正常入账

3、禁止企业间大额支付交易不经过央行清结算系统

痛点

开票问题

通常由于资金流与实际交易合同信息流不一致导致开票困难；

在与第三方支付公司合作时需要明确：1）交易双方在支付公司都需要开通虚拟支付账号以便于后续开票需要的资金流水证明开据；2）支付公司能够开据在线资金流水；

基于支付公司买卖双方虚拟户解决开票问题的资金流

目标

业务目标

提供业务需要的微信支付，支付宝支付，预付款，供应链金额支付等能力。同时支撑不同的结算诉求。

技术目标

已有支付能力可快速横向复用于不同业务（通常业务接入已有支付能力全部人力少于3天）。

快速接入新支付渠道能力并且不影响其它支付能力。

快速支撑不同的结算诉求。

不出现资损。

挑战

• 架构如何抽象形成横向与纵向能力

只有对于支付产品及业务本身哪些是可变，哪些是不变的有深入了解，并做一定的抽象才能支撑快速复用业务及快速接入新的产品诉求。横纵能力就是为了业务快速复用目标。

横向能力是对于支付产品的能力抽象，这部分可复用于不同的业务。而不同的业务对于支付产品能力是不需要做扩展的，如支付宝扫码支付产品。纵向能力则是对于业务提供扩展。如电商电器行业在支付时可再进行库存校验或产品在架状态校验。

对于结算横向能力抽象分为平台抽佣产品以及平台抽佣&分成产品。

• 业务模型抽象复杂

如何应对支付多样式及结算多样性带来的复杂度。展开来说多阶段支付，周期结，合并结等如何去支撑。这背后需要抽象好业务领域模型及划分好边界。

• 如何防资损

B端支付金额大，一旦出现资损就会达到较高故障等级。这部分怎么从不同维度去做防控？

• 如何做到高可用？多支付渠道路由&预案

方案设计

竞品调研

整体步骤如下

• 理解所处行业竞争壁垒要素

B2B交易核心竞争的是流量，服务，产品效率，品牌，供应链金融。

流量就是商品的销售量，流量对于供应商来讲特别重要，特别是旅游货品强时效性的特点（如酒店过了时间点这个房间没售出就亏本）。流量可以从多渠道去扩展。如抖音，公众号等。

服务是商品购买售中或售后能够帮供应商或分销商解决问题的能力。

产品效率就是买卖双方在B2B平台上交易的效率。在B2B交易场景可以从业务频次及所占交易成本较大的功能去做提升。从成本角度看：发布商品对于复杂的B2B业务成本就比较大，涉及很多产品元素的组成以及后续审核流等。从业务频次来看：导购，商详，交易下单及支付结算是频次比较高的。

• 分析本方及竞品优劣势

基于行业竞争核心壁垒要素分析我们的优势，劣势是什么。从支付结算层面能做什么。竞品好的优势我们可以学习的咱们具体判断补齐下。我们的优势是不是可以成为壁垒，可以的话需要持续投入加强。

比如对于2b支付可以从从结算效率及供应链金融几个维度去分析。这几个维度竞品是怎么做的，当前做的程度是怎么样。结算效率这块更多是产品能力的建设。供应链金融则是有一定的门槛，能常自建或与第三方合作成本都会比较大。

业务场景梳理

这部分主要是根据具体业务输出用例,业务流程图，业务架构图。

具体业务即包含了现有业务也包含对于未来业务。

未来业务的来源一方面是所在组织的产品与业务输入。另外一方面是竞品方面的研究看有哪些方面需要补齐的。

领域模型设计

领域分析

一般用DDD领域驱动设计事件风暴分析。

图中对于具体业务进行了虚化。基本分析思路类似。

模型结果

支付

模型说明

• 模型设计上用支付单收敛外部一个支付业务。支付条款则对应不同的支付业务(支付正向，支付逆向，打款等)。

支付完整生命周期包含了支付收单，支付正向，支付逆向(退款)，支付打款。在国际支付场景还涉及换汇。对于上层业务来说一笔交易涉及这么多的支付业务，有了支付单聚合根可以业务支付的完整生命周期，并且能够很好的支撑多阶段付款。

比如旅游的阶段支付是分定金和尾款2阶段，这种情况一个业务支付就要包含2条支付正向阶段记录。对应模型中就是一个支付单，2条支付条款(定金和尾款)。只有当这2阶段都付成功了整体这个业务的支付才算真正结束。

• 由于业务上用的是三方的供应链金额产品，应收应付账单是由第三方提供接口的，这种情况可以不用建设供应链金额产品的应收应付账单。如果供应链金额产品是团队业务自研的，这个就是需要了。

• 支付协议代表商户入驻业务支付系统时与三方支付机构签的开通合约，记录了用户的支付账号(如支付宝，微信支付账号)是什么以及签约了哪个支付产品。支付协议签好后会生成一个支付账号。支付账号用于后续支付中查询支付账号信息用(如果是预付支付则会在预付支付账号做扣减)。

架构设计

设计思路

系统是随业务发展演进的。业务初期要保证业务能先跑起来，基本能力具备。业务中后期则要贴合业务去建壁垒，以及做降本提效的事情。

初期伴随业务策略某一块业务发展了扫码，预付款等支付方式。能力上有了多阶段支付，不同支付阶段混合支付。

技术策略上初期设计上考虑了支付终局架构，在落地时落地了支付与结算2大域。但在具体子域落地时会轻量去根据当前业务实际情况做落地，后续保留高效扩展能力即可。

初期支付域落地了支付核心&支付用户&支付收银域。结算初期清算结算2大域有划分，落地了清算及结算核心2大能力。

在业务发展中后期随着支付降本&高可用的目的需要支持同一种支付方式多支付渠道。因此在这个阶段落地了支付决策域，根据运营设置的低费率做渠道路由。业务发展需要营销补贴，因此支付域也建设了营销补差的能力。

整体架构

支付域

内部按领域划分：支付核心，支付用户域，收银域与支付决策域（支付路由）。在实际落地过程中支付核心与支付用户域及收银域是在业务初期就实际并落地。收银域前期在包模块上是独立的，能力上相对比较简单适用于业务实际场景：根据不同业务不同端不同供应，分销商展示相应的支付能力。如有些商户是有开通供应链金融支付方式（如赊呗），有些分销商则开通了支付代扣能力则在端收银台上会根据这些因素展示出相应支付方式。

分层架构

设计思路

分层架构遵循DDD clean分层架构。核心能力沉淀在domain。domain依赖数据持久化reposity及外部服务调用接口。Entity实体沉淀领域实体核心领域知识。

支付分层架构

整体对于具体业务做了虚化。

资损防控

资损防控这块整体围绕事前，事中来进行设计。

事前

包含：设计方案标准，发布规范，CR规范，灰度规范，自动化用例。

对于结算则先进行对账（如资金清算的金额平衡），如果不平则人工介入处理后再进行结算打款。

事中

发生后要有发现机制以及融断机制。发现机制通过实时及离线核对。

事后

事后必须组织复盘看机制流程或产品技术上哪些地方可以优化改进。