前言
Hi，各位好久不見，我是CrazyCodes，今天我們來聊聊支付系統。
支付系統是每個系統都必備的模組之一，也是眾多模組中最核心的功能，如果支付出現問題，那麼意味著會直接影響到產品收益，事故嚴重程度高。
本篇我們聊聊支付系統的基本流程，它們分別為付款、通知（包括同步通知、非同步通知）、查詢、退款以及對賬，下方是本篇文章會用到的流程互動圖。
付款
先聊聊發起支付前需要做哪些事
- 使用者在選中心儀的商品後，首先我們建立訂單，建立訂單的基本資訊，如商品的名稱、價格、數量以及使用者的收貨地址等後是我們後續需要的引數
- 其次如果系統中整合多種支付方式的話，我們會有一個收銀臺的頁面，供使用者選擇使用某個支付方式完成支付，例如支付寶、微信、銀聯等
- 在使用者完成選擇後，我們根據三方支付系統需要的引數組裝好，向三方發起支付請求，一般需要的資訊大致包括 訂單號、商品的名稱、價格、同步&非同步通知地址，有部分支付方式也需要使用者的收貨地址、使用者的銀行卡資訊（卡號、cvv、日期）當然使用者隱私資訊是需要加密傳輸的，總而言之，三方支付系統需要什麼，我們就傳什麼。
- 當一切準備就緒，我們通過三方支付系統提供的PayUrl發起付款。
通知
使用者無論付款成功或失敗，三方都會至少給到我們一個同步通知，那麼我們先了解下什麼是同步通知
- 如上圖所示，當三方系統確認使用者已完成付款，會根據我們在付款時提供的通知地址，向我方發起直接跳轉回本站的POST或者GET請求，請求附帶三方傳輸給我們一些關鍵交易資訊，如果是移動端這類通知會在呼叫支付的Callback的回撥結果內
- 通知大致的引數有我們傳輸的大部分資訊、交易狀態、第三方交易號、簽名（用於雙方系統驗證來源）和一些可能暫時用不到的資訊
- 當我們接收到回傳的資料後，首先進行校驗，保證不是欺詐請求，校驗的內容無非是雙方系統確定的簽名演算法，還有一些關鍵欄位，例如金額是否匹配等。
- 我們不能完全信任三方系統傳送的資訊，在我們接收到通知後，如果三方系統有提供查詢介面，我們還是需要通過查詢方式，反查三方訂單交易關鍵資訊，以保證付款確實順利完成。
- 當驗證完成後，根據自己系統邏輯，將訂單進行後續流轉
瞭解完同步通知後，我們再看下非同步通知，有部分朋友比較疑惑，有同步通知了，那麼為什麼還需要非同步通知，你可以暫且理解為同步通知實際是完成了付款流程，這是一個瞬發的過程，三方系統也是暫時認為付款已完成，但如果出現異常或者使用者在三方秒退款或者申訴，那麼我們的流程將會受到影響。
如上圖所示，三方系統一般也需要歸檔，就是系統完成全部校驗後，確保交易安全完成後，叫交易加入資料庫中，這時，整個付款流程才徹底完成。這時三方會通過我們提供的非同步通知地址（有時非同步和同步通知是一個地址），通知我們付款確實已經完成。
我們接收到三方後，依舊先進行校驗，防止請求欺詐，而後確保資訊正確性，依舊是去請求查詢介面，非同步通知與同步通知最大的區別是我們在確保資訊完整並正確後，需向三方系統返回一個雙方系統約定的值，可能是HTTPCODE = 200 ，也或者Document內寫個200或者完成等等，不同三方系統，要求不同。
退款
有買就有退，退款佔支付模組一半的邏輯，大致流程與支付時沒有太大區別，如上圖所示。
只是大部分三方系統，退款一般通過HTTP Reponse返回結果，並不會有同步通知，我們根據使用者發起退款的商品金額建立退款單，並組裝必要引數後，請求三方提供的RefundUrl，完成退款申請，注意，是退款申請，為什麼是退款申請而不是退款呢？這實際是一個時效的問題，一般退款都不是實時的，因為三方系統可能還有下方鏈路（例如下方可能對接的某銀行），那麼退款是需要一條鏈路的自動審批或者人工審批的，當全鏈路確認可以退款時，才可以完成退款。
因為是非實時的，所以無同步通知，但大部分系統內是有非同步通知的，當三方系統確認退款完成後，會根據我們發起支付時傳輸的非同步通知地址，通知我方退款完成，並攜帶必要引數。
當我們接收後，依舊先進行校驗，以防欺詐，而後還是需要通過三方提供的查詢介面查詢退款情況，並根據自身系統邏輯，完成退款完成的打標，並通知使用者。
當然，如果沒有非同步通知的話，我們可以通過延時佇列，失敗佇列重試或者定時指令碼的方式，使用查詢介面，不定時向三方請求退款結果。
對賬
支付或者退款完成後，還沒有結束，我們應當定時拉取賬單，大部分三方系統都會提供例如bill的介面，獲取賬單後，我們要用我方系統資料與三方系統資料對比，確保每筆交易金額、交易時間、交易狀態完全正確，當遇到錯誤的地方，就應該去查詢問題點了。
只有對賬完成後，才是正確完成了整個交易，否則你公司的財務早晚會找到你頭上的，到那時這件事情就不僅僅是程式實現那麼簡單了。
致謝
感謝你看到這裡 ，希望本篇文章可以幫到你，謝謝。