引言
本篇是本次支付系列的一個終篇，是博主就目前的支付經驗一個總結，如果後期博主能有幸接觸到大型支付公司的架構和有更深層次的理解，可能會繼續更新本系列。
1、銀行卡簽約
1.1、支付通道優先級
第三方支付平臺穩定性參差不齊，穩定點的價格會貴點，便宜的可能會有各種意想不到的坑等着你，傲嬌點的支付通道會要求最低交易量。設置支付通道的優先級，就是在支付通道關閉後，系統自動的切換備選支付通道。
1.2、銀行卡簽約次數
第三方支付平臺的收費標準是簽約成功一次就收費一次，同一張銀行卡同一個支付通道的也要收費。因此，系統必須判斷客戶一張銀行卡只需簽約一次。
1.3、銀行卡簽約日誌
客戶什麼樣的人都有，有的客戶銀行卡簽約的時候用的建行的卡，確認的時候換成了交行的卡，然後投訴說銀行卡簽約始終有問題，這時候日誌的作用就體現出來了。
2、支付
2.1、請求接口
支付接口需要預防客戶表單重複提交，保證接口的冪等性，併發加鎖處理，同時支付的參數需要進行安全校驗。
2.2、請求超時
支付請求提交給第三方支付後，可能由於網絡原因，對方沒有接收到，請求超時；可能是對方收到了，響應的時候，網絡異常了。此時，不應該隨便的選擇重試機制，應該採取保守的策略，因爲無法知道訂單的處理狀態，可以將訂單置爲處理中，後面利用同步查詢接口，對該筆訂單進行查詢。
2.3、返回狀態碼
支付成功的結果是比較好判斷的，支付失敗的結果原因很多，遇到不確定的狀態碼，一定要多向第三方支付多求證，系統業務層面對狀態碼只能一一比對，禁止使用else。
2.4、異步通知
異步通知接口需要校驗通知的IP是否是對應第三方支付、通知金額是否是訂單的金額，報文的安全性，避免以及接口的冪等性。
2.5、同步查詢
支付的結果一般是以異步回調通知爲準，但是由於網絡原因或者其它異常原因，導致異步通知失敗，此時需要進行同步查詢，同步查詢一般以定時任務方式，請求的間隔時間需要詢問第三方支付，每個支付通道的時間會有差異，不能過早的查詢，避免對方還沒來得及處理，返回“交易不存在”，導致我們將系統訂單的支付狀態錯誤的處理，造成金額的損失。同時，對於“交易不存在”的狀態，我們一定要謹慎的處理，最好的方法是預警，通知人工處理。
2.6、支付日誌
支付日誌很重要！ 支付日誌一定要記錄原始的報文、請求的參數、相應的結果、耗時等信息，因爲這是排查錯誤的有效方式、與第三方支付交流的憑證。
3、對賬
對賬一般是第二日對前一個交易日資金的結算，包括各個支付通道之間的應收和應付的彙總，對賬最好細分到具體的訂單 ，如果賬有差異的時候，方便排查問題。
4、監控
監控常見的是運維層面的，支付交易的要求更爲嚴格，需要業務層面的監控，比如：遠程資金是否充足。更爲嚴格的應該對支付通道的穩定性、用戶的交易是否異常進行監控，發現異常郵件通知相關人員。
5、測試
測試是重要的一個環節，所有的場景必須在測試環境下進行模擬一遍，不同的銀行卡、資金等都要走一遍流程；線上的環境中，必須至少要走一筆完整的流程，遇到項目更新內容比較多時，一定要限制用戶流量，待確定支付穩定可用後，再分批放開所有的用戶，防止災難性的後果。
結束語
支付的坑不限於文中描述的這些內容，上面是需要十分注意的坑，在支付系統開發中，一定要保持謹慎的態度，保持保守的操作，要保證要異常回滾，補償等機制，支付的總結就到這了，希望本文能夠對大家有所幫助。