電商支付系統設計（一）——可行性分析
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，以適應跨語言平臺擴充套件