系統中如果要接入支付功能，目前基本上有三個大的場景。第一個場景是，接入第三方聚合支付接口，也就是說，這個聚合接口幫你搞定了支付寶，微信，銀聯等支付渠道的打通，在我們自己的系統中，只需要跟這個聚合接口進行交互就能實現支付功能；第二個場景是，系統直接跟支付寶，微信，銀聯，或者銀行進行對接，此時我們需要去調試各個支付系統的接口，處理好，並對我們系統的用戶包裝成一個統一的支付通道，方便用戶操作。
此類接口，一般是先進行各個參數的組裝，參數加密，而后調用支付系統（無論是聚合，還是各個主流的支付系統）的支付接口獲取到有效的支付鏈接；而后前台將該支付鏈接展示給用戶，用戶輸入密碼等，進入到各個支付系統的支付通道，此時用戶進行支付操作。用戶支付完成后，對應的支付系統會根據我們調用支付時傳入的參數，調用我們系統的回調接口。
此時我們需要考慮一些容易出問題的點：
1.用戶在對同一訂單進行支付時，可能會誤操作或者網關重發，這時我們需要考慮這個支付接口的冪等性，即用戶調用一次和調用多次的結果應該保持一致。如果是在微服務體系下，支付模塊部署了多個服務，尤其需要注意這個問題，此時我們可能需要使用一個分布式鎖，保證只有一個請求能夠完成這次支付處理，其余的請求不予處理。
2.回調的接口也需要考慮冪等。第三方支付系統在進行支付回調時，考慮到失敗的情況，也可能會進行多次重復的回調，那么我們系統在進行處理時，也要考慮多次回調的處理結果應該保持一致。
3.如果整個支付過程是阻塞的，那么調用支付系統接口時，我們的系統可能還沒有完全處理好相關的數據，比如支付訂單的存儲。也就是說，支付系統支付接口的調用是先於我們系統處理好支付訂單的存儲的，如果此時支付系統的回調已經到達我們系統，那這個時候可能回調接口會發現這個支付訂單並不存在。為了避免這種問題，我們可以將發送支付請求與對應的數據進行異步處理。大多數情況下，我們可以將支付請求放入一個延時隊列，當確認對應的數據准備工作完成時，這個請求再發出，此時支付系統進行回調的時間消耗即時是0ms，支付數據與訂單數據也能進行正常的后續處理，整個支付動作完成。
待補充......