B2B支付建设
概述
本文中有些业务细节点会做虚化处理，有些技术组件替换成其它技术栈，但大体设计思路类似。
业务背景
概述
本文描述的整体架构主要是针对b2b平台。业务场景：供应商可在平台发布商品，分销商可购买。
b2b平台通常有不同的行业，如对于实物b2b会有消费品，电器，服饰等。旅游行业则会有酒店，线路等业务。不同的业务所需的支付也会有所不同，如对于自营的电器业务可能会用到预付款的支付模式。
支付定义
帮助业务参与方通过某种货币完成债权债务转移。
通俗点就是买家买了一个货物，要支付钱给卖家,支付钱给卖家以什么结及什么时候结给卖家就是支付要做的事。
与支付机构对比
与传统的纯支付机构相比，b2b业务平台的支付目标及架构上会有所差异。
传统支付机构目标
提供通用的支付及清结算能力给到商户或第三方平台，而支付机构需要对接清结构机构(银联或网联)。
b2b业务平台支付目标
提供上层业务 B端所需要的支付与清结算的能力，帮助业务完成交易中债权与债务的转移，并在此之上提供业务特性需要的支付能力。
b2b业务平台支付是不具备支付牌照的不能独立完成清结算。所以b2b业务平台支付主要是通过不同的支付平台来完成支付及清结算。
b2b业务平台对于支付会有单阶段或多阶段付款，如多阶段会分定金和尾款阶段。对于结算则会有实时结和周期结。同时结算计费也会有阶梯计费等复杂逻辑。
一笔支付涉及全链路流程图
图中的电商平台对应就是b2b业务平台支付所处角色。
从图中可以看出支付机构重点建设分2大块
向上提供收单产品，以及向下对接清算机构。
向上提供收单产品
主要是封装不同的支付产品能力给到客户，如微信支付有提供微信收付通能力提供完整的支付清结算产品能力。
向下对接清算机构
主要是和清算机构完成不同银行渠道的支付能力对接。
b2b平台支付建设重点
向上提供b2b交易支付清结算能力
这里涉及到提供业务具有行业特性的支付结算能力，比如多阶段支付及周期结算等能力。
向下连接不同的支付机构
B端支付特性
本文重点讲B端支付。所以会深入看B端支付特性。
B端支付特性如下
金额大：比toc的交易金额要大很多
支付多样性
支付方式多：比如微信支付，支付宝支付，预付支付以及供应链金融支付
支付形式多：如单阶段支付，多阶段支付
结算多样性
周期多性：实时结，周/月结
计费多样式：如固定费率计费，阶梯计费；通常阶梯计费用于与供应商的对赌协议完成多少交易量就按多少费率扣佣。
目标
业务目标
提供业务需要的微信支付，支付宝支付，预付款，供应链金额支付等能力。同时支撑不同的结算诉求。
技术目标
已有支付能力可快速横向复用于不同业务（通常业务接入已有支付能力全部人力少于3天）。
快速接入新支付渠道能力并且不影响其它支付能力。
快速支撑不同的结算诉求。
不出现资损。
挑战
架构如何抽象形成横向与纵向能力
只有对于支付产品及业务本身哪些是可变，哪些是不变的有深入了解，并做一定的抽象才能支撑快速复用业务及快速接入新的产品诉求。横纵能力就是为了业务快速复用目标。
横向能力是对于支付产品的能力抽象，这部分可复用于不同的业务。而不同的业务对于支付产品能力是不需要做扩展的，如支付宝扫码支付产品。纵向能力则是对于业务提供扩展。如电商电器行业在支付时可再进行库存校验或产品在架状态校验。
对于结算横向能力抽象分为平台抽佣产品以及平台抽佣&分成产品。
业务模型抽象复杂
如何应对支付多样式及结算多样性带来的复杂度。展开来说多阶段支付，周期结，合并结等如何去支撑。这背后需要抽象好业务领域模型及划分好边界。
如何防资损
B端支付金额大，一旦出现资损就会达到较高故障等级。这部分怎么从不同维度去做防控？
方案设计
竞品调研
整体步骤如下
理解所处行业竞争壁垒要素
B2B交易核心竞争的是流量，服务，产品效率，品牌，供应链金融。
流量就是商品的销售量，流量对于供应商来讲特别重要，特别是旅游货品强时效性的特点（如酒店过了时间点这个房间没售出就亏本）。流量可以从多渠道去扩展。如抖音，公众号等。
服务是商品购买售中或售后能够帮供应商或分销商解决问题的能力。
产品效率就是买卖双方在B2B平台上交易的效率。在B2B交易场景可以从业务频次及所占交易成本较大的功能去做提升。从成本角度看：发布商品对于复杂的B2B业务成本就比较大，涉及很多产品元素的组成以及后续审核流等。从业务频次来看：导购，商详，交易下单及支付结算是频次比较高的。
分析本方及竞品优劣势
基于行业竞争核心壁垒要素分析我们的优势，劣势是什么。从支付结算层面能做什么。竞品好的优势我们可以学习的咱们具体判断补齐下。我们的优势是不是可以成为壁垒，可以的话需要持续投入加强。
比如对于2b支付可以从从结算效率及供应链金融几个维度去分析。这几个维度竞品是怎么做的，当前做的程度是怎么样。结算效率这块更多是产品能力的建设。供应链金融则是有一定的门槛，能常自建或与第三方合作成本都会比较大。
业务场景梳理
这部分主要是根据具体业务输出用例,业务流程图，业务架构图。
具体业务即包含了现有业务也包含对于未来业务。
未来业务的来源一方面是所在组织的产品与业务输入。另外一方面是竞品方面的研究看有哪些方面需要补齐的。
领域模型设计
领域分析
一般用DDD领域驱动设计事件风暴分析。
图中对于具体业务进行了虚化。基本分析思路类似。
模型结果
支付
模型说明
模型设计上用支付单收敛外部一个支付业务。支付条款则对应不同的支付业务(支付正向，支付逆向，打款等)。
支付完整生命周期包含了支付收单，支付正向，支付逆向(退款)，支付打款。在国际支付场景还涉及换汇。对于上层业务来说一笔交易涉及这么多的支付业务，有了支付单聚合根可以业务支付的完整生命周期，并且能够很好的支撑多阶段付款。
比如旅游的阶段支付是分定金和尾款2阶段，这种情况一个业务支付就要包含2条支付正向阶段记录。对应模型中就是一个支付单，2条支付条款(定金和尾款)。只有当这2阶段都付成功了整体这个业务的支付才算真正结束。
由于业务上用的是三方的供应链金额产品，应收应付账单是由第三方提供接口的，这种情况可以不用建设供应链金额产品的应收应付账单。如果供应链金额产品是团队业务自研的，这个就是需要了。
支付协议代表商户入驻业务支付系统时与三方支付机构签的开通合约，记录了用户的支付账号(如支付宝，微信支付账号)是什么以及签约了哪个支付产品。支付协议签好后会生成一个支付账号。支付账号用于后续支付中查询支付账号信息用(如果是预付支付则会在预付支付账号做扣减)。
结算
模型推演
模型抽象出来后，还需要根据业务场景去做模型推演。这里涉及到具体业务所以省略掉。整体推演思路基本是按主要用例流程去看产出的领域模型是否能支撑业务场景。
架构设计
整体架构
分层架构
设计思路
分层架构遵循DDD clean分层架构。核心能力沉淀在domain。domain依赖数据持久化reposity及外部服务调用接口。Entity实体沉淀领域实体核心领域知识。
支付分层架构
整体对于具体业务做了虚化。
结算分层架构
大致结算流程：接收交易确认收货消息触发结算，结算先收单，然后计费生成清算单，最后看是否需要合并结算生成最终的结算单。结算单有周期或实时结，如果实时结则直接调用渠道进行结算打款。
流程
结算流程
资损防控
资损防控这块整体围绕事前，事中来进行设计。
事前
包含：设计方案标准，发布规范，CR规范，灰度规范。
对于结算则先进行对账（如资金清算的金额平衡），如果不平则人工介入处理后再进行结算打款。
事中
发生后要有发现机制以及融断机制。发现机制通过实时及离线核对。
事后
事后必须组织复盘看机制流程或产品技术上哪些地方可以优化改进。