商戶聚合支付系統設計（一）

產品概述與整體設計

背景

如今，網購已經滲透到人們日常生活中的方方面面，做為網購的載體，網際網路電商平臺發展如火如荼，支付功能做為其不可或缺的一部分，實現起來，也有各種各樣的方案。根據自己有限的認知，我主觀上把目前行業內的支付實現方案做以下歸類：

• 持有支付業務許可證，又稱支付牌照，自有支付品牌，比如阿里的支付寶、騰訊的微信支付（財付通）、京東的京東支付等；
• 自建第三方支付聚合平臺，對接第三方支付（支付寶、微信支付、中國銀聯、各大商業銀行直連等），為其自有訂單提供支付功能；
• 一些研發資源有限的電商平臺，選擇市場中直接能提供全套聚合支付的支付平臺，省去研發環節，能夠以最短時間較低的成本為其平臺提供支付功能。

我從開發者的角度，主要針對第二類，講述怎麼去構建商戶自己的聚合支付平臺，以及投產上線後所需要主意的事項，打造一套簡單、穩定、高效的聚合支付平臺。

整體設計

一個完善的聚合支付系統，擁有支付閘道器、主動對賬、退款閘道器、支付/退款狀態查詢等功能模組。我會以LNMP架構為基礎，細分成六個章節對每一部分做盡量詳細的說明。

   

聚合支付平臺的核心，就是怎麼合理的去管理接入的各種支付SDK，很多童鞋從官網下載到SDK，幾乎不做任何邏輯修改，就直接放到專案的目錄中使用，這樣做雖然開發成本很低，但弊端頗多，首先要說的就是不易維護，各支付SDK程式碼結構、風格不一樣，後期維護成功高；程式碼各自為政，沒有統一的呼叫方法；配置分散，無法集中維護系統配置項；無法提供統一有效的日誌資料等。因此，我建議首先定義一個Interface，如下圖：

然後，每次接入新的支付方式的過程，其實就是實現該Interface的過程。

通常情況下，一種支付方式有一個class[將其class備註為支付類]來實現，但面對一種支付方式提供了多種支付場景，比如微信（提供了公眾號支付、APP支付、掃碼支付、H5支付、小程式支付、微信免密代扣等）、中國銀聯（提供了PC閘道器支付、WAP支付、APP支付、銀聯雲閃付等），我們該怎麼辦，我建議針對每種不同的支付場景，都有單獨的class來實現，理由如下：

• 不同的支付場景，程式執行的流程也不一樣，比如中國銀聯PC閘道器支付，是需要將支付報文通過客戶端瀏覽器表單POST給銀聯支付閘道器，跳轉至銀聯支付網頁進行支付，而銀聯APP支付則是通過curl將支付報文提交給銀聯支付閘道器，再將其返回的tn碼返回給商戶APP，商戶APP憑該tn碼發起支付交易；
• 對訂單系統的訂單支付方式展示更加準確，分配給商戶不同購物平臺（PC端、H5端、APP）的支付方式id是唯一的。如果商戶系統不同支付場景所申請的商戶號不一樣，則需要在推送至財務系統的支付方式也不能重複，否則無法對賬；
• 支付類的程式碼邏輯只關注於自身的支付邏輯處理，不引入額外的判斷流程。

那麼，就有童鞋就會想到了，一個很頭疼的問題，程式碼冗餘。大部分第三方支付，雖然提供了不同支付場景，但基礎介面都是一樣的，只是部分引數不同，或支付流程上面的少許差別。這時候我們就要考慮好以第三方支付平臺為單位來封裝一個支付基類，該支付基類實現其所必須的介面呼叫，比如微信支付，程式碼如下圖：

上面分別提到了 支付Interface、支付類、支付基類三個概念，它們之間的關係是怎樣的，見下圖

對上圖做簡要說明，PaymentHandlerInterface是所有支付類的介面，WechatPayment是所有微信支付類的基類，WechatAPPPayment、WechatJSAPIPayment、WechatNativePayment都是提供支付服務的支付類，都需要繼承WechatPayment並實現PaymentHandlerInterface介面。同理，系統如果需要接入銀聯線上支付，那麼就需要按照開發文件實現一個ChinaPayPayment做為銀聯線上支付的基類，然後分別開發出具體支付場景的支付類，比如ChinaPayAPPPayment(銀聯app支付)、ChinaPayWAPPayment(銀聯wap支付)、ChinaPayPCPayment(銀聯pc支付)，這三個支付類需要繼承ChinaPayPayment並實現PaymentHandlerInterface介面。

原文地址：https://blog.csdn.net/think2017/article/details/79820786