# 6 公眾帳號支付接口

# 6.1 初始化請求接口

# 6.1.1 業務功能

初始化 JSAPI 請求，通過生成 token_id 來進行交互驗證。

# 6.1.2 交互模式

請求：後臺請求交互模式

返回結果+通知：後臺請求交互模式+後臺通知交互模式

# 6.1.3 請求參數列表

請求 url：https://gateway.wepayez.com/pay/gateway

POST XML 內容體進行請求

# 6.1.4 返回結果

數據按 XML 的格式即時返回

以下字段在 status 為 0 的時候有返回

以下字段在 status 和 result_code 都為 0 的時候有返回

# 6.2 原生態 js 支付接口

# 6.2.1 使用示例

接口需要注意：**所有傳入參數都是字串類型！**使用 JavaScript、PHP 等弱類型語言需 要關注一下。

示例代碼如下：

WeixinJSBridge.invoke('getBrandWCPayRequest',{
"appId" : "wx2421b1c4370ec43b", //公眾號名稱，由商戶傳入
"timeStamp":" 1395712654", //時間戳，自 1970 年以來的秒數
"nonceStr" : "e61463f8efa94090b1f366cccfbbb444", //隨機串
"package" : "prepay_id=u802345jgfjsdfgsdg888",
"signType" : "MD5", //微信簽名方式:
"paySign" : "70EA570631E4BB79628FBCA90534C63FF7FADD89" //微信簽名
},function(res){
if(res.err_msg == "get_brand_wcpay_request:ok" ) {}
// 使用以上方式判斷前端返回,微信團隊鄭重提示：res.err_msg 將在用戶支付成功後返回 ok，但並
不保證它絕對可靠。
});

getBrandWCPayRequest 參數以及返回值定義

# 6.2.2 交互模式

請求：後臺請求交互模式

返回結果+通知：後臺請求交互模式+後臺通知交互模式

# 6.2.3 請求參數列表

返回結果

注：JS API 的返回結果 get_brand_wcpay_request:ok 僅在用戶成功完成支付時返回。由 於前端交互複雜，get_brand_wcpay_request:cancel 或者 get_brand_wcpay_request:fail 可以統 一處理為用戶遇到錯誤或者主動放棄，不必細化區分。

注：商戶實現原生態頁面的請求地址必須提供支付授權目錄由服務商配置好，在微信提供的測試公眾帳號上無 法調起支付（測試時可以在手機微信端檔傳輸助手中進行）。

# 6.3 公眾帳號 JS 支付接口

# 6.3.1 業務功能

初始化 JSAPI 請求，通過生成 token_id 來進行交互驗證。 如調用時是用的原生態 js 支付，此接口可以忽略

# 6.3.2 交互模式

請求：後臺請求交互模式

返回結果+通知：後臺請求交互模式+後臺通知交互模式

# 6.3.3 請求參數列表

請求 url：https://gateway.wepayez.com/pay/jsIntl

該請求參數為 http queryString，即: https://gateway.wepayez.com/pay/jsIntl?token_id=xxx，如https://gateway.wepayez.com/pay/jsIntl?token_id=9a0610bc519e782e6275e8c7dd94a445

在服務號中點擊這個鏈接就可調起支付（用戶點擊頁面中的微信支付按鈕時實際上就是點擊的這 個鏈接，此種方式需配置固定的支付授權目錄：https://gateway.wepayez.com/pay/, 但不用像原生態 jsapi 支付那樣獲取那些參數後續的操作，測試時可以將組裝好的這個鏈接放到 手機微信端檔傳輸助手點擊調起支付接口）

注：組裝的請求鏈接在微信提供的測試公眾帳號上無法調起支付。

# 6.4 JS 支付通知接口

# 6.4.1 通知結果參數列表

通知 URL 是 6.1 節中提交的參數 notify_url， 支付完成後，平臺會把相關支付和用戶資訊發送到該 URL，商戶需要接收處理資訊。對後臺通知交互時，如果平臺收到商戶的應答不是純字串success或超過5秒後返回時，平臺認為通知失敗。平臺會通過一定的策略（通知頻率為0/15/15/30/180/1800/1800/1800/1800/3600，單位：秒）間接性重新發起通知，盡可能提高通知的成功率，但不保證通知最終能成功。

由於存在重新發送後臺通知的情況， 因此同樣的通知可能會多次發送給商戶系統。 商戶系統必須能夠正確處理重複的通知。

推薦的做法是，當收到通知進行處理時，首先檢查對應業務數據的狀態，判斷該通知是否已經處理過，如果沒有處理過再進行處理，如果處理過直接返回結果成功。 在對業務數據進行狀態檢查和處理之前， 要採用數據鎖進行併發控制， 以避免函數重入造成的數據混亂。

特別注意：商戶後臺接收到通知參數後，要對接收到通知參數裏的訂單號out_trade_no和訂單金額total_fee和自身業務系統的訂單和金額做校驗，校驗一致後才更新資料庫訂單狀態

後臺通知通過請求中的 notify_url 進行， post

以下字段在 status 為 0 的時候有返回

以下字段在 status 和 result_code 都為 0 的時候有返回

# 6.4.2 後臺通知結果回饋

平臺伺服器發送通知，post發送XML數據流，商戶notify_Url地址接收通知結果，接收方法 demo 有寫（如php中的callback方法，c#中的notify.aspx檔，java中的TestPayResultSerlet方法），商戶做業務處理後，需要以純字串的形式回饋處理結果，內容如下：

# 6.5 訂單查詢接口

# 6.5.1 業務功能

根據商戶訂單號或者平臺訂單號查詢平臺的具體訂單資訊

# 6.5.2 交互模式

後臺系統調用交互模式

# 6.5.3 請求參數列表

請求 url：https://gateway.wepayez.com/pay/gateway

通過 POST XML 內容體進行請求

以下字段在 status 為 0 的時候有返回

以下字段在 status 和 result_code 都為 0 的時候有返回

以下字段在 trade_state 為 SUCCESS 的時候有返回