業務流程
上文提到由於支付處理的流程複雜性，為了避免因為冗長的流程阻塞降低了處理效率，支付系統中多使用非同步機制，將整個支付業務流程拆分為多步處理。支付系統將流程劃分為業務受理、支付前置和支付閘道器、終態獲取、結果處理四個大部分，各部分之間以訊息佇列或系統之間的互動分隔。風控和路由屬於支付前置服務，但由於其重要性和複雜性，將它們提出來分別介紹。
下面的圖是兩種典型的交易時序圖：
業務受理
業務受理介面是與商戶系統的互動處，主要功能為接受交易業務，響應給商戶的是受理結果，而並非交易結果，交易結果會通過非同步方式告知商戶。
為了考慮介面的安全性，受理介面要依次驗證支付請求報文的安全性、商戶的許可權、引數的合法性。為了保證保證交易入口的可用性，特殊介面還要限制商戶的請求頻率。
由於受理結果要同步響應給商戶，很長的驗證流程是不合適的。要儘量保證受理介面進行的是基礎驗證，對其他複雜的的驗證流程，進行非同步處理，驗證無法通過的再置交易為失敗為好。
受理介面還需要特別注意到的一點是要保證系統受理和介面響應的原子性，即要保證響應給商戶的受理結果是真實的，可查詢的。要保證受理結果響應給商戶後，該筆交易要能查詢到，這時候便需要資料落地和響應商戶的順序了。為了保證安全，要在資料落地後再將受理結果響應給商戶，避免出現資料丟失的情況。
此時要開始非同步流程的第一步了，受理成功待處理的交易應該在訊息佇列內。
風控
風控的概念上文已提過，這裡說一下風控系統的簡單實現。
首先是交易量風控，交易金額過大、交易頻率過高的交易都是需要注意的，通過配置對不同交易分類的閾值限制，將可疑交易打上風控標籤，再新增後續驗證來確認。
然後是交易慣性風控，這就需要對比使用者畫像來確定了。通過分析使用者的多次支付習慣，為使用者“畫”一張大概的“畫像”，支付時對比是否符合其支付習慣，對異常的交易進行後續驗證。（由於使用者支付的量不大，無此功能，不再多提）
後續驗證可以分互動性交易和非互動性交易來分別處理，對非互動性交易，如代收或代付，並不要求交易的實時性，可以採用介面稽核或人工稽核的方式。而互動性交易，如收銀臺交易，稽核肯定不能達到要求的實時性，新增驗證步驟，如手機驗證碼等二次驗證則十分適用。
支付路由
支付路由，簡單的說就是選擇一條支付通道。支付通道要有一定維度上的優先順序，這裡提到優先順序，是因為支付通道偶爾會因為系統維護、銀行維護等原因關閉，那麼在可選通道之間要有優先順序來調控優先通道不可用時的替代通道。單純的通道路由在技術上實現起來可能非常簡單，可是通道路由要考慮的因素還有很多：
- 三方系統三方系統支援：最基本的要求了，一般三方系統對賬戶型別、卡型別、銀行等有不同的支援範圍。
- 便宜：很直觀的要求，為了公司的開銷考慮，能使用價格低的通道最好。雖然低價格在一定程度上代表著低質量，會埋下各種各樣甚至不可思議的坑。
- 通道限流：由於各個系統對通道的限制不同，在達到通道上限後自然要限制交易頻率。還有些三方系統比較傲嬌，接了我們的支付通道卻不用也不行，所以支付通道的流量還要有下限。
- 動態調節：動態調節是通道路由的完全態會有的功能，和分散式系統中對各個伺服器的監控類似，實時監控通道的狀態，在判斷通道的失敗率達到某個閾值後自動關閉通道，使用替換通道。並間隔一段試探通道的狀態，在其交易恢復正常後再將通道開啟。
支付閘道器
支付閘道器是支付系統與三方系統的互動介面，支付閘道器的設計要考慮的重點是報文的互動。除了普通系統要進行的引數驗證、內外系統引數對映、各種請求類的包裝外，支付系統要額外考慮的有：
- 報文簽名和加密：這個各個支付系統會有不同的要求，見招拆招即可，這就需要掌握一些加密知識了，也是我之前花很多時間研究通訊加密的原因（說起來還挺敬業 = =）。
- 日誌：閘道器日誌很重要！！！不光是作為與三方系統互動的憑證，也是排查錯誤的關鍵資訊。一般會將原始（強調一下）報文記錄下來，包括請求引數、響應引數、耗時等資訊。
終態獲取
支付系統的交易除了需求實時性較強的快捷支付外，其他交易型別一般都是非同步，那麼終態的獲取就靠主動查詢和非同步回撥通知。
非同步回撥通知：非同步回撥通知是最基本的獲取三方終態的方式了，即支付系統在支付請求時提供一個通知地址，在三方系統處理完交易後請求此地址並附帶交易結果資訊。需要注意報文驗籤防止報文偽造。另外通知一般會多次通知以確保通知到達，還要給三方系統符合規則的響應，以在自己系統處理完交易後，告訴三方系統停止通知。
主動查詢：主動查詢是對非同步回撥通知的保證。在有的系統（呵呵）不提供回撥通知或自己系統故障通知失敗，或對交易的實時性要求很高，而三方系統的非同步通知延遲嚴重時，主動查詢就非常重要了。需要注意查詢時機，一定要確認三方系統已完全受理了交易且可查詢後再呼叫查詢介面。
結果處理
獲取到支付結果後，不光要及時更新自己系統內的支付狀態，還要考慮對交易的後續處理：
- 結果通知：同三方系統通知支付系統，支付系統要將支付結果及時通知商戶。為了確保通知成功，重試機制是必不可少的，這裡考慮三方系統通知支付系統的邏輯。
- 推送賬務系統：由於支付系統的賬務由賬務和資金管理系統負責，支付系統只負責交易結果的推送。單獨的賬務和資金管理系統功能介紹見下；
- 觸發統計：為了保證交易統計的實時性，在支付成功後儘快統計支付結果。
支付結果在確認後正常流程內不再變動，為了減少支付結果的處理對交易表的侵入性，可以使用另一張 交易終態表 來承擔交易結果處理的記錄。至於兩張表的資料同步，使用資料庫的事務即可。
賬務和資金管理
賬務和資金管理系統是為了在資金流上確保交易的正確。
支付系統之間一般在第二日進行前一日交易的資金結算。賬務負責維護各個商戶與支付通道的對應銀行賬戶，並根據當日的交易結果彙總出資金的應收應付，第二日財務人員根據應收應付和實收實付進行轉賬和核銷。
附屬服務
附屬服務不屬於交易流程的一部分，但它們也是必不可少的部分，對異常交易的排查、修復有著重要意義。
對賬
對賬是對前一日交易在全域性上的對照，不同於賬務和資金管理系統，對賬是在資料流上確定交易的正確性，一般的對賬流程如下：
- 下載對賬檔案 針對各三方系統的下載方式：FTP/HTTP 獲取到對賬檔案
- 標準化處理：將格式為 txt/xml/cvs/zip 的三方系統對賬檔案處理成一種選用格式；
- 本地對賬準備：可以根據資料量的大小，從源庫/從庫/nosql/檔案方式準備與三方系統對賬檔案的對比
- 兩個賬務資料對比。
- 差異資料修復(人工/後續)
監控
監控在每個完備的系統都會存在，不過一般是運維層面上的，支付系統更多的是在業務層面上的監控。監控系統一般監控交易異常、通道異常等影響正常交易的狀況，並及時報警告知運營或技術人員。
監控方式一般有：
- 統計法：定時對比統計資料與監控閾值，在統計資料的異常比例超出監控閾值時觸發報警。
- 試探法：以測試交易來定時試探系統的穩定性和三方通道的穩定性。
- 埋點法：在支付關鍵節點埋點，並檢驗交易狀態是否在期望狀態。
統計
統計資料一般包括，交易總額，手續費，交易總筆數，成功率等，一般根據業務線、支付通道、銀行等維度來分別統計。
對運營人員來說，統計資料可以幫助在全域性上觀察交易狀況，作出決策；對於業務流程來說，統計資料可以作為通道路由的基礎，如在支付通道交易異常率較高時降低其優先順序等，也可以為監控系統提供資料；對技術人員來說，統計可以幫助有方向地優化系統。
小結
理清了支付的各個必備模組，系統設計應該就會很清晰了，完成了系統設計，後續的工作就剩下程式碼的堆砌和完善了。
支付服務中的每一塊都有一定的“門道”，有機會和必要的話，會單獨拿出來一塊寫。
感謝關注。