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