以前寫過一篇如何對接第三方支付的文章如何高效對接第三方支付，因為對接的大多數是海外支付公司，這些公司有很多神奇的問題，往往會埋坑，所以開發之前，整理出問題串列，以便盡早發現和解除問題，保證按時上線，
問題如下
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/
往期文章回顧：
- Go語言
- MySQL/Redis
- 演算法
- 架構/網路/專案
- 思考/讀書筆記
轉載請註明出處，本文鏈接：https://www.uj5u.com/qukuanlian/256854.html
標籤：區塊鏈
上一篇：2021-02-04：第一年農場有1只成熟的母牛A，往后的每年：①每一只成熟的母牛都會生一只母牛 ②每一只新出生的母牛都在出生的第三年成熟 ③每一只母牛永遠不會死 。請問N年后牛的數量是多少 ？