# 6 掃碼支付接口

# 6.1 掃碼支付接口

# 6.1.1 業務功能

初始化掃碼請求，通過該請求生成二維碼來進行掃碼支付.

# 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 掃碼通知接口

# 6.2.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方式給商戶系統（通知參數內容為 xml 的字串）

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

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

#6.2.2 後臺通知結果回饋

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

# 6.3 訂單查詢接口

# 6.3.1 業務功能

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

# 6.3.2 交互模式

後臺系統調用交互模式

# 6.3.3 請求參數列表

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

通過 POST XML 內容體進行請求

# 6.3.4 返回結果

數據按 XML 的格式即時返回

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

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

失敗)

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