# 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是支付接口中提交的參數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 的時候有返回