以前寫過一篇如何對接第三方支付的文章如何高效對接第三方支付，因爲對接的大多數是海外支付公司，這些公司有很多神奇的問題，往往會埋坑，所以開發之前，整理出問題列表，以便儘早發現和解除問題，保證按時上線。
問題如下
1. 支付
a. 同一個訂單號，支付成功之前，是否可以使用該訂單號重複發起支付請求
b. 同一個訂單號是否能夠保障只能被成功支付一次
c. 支付過程是否有其他限制，導致支付失敗？比如：地區、ip等
d. 是否支持請求時設置同步/異步通知的url地址
e. 第三方需要支持請求時設置訂單過期時間
f. 請求支付的數據是否需要簽名，簽名規則是什麼，如果沒有如何防止數據不被篡改？
g.能否提供用戶測試的信用卡或者儲蓄卡等
2. 同步/異步通知
a. 同步通知的結果是否可信？是否需要同步通知到達時查詢一次支付結果以查詢結果爲準
b. 查詢的交易狀態與交易的實際狀態是否有時間延遲（如：用戶支付後，我方立即查詢是否會得到一致的結果）
c. 異步通知策略，通知的時間間隔，通知的次數，觸發異步通知的條件
d. 通知數據中是否包含交易號，即第三方系統內的一筆交易的唯一標示，以及通知的種類標示字段（交易成功通知/退款成功通知/其它通知）
e. 針對異步/同步通知如何判斷支付成功，是否有pending狀態（可發貨出庫的狀態）
f. 同步/異步請求的方式是GET/POST哪種方式，傳輸數據的方式是json/xml/formdata
g. 異步/同步返回的數據是否有簽名，如何進行驗證？如果沒有如何保證數據是安全未篡改的？
h. 是否有風控流程？時間間隔多久？超過間隔時間爲收到成功或失敗的通知導致發貨後的損失怎麼解決？
i. 哪個狀態可以認爲真正支付成功了？
j. 處理失敗是否會阻塞
3. 查詢
a. 是否支持訂單狀態查詢，通過我們的訂單號或第三方的交易流水號
b. 是否支持退款單狀態的查詢，如果不支持，如何檢查之前退款是否成功，主要用來檢測是否會重複退款
c. 支付訂單的查詢與退款訂單的查詢是否是孤立的？比如：支付單如果支付成功，無論該訂單是否退款，查詢的狀態都是支付成功，而退款狀態需要通過其他接口獲取
d. 接口是否有簽名相關安全措施，如果沒有如何保障安全
e. 查詢的金額不會因爲交易狀態的變更而發生變化
4. 退款
a. 是否支持部分退款，退款接口是否包含唯一退款單號標示，對於同一退款單號第三方要保證不超退不重複退。退款是否爲冪等操作。
b. 退款接口，直接調用退款接口即可，還是調用退款接口後還有異步通知
c. 需原路退款，確認退款時效和退款期限
d. 退款是否有任何限制？比如某種支付渠道需要支付後多少時間後纔可退款，某種渠道不支持部分退等，部分退款有無次數、頻率限制。
e. 退款必須只能由小米商城通過接口或者在其後臺手工操作，不能由用戶申請而直接進行退款
f. 如果在第三方的退款金額不足，第三方如何處理？理論上應該資金充足時自動重試
g. 如果是卡支付，用戶是否能夠直接向銀行申請退款，如果可以，這部分流程如何處理？
5. 對賬/結算
a. T+1日獲取第三方前一日的完整交易記錄，提供api還是ftp
b. 是否提供結算單明細：每一筆結算給mi.com的資金，由哪些交易構成的明細，以及第三方每一筆收的手續費、產生的費率等。
c. 對賬單的數據在交易產生後，每個字段值不應該發生變化，比如：某筆交易部分退款後，它的支付交易金額應該保持不變。
6. 線上配置
- 配置線上賬號需要多長時間
- 配置線上賬號需要什麼信息，對於這些信息有無特殊需求
7. 支付系統支持的qps爲多大
a. 常規系統支付的qps
b. 大型活動是否需要提前溝通，預估交易相關數值
c. 對方服務的部署位置
8. 開發&測試
a. 開發階段需要提供完備的測試環境、測試賬號
b. 測試如何模擬各種場景的case
最後
大家如果喜歡我的文章，可以關注我的公衆號（程序員麻辣燙）
我的個人博客爲：https://shidawuhen.github.io/
往期文章回顧：