电商支付系统设计(一)——可行性分析

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 实施方案选择建议

展开阅读全文

没有更多推荐了,返回首页