請求結(jié)果判斷邏輯
機構(gòu)或商戶在收到接口請求返回信息后，需要根據(jù)對應(yīng)字段及判斷邏輯來確認該次請求的處理結(jié)果。否則會導(dǎo)致請求結(jié)果判斷錯誤，引起交易狀態(tài)同步錯誤的問題。
微信支付采用回包兩層判斷的邏輯，分別對應(yīng)的返回字段為return_code和result_code, return_code代表的是該次請求的通信結(jié)果，result_code代表該次請求的業(yè)務(wù)處理結(jié)果。
以Submit Quick Pay API為例：
-
1
當return_code和result_code均返回SUCCESS，表示通信成功，業(yè)務(wù)處理成功，即該筆訂單扣款成功；
-
2
當return_code返回SUCCESS, result_code返回fail，表示通信成功但業(yè)務(wù)處理失敗。但遇到該情況，機構(gòu)或商戶不能直接判定業(yè)務(wù)處理失敗，因為在某些極端情況下，可能出現(xiàn)返回業(yè)務(wù)處理失敗但實際成功的情況，建議機構(gòu)或商戶在該種情況下輪詢查單；
-
3
當return_code返回fail，則不會有result_code的返回，該次請求通信失敗，可直接判定交易失敗。
機構(gòu)和商戶在對接微信支付接口時，都需要遵循以上的判斷順序及邏輯。
注意：查詢訂單接口除了判斷return_code和result_code外，最終的訂單狀態(tài)需要根據(jù)trade_state字段來確認。即return_code和result_code均返回SUCCESS也僅代表查詢訂單業(yè)務(wù)處理成功，但所查訂單的狀態(tài)需要參考trade_state的返回內(nèi)容。
API請求頻次
微信支付的API接口都有一定的調(diào)用頻率限制，以防止對服務(wù)器產(chǎn)生過大壓力，影響業(yè)務(wù)的正常運轉(zhuǎn)。以下為常用接口的調(diào)用頻率限制，請機構(gòu)在系統(tǒng)邏輯設(shè)計時格外注意：
| 頻次限制(QPS) |
API |
頻次 |
| 查詢訂單 |
1800 |
| 統(tǒng)一下單 |
600 |
| 提交退款 |
150 |
| 查詢退款 |
300 |
| 提交付款碼支付 |
30 |
| 報關(guān) |
600 |
| 入駐子商戶 |
30 |
撤銷API
撤銷接口僅可對刷卡支付使用，用于完成刷卡支付異常訂單的閉環(huán)。
若當前訂單已支付成功，撤銷操作會對該訂單發(fā)起退款；若當前訂單尚未支付，撤銷操作會對該訂單進行關(guān)閉處理。
撤銷接口同樣支持重入，在撤銷結(jié)果不明確的情況下，可重新請求撤銷。商戶或機構(gòu)還可根據(jù)撤銷接口返回的recall字段來判斷是否需要重新請求撤銷。
不存在的訂單請求撤銷接口會返回SUCCESS，以保證業(yè)務(wù)的正常進行。
關(guān)閉訂單API
對于非刷卡支付的場景，需要調(diào)用關(guān)單接口完成異常訂單的閉環(huán)。
關(guān)單接口僅能對非成功狀態(tài)的訂單調(diào)用，支付成功的訂單無法進行關(guān)單操作。
建議機構(gòu)或商戶在最后一次查單獲取交易狀態(tài)非SUCCESS情況下，立即調(diào)用關(guān)單接口，中間切勿留有時間差。
APP支付傳參規(guī)則（機構(gòu)模式）
機構(gòu)在調(diào)用統(tǒng)一下單接口時，需要將商戶app對應(yīng)的appid傳入到sub_appid參數(shù)內(nèi)。
子商戶前端調(diào)用SDK時，注意參數(shù)均為子商戶號信息，即appid為子商戶APP的appid，partnerid為子商戶在機構(gòu)生成的子商戶號sub_mch_id。
小程序支付傳參規(guī)則（機構(gòu)模式）
子商戶在向機構(gòu)請求發(fā)起交易時，需要傳輸用戶的openid給機構(gòu)。
機構(gòu)在調(diào)用統(tǒng)一下單接口時，需要將子商戶小程序的appid傳入到sub_appid中，將子商戶傳輸?shù)膐penid傳入到sub_openid參數(shù)。
子商戶前端拉起支付時，傳入?yún)?shù)均為子商戶信息，即appid為子商戶小程序?qū)?yīng)的appid。
