本文執行個體分析了php進行支付寶開發中return_url和notify_url的區別。分享給大家供大家參考。具體分析如下:
在支付寶處理業務中return_url,notify_url是返回些什麼狀態呢,我們要根據它來做一些處理就必須瞭解return_url,notify_url的區別,下面我就來給大家介紹介紹.
問題描述:
我在處理支付寶業務中出現過這樣的問題,付費完成後,在支付寶跳轉到商家指定頁面時,訂單狀態已經更新,通過調試發現是支付寶先通知notify_url,完成了訂單狀態.
支付寶return_url和notify_url通知順序問題:
順序不一定的,請別以先後順序來做判斷,具體如何判斷,是根據您當前資料庫裡的狀態和剛從支付寶裡擷取到的狀態做對比來判斷是否有做過處理了.
關於支付寶return_url和notify_url的區別,同步通知頁面特性(return_url特性):
(1) 買家在支付成功後會看到一個支付寶提示交易成功的頁面,該頁面會停留幾秒,然後會自動跳回商戶指定的同步通知頁面(參數return_url);
(2) 該頁面中獲得參數的方式,需要使用GET方式擷取,如request.QueryString("out_trade_no")、$_GET['out_trade_no'];
(3) 該方式僅僅在買家付款完成以後進行自動跳轉,因此只會進行一次;
(4) 該方式不是支付寶主動去調用商戶頁面,而是支付寶的程式利用頁面自動跳轉的函數,使使用者的當前頁面自動跳轉;
(5) 基於(4)的原因,可在本機而不是只能在伺服器上進行調試;
(6) 返回URL只有一分鐘的有效期間,超過一分鐘該連結地址會失效,驗證則會失敗;
(7) 設定頁面跳轉同步通知頁面(return_url)的路徑時,不要在分頁檔的後面再加上自訂參數。例如:
錯誤的寫法:
複製代碼 代碼如下:
<http://www.alipay.com/alipay/return_url.php?xx=11>
正確的寫法:
複製代碼 代碼如下:
<http://www.alipay.com/alipay/return_url.php>
伺服器非同步通知頁面特性(notify_url特性):
(1) 必須保證伺服器非同步通知頁面(notify_url)上無任何字元,如空格、HTML標籤、開發系統內建拋出的異常提示資訊等;
(2) 支付寶是用POST方式發送通知資訊,因此該頁面中擷取參數的方式,如:
request.Form("out_trade_no")、$_POST['out_trade_no']。
(3) 支付寶主動發起通知,該方式才會被啟用;
(4) 只有在支付寶的交易管理中存在該筆交易,且發生了交易狀態的改變,支付寶才會通過該方式發起伺服器通知(即時到賬中交易狀態為“等待買家付款”的狀態預設是不會發送通知的);
(5) 伺服器間的互動,不像頁面跳轉同步通知可以在頁面上顯示出來,這種互動方式是不可見的;
(6) 第一次交易狀態改變(即時到賬中此時交易狀態是交易完成)時,不僅頁面跳轉同步通知頁面會啟用,而且伺服器非同步通知頁面也會收到支付寶發來的處理結果通知;
(7) 程式執行完後必須列印輸出“success”(不包含引號)。如果商戶反饋給支付寶的字元不是success這7個字元,支付寶伺服器會不斷重發通知,直到超過24小時22分鐘。
一般情況下,25小時以內完成8次通知(通知的間隔頻率一般是:2m,10m,10m,1h,2h,6h,15h);
(8) 程式執行完成後,該頁面不能執行頁面跳轉。如果執行頁面跳轉,支付寶會收不到success字元,會被支付寶伺服器判定為該頁面程式運行出現異常,而重發處理結果通知;
(9) cookies、session等在此頁面會失效,即無法擷取這些資料;
(10) 該方式的調試與運行必須在伺服器上,即互連網上能訪問;
(11) 該方式的作用主要防止訂單丟失,即頁面跳轉同步通知沒有處理訂單更新,它則去處理;
(12) 通知ID(參數notify_id)只有一分鐘有效期間,超過一分鐘該次通知會驗證失敗。一旦驗證成功下次再驗證就會失效。
希望本文所述對大家的php程式設計有所協助。