电商支付系统设计（一）——可行性分析
1 背景
随着互联网的发展，主流OTA不再单纯卖自己的机票和酒店，都走向多供应商的开放平台。商旅系统在XX信用卡中心的战略指导下，也拓展了火车票、签证、保险等多项业务，旨在为XX银行持卡人的出行提供全方位产品供应。
商差旅系统早期的设计是支持多供应商和开放平台，架构上也支持插件化。但因为业务快速发展的需要，支付和订单包含了不少的业务逻辑，这些耦合的集中性，影响分布式的扩展，也带来一些业务限制和性能瓶颈。
统一支付和订单系统计划对原有公共业务进行重构，将业务差异性从支付剥离，将订单与支付解耦，构建分布、易扩展的统一支付和统一订单系统。
2 可行性分析
统一支付系统计划对商旅原有支付系统进行重构，解开支付、订单系统的耦合，便于后期业务扩展，以及新业务的快速接入。
新的支付架构，致力于涵盖未来一至三年内的系统发展，在这段期间，业务系统的普通功能增强不需要支付系统随之变更发布，并能兼容重大功能增强等业务需求。
3 方案设计
3.1 设计策略
业务产品：通过产品ID与统一订单关联，将需要提供给前端渠道、个人中心集中展示的信息，同步到统一订单系统中，形成综合视图；统一订单则通过产品ID查询业务详情。通过支付工单发起支付，与统一支付系统支付单号进行对应，需自行维护支付业务项以及状态。
3.2 技术方案
技术方案的关键点在于订单系统和支付系统的解耦，订单系统与业务关系紧密，支付系统侧重交易功能。由于产品的交易多样性，系统支持现金、礼金、积分等多种交易方式，并支持各种交易的组合支付。经过对需求的分析，对解耦后的实现提出了两套可行性方案，两套方案的关键比较指标是：产品的可扩展性、对现有产品影响的高低、系统自身的复杂性等。两套方案的划分原因：组合支付的逻辑相对复杂，并且都是特定业务使用，由订单系统还是支付系统实现组合支付，直接影响到上述比较指标。
3.2.1 技术方案一
统一支付系统
l 功能说明
增加支付状态同步主动推送功能，可定时推送和手工推送，便于业务流程中断后能再续，增强系统完善性。
l 流程描述
业务与支付关联： 业务“工单流水”和“支付订单”多对一关联（如扣款、退款关联到同一个支付订单），可通过“工单流水/支付订单”查询 “支付订单” 和 “交易流水”
业务系统说明：
1、组合支付的逻辑由支付系统实现，每发起一笔交易流水可支持多个交易类型组合同时扣款。
2、业务支付工单的流水不能重复
3、多次收款时，只需创建新的工单即可
4、多次退款时，每次新建退款工单，退与收的关联关系需要业务系统自行设计
5、预授权完成、预授权撤销时，可不新建业务支付工单
支付系统说明：
1、组合支付的逻辑由支付系统实现，需要处理部分成功的异常
2、仅在扣款时创建订单并关联扣款工单流水
3、预授权撤销、完成、退款等操作中，不用创建新的支付订单，但会创建每次的交易流水，并通过流水关联撤销、完成、退款的业务支付工单
l 规则和要素
将所有的枚举改变为INT，以适应跨语言平台扩展
