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