1.設計思路

每個公司都有自己的支付系統，有很複雜的像支付寶這種，也有超級簡單的就是一個接入第三方支付。這裡我想設計一個簡易的完整的支付系統，我應為應當包括，支付閘道器，支付渠道，基本支付，以及風險監控。

1.1支付閘道器

支付閘道器是對外提供服務的介面，所有需要渠道支援的資金操作都需要通過閘道器分發到對應的渠道模組上。一旦定型，後續就很少，也很難調整。而支付渠道模組是接收閘道器的請求，呼叫渠道介面執行真正的資金操作。每個渠道的介面，傳輸方式都不盡相同，所以在這裡，支付閘道器相對於支付渠道模組的作用，類似設計模式中的wrapper，封裝各個渠道的差異，對閘道器呈現統一的介面。而閘道器的功能是為業務提供通用介面，一些和渠道互動的公共操作，也會放置到閘道器中。

1.2 支付渠道

這裡並沒有採用現在最流行的微服務的方式，因為考慮到渠道不會很多，而且一般支付的交易量不會太大。這裡一般有兩種拆分模式：

• 按渠道拆分，指每個渠道單獨拆分，對支付閘道器提供相同的服務。

• 按服務拆分，是按介面來拆分，分為支付，對賬，退款等子系統，所有服務都實現在一起。

這裡個人比較喜歡按渠道拆分，不喜歡按功能拆分。因為按照面向物件的使用習慣，按渠道拆分類似於面向物件，每個支付渠道就是一個支付物件，按服務拆分有點類似於面向過程，把整個支付的過程拆開來實現，本人常年使用Java所以更推薦按渠道拆分。

1.3基本支付

這裡的基本支付會涉及到你的業務系統，一般會涉及到虛擬貨幣,代付，應用內支付，賬戶支付（領錢，餘額），銀行卡支付，信用支付等。在這個模組中會處理我們的業務邏輯，實現整個貨幣在平臺內的流通。

1.4風險監控

我們在交易中如果發現大額交易或者異常交易，這個時候就要評估交易風險

檢查本次交易是否有風險。風控介面返回三種結果：阻斷交易、增強驗證和放行交易。

1. 阻斷交易，說明該交易是高風險的，需要終止，不執行第5個步驟；

2. 增強驗證，說明該交易有一定的風險，需要確認下是不是使用者本人在操作。這可以通過傳送簡訊驗證碼或者其他可以驗證使用者身份的方式來做校驗，驗證通過後，可以繼續執行該交易。

3. 放行交易，即本次交易是安全的，可以繼續往下走。

資料庫設計

這裡資料庫的話採用mysql，因為簡單輕量，當然還有很多涉及到具體業務的表就沒有發出來了。

1 pay_channel：可供接入的支付渠道

2 ali_pay支付應用資訊

3 wx_pay微信支付應用資訊

4 pay_order支付訂單

具體流程如下：

未完待續