再聊企业数字化建设的支付结算产品设计(3)

作者:网站采编
关键词:
摘要：1.2领域架构设计 我理解的业务架构，通过层级来定义同1个业务的输入和输出边界，通过模块来定义同一层的不同能力或者服务，比如很多架构都会有应用

1.2领域架构设计

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

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

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

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

业务驱动支付产品设计。

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

四、资源

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

1.1 金融资源

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

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

1.2企业资源

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

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

1.3 运营资源

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

五、支付结算数字化案例

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

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

文章来源：《数字化用户》 网址: http://www.szhyhbjb.cn/zonghexinwen/2022/0214/2629.html

上一篇：快消数字化划重点：用户价值、数据在线、数据
下一篇：金融机构数字化转型是必答题