电商支付系统设计（一）——可行性分析

1 背景

随着互联网的发展，主流OTA不再单纯卖自己的机票和酒店，都走向多供应商的开放平台。商旅系统在XX信用卡中心的战略指导下，也拓展了火车票、签证、保险等多项业务，旨在为XX银行持卡人的出行提供全方位产品供应。

商差旅系统早期的设计是支持多供应商和开放平台，架构上也支持插件化。但因为业务快速发展的需要，支付和订单包含了不少的业务逻辑，这些耦合的集中性，影响分布式的扩展，也带来一些业务限制和性能瓶颈。

统一支付和订单系统计划对原有公共业务进行重构，将业务差异性从支付剥离，将订单与支付解耦，构建分布、易扩展的统一支付和统一订单系统。

2 可行性分析

统一支付系统计划对商旅原有支付系统进行重构，解开支付、订单系统的耦合，便于后期业务扩展，以及新业务的快速接入。

新的支付架构，致力于涵盖未来一至三年内的系统发展，在这段期间，业务系统的普通功能增强不需要支付系统随之变更发布，并能兼容重大功能增强等业务需求。

3 方案设计

3.1 设计策略

统一支付：关注支付组合；支付订单与业务支付工单对应；与业务解耦，与订单解耦，不再维护订单任何状态。

统一订单：关注Customer-Order-Product三角关系；大表拆分；由1:1改造成1:n关系，便于新业务扩展；解决统一展示问题。

业务产品：通过产品ID与统一订单关联，将需要提供给前端渠道、个人中心集中展示的信息，同步到统一订单系统中，形成综合视图；统一订单则通过产品ID查询业务详情。通过支付工单发起支付，与统一支付系统支付单号进行对应，需自行维护支付业务项以及状态。

3.2 技术方案

技术方案的关键点在于订单系统和支付系统的解耦，订单系统与业务关系紧密，支付系统侧重交易功能。由于产品的交易多样性，系统支持现金、礼金、积分等多种交易方式，并支持各种交易的组合支付。经过对需求的分析，对解耦后的实现提出了两套可行性方案，两套方案的关键比较指标是：产品的可扩展性、对现有产品影响的高低、系统自身的复杂性等。两套方案的划分原因：组合支付的逻辑相对复杂，并且都是特定业务使用，由订单系统还是支付系统实现组合支付，直接影响到上述比较指标。

3.2.1 技术方案一

统一支付系统

l 功能说明

将业务要素从支付系统剥离，支付不再记录业务类别等信息，关注支付类型的组合。支持订单多收多退，支持新业务品种随时接入。

增加支付状态同步主动推送功能，可定时推送和手工推送，便于业务流程中断后能再续，增强系统完善性。

l 流程描述



业务与支付关联：　业务“工单流水”和“支付订单”多对一关联（如扣款、退款关联到同一个支付订单），可通过“工单流水/支付订单”查询　“支付订单”　和　“交易流水”



业务系统说明：　

1、组合支付的逻辑由支付系统实现，每发起一笔交易流水可支持多个交易类型组合同时扣款。

2、业务支付工单的流水不能重复

3、多次收款时，只需创建新的工单即可

4、多次退款时，每次新建退款工单，退与收的关联关系需要业务系统自行设计

5、预授权完成、预授权撤销时，可不新建业务支付工单

支付系统说明：

1、组合支付的逻辑由支付系统实现，需要处理部分成功的异常

2、仅在扣款时创建订单并关联扣款工单流水

3、预授权撤销、完成、退款等操作中，不用创建新的支付订单，但会创建每次的交易流水，并通过流水关联撤销、完成、退款的业务支付工单

l 规则和要素

将所有的枚举改变为INT，以适应跨语言平台扩展

4 方案分析

4.1 技术方案一

4.2 技术方案二

5 意见汇总

5.1 技术方案比较

5.2 实施方案选择建议