支付寶接口使用文檔說明 支付寶異步通知(notify_url)與return_url

現支付寶的通知有兩類。
A服務器通知,對應的參數為notify_url,支付寶通知使用POST方式
B頁面跳轉通知,對應的參數為return_url,支付寶通知使用GET方式 (通知地址不需要像以前一樣去賬戶內設置,而是由客戶在支付的時候通過參數傳遞給我地址。

例如 notify_url=http://www.xxx.com/notify_alipay.asp 注意:www.XXX.com是您網站的域名,也可以用ip地址代替。對于服務器通知,ip地址一定是公網的,私有地址(例如10.2.1.1或者192.168.1.1)支付寶無法通知到客戶端)

以下內容來自支付寶官方網站,不過由于地址改變了,導致原帖無法訪問,通過快照查找到其內容,特分享一下.

  1. 確認您使用的接口是用notify_url還是return_url。
  2. notify_url為服務器通知,支付寶可以保證99.9999%的通知到達率,前提是您的網絡通暢。
  3. return_url為網頁重定向通知,是由客戶的瀏覽器觸發的一個通知,若客戶去網銀支付,也會受銀行接口影響,由于各種影響因素特別多,所以該種類型的通知支付寶不保證其到達率。
    買家付款成功后,會跳到 return_url所在的頁面,這個頁面可以展示給客戶看,這個頁面只有付款成功才會跳轉,并且只跳轉一次..
    notify_url: 服務器后臺通知,這個頁面是支付寶服務器端自動調用這個頁面的鏈接地址,這個頁面根據支付寶反饋過來的信息修改網站的定單狀態,更新完成后需要返回一個success給支付寶.,不能含有任何其它的字符包括html語言.
    流程:買家付完款(trade_status=WAIT_SELLER_SEND_GOODS)--->支付寶通知notify_url--->如果反饋給支付寶的是success(表示成功,這個狀態下不再反饋,如果不是繼續通知,一般第一次發送和第二次發送的時間間隔是3分鐘)
    剩下的過程,賣家發貨,買家確認收貨,交易成功都是這個流程

大家想必都有這種困惑——拿到支付寶的接口代碼后,盡管里面的程序有注釋,接口代碼包中也附有開發說明,但還是不知道該如何入手。這不難想象是什么原因,因為自己并不了解這個接口的工作原理是什么?
那么這篇文章就是要向大家全面展示關于支付寶接口的所有東西,以便大家能快速上手把接口接入自己的項目中,也能幫助那些已經對支付寶接口有所了解的程序開發者們更了解支付寶的一些通用規則、特殊用途等。

正題開始——

一、 結構
a) 一般由兩部分組成,接入部分與通知返回部分。接入部分即為傳遞參數等信息組合成超級鏈接,并用該鏈接來進行跳轉。通知返回部分則是支付寶服務器對該筆訂單處理完畢后,通知與返回該筆訂單的詳細信息到商戶服務器,商
戶服務器接收到后,并對其進行數據處理。
b) 以實物標準雙接口ASP代碼中的程序為例。
i. 接入部分的頁面文件包含:配置頁alipay_Config.asp、方法詳細頁alipay/Alipay_Payto.asp、程序入口頁index.asp以及MD5加密方法類頁alipayto/Alipay_md5.asp。
ii. 通知返回部分的頁面文件包含:方法詳細頁alipay/Alipay_Payto.asp、MD5加密方法類頁alipayto/Alipay_md5.asp、支付完成后(支付寶處理完畢后)自動跳轉回的自定義頁面return_Alipay_Notify.asp、兩方服務器間相互交互(肉眼無法見到的)通知頁Alipay_Notif
y.asp。
這里大家可以一目了然,MD5加密方法類與方法詳細頁不論是哪部分都有被調用,因此這兩個文件可視為核心代碼部分,若想理解接口的工作原理則要從該部分入手。
c) 以實物標準雙接口的ASP.NET C#語言代碼程序為例:
i. 接入部分的頁面文件包含:無需更改的ALIPAY的類文件App_Code/AliPay.cs及入口頁面文件Default.aspx
ii. 通知返回部分的頁面文件包含:兩方服務器間相互交互(肉眼無法見到的)通知頁Alipay_Notify.aspx、支付完成后(支付寶處理完畢后)自動跳轉回的自定義頁面Alipay_Return.aspx、
無需更改的ALIPAY的類文件App_Code/AliPay.cs
這個架構是否更容易理解了?沒錯,核心部分的運算過程就在AliPay.cs這個文件中。


二、 工作原理
大家對結構部分已經有所了解,那么我們就開始分析具體的這個接口是如何運作的。
a) 接入部分原理
i. 第一步——選定參數信息:
結合技術文檔以及接口代碼DEMO,選定傳遞給支付寶服務器的參數,以實物標準雙接口為例。如必傳項service、partner、seller_email、sign、sign_type、out_trade
_no、price、subject、quantity、payment_type以及最少一組的物流信息參數三個logistics_type、logistics_fee、logistics_payment
等,選填項body、discount、show_url等。
以ASP.NET C#語言代碼程序為例:

string service = "trade_create_by_buyer";
string seller_email = "aaaa@126.com";
string sign_type = "MD5";
string key = "********************************";
string partner = "2088************";
string _input_charset = "utf-8";
string show_url = "http://www.alipay.com/";
string out_trade_no = TxtOrderno.Text.Trim();
string subject = TxtSubject.Text.Trim();
string body = TxtBody.Text.Trim();
string price = TxtPrice.Text.Trim();
string quantity = TxtQua.Text.Trim();
string logistics_type = "POST";
string logistics_fee = TxtPost.Text.Trim();
string logistics_payment = "BUYER_PAY";
string notify_url = "http://www.xxx.com/swnet05utf8/Alipay_Notify.aspx";
string return_url = "http://www.xxx.com/swnet05utf8/Alipay_Return.aspx";

ii. 第二步——排序:
把這些參數的變量名(即技術文檔里給出的變量名,以這種方式組合:service=”trade_create_by_buyer”作為一串字符串)按從a到z的順序依次排序。以ASP.NET C#語言代碼程序為例,該功能在ALIPAY.CS類中;以ASP代碼中的程序為例,該功能在alipayto/Alipay_Payto.asp文件中。
iii. 第三步——加密:
目前一般的加密方式是MD5,不論是哪種加密方式,要加密的信息是要傳給支付寶的信息,且存在于技術文檔中,而非自定義的變量名。對以上排序好的所有參數(不包括網關參數即:string gateway = "https://www.alipay.com/cooperate/gateway.do?" ;)以循環的方式,用‘&’字符拼接成一長串字符串(這里需要注意,所有的參數都是&字符來拼接的,拼接后直接再拼接安全校驗碼Key,在程序中大家可看到,這個key是直接加到該字符串后面而沒有用&字符 ),之后進行加密。得出的加密字符串集存儲于sign這個參數中。
iv. 第四步——拼接字符串成URL鏈接
我們已經拿到了各個參數、參數所屬的值以及加密得出的加密字符串,那么手上現在的所有參數信息的格式,應當都是一組一組的service=”trade_create_by_buyer”這種格式的字符串,拼接的話,則依靠循環的方式遍歷所有的這種字符串,因為這次的拼接是要成URL鏈接,所以之前排除在外的網關gaetway和加密類型參數sig
n_type也都會被拼接進來,那么,連接的字符則用大家所熟知的字符’&’,就這樣得出一個完整的URL鏈接地址,如:

https://www.alipay.com/cooperate/gateway.do?s...3d199ba&sign_type=MD5

該鏈接來自支付寶官方的技術文檔“標準實物雙接口技術文檔”
v. 第五步——自動跳轉
第四步中已經運算得出的URL鏈接字符串,我們則要讓其活起來,那么活起來的方式就是——用程序調用它,也就是所謂的頁面自動跳轉。這樣就能跳到支付寶的官方收銀臺頁面。
可以說,現在已經成功的把支付寶接口融合進了大家自己的網站中,且能夠使用支付寶來進行付款了。
b) 通知返回部分原理
i. 專業術語
通知返回是兩個頁面,即傳遞給支付寶時的notify_url參數所對應的頁面文件(asp.net的是Alipay_Notify.aspx、asp的是Alipay_Notify.asp)稱之為通知頁,傳遞
給支付寶時的return_url參數所對應的頁面文件(asp.net的是Alipay_Return.aspx、asp的是return_Alipay_Notify.asp)稱之為返回頁。
ii. 通知返回原理

  1. 第一步——驗證是否是支付寶服務器發來的請求:
    a) 以asp程序代碼為例:

alipayNotifyURL = "http://notify.alipay.com/trade/notify_query.do?"
alipayNotifyURL = alipayNotifyURL &"partner=" & partner & "&notify_id=" & request("notify_id")
Set Retrieval = Server.CreateObject("Msxml2.ServerXMLHTTP.3.0")
Retrieval.setOption 2, 13056
Retrieval.open "GET", alipayNotifyURL, False, "", ""
Retrieval.send()
ResponseTxt = Retrieval.ResponseText
Set Retrieval = Nothing

得到的便是ResponseTxt的值,這是下面的步驟要用到的。
b) 以asp.net C#程序代碼為例:

//獲取遠程服務器ATN結果,驗證是否是支付寶服務器發來的請求
public String Get_Http(String a_strUrl, int timeout)
{
string strResult;
try
{
HttpWebRequest myReq = (HttpWebRequest)HttpWebRequest.Create(a_strUrl);
myReq.Timeout = timeout;
HttpWebResponse HttpWResp = (HttpWebResponse)myReq.GetResponse();
Stream myStream = HttpWResp.GetResponseStream();
StreamReader sr = new StreamReader(myStream, Encoding.Default);
StringBuilder strBuilder = new StringBuilder();
while (-1 != sr.Peek())
{
strBuilder.Append(sr.ReadLine());
}

strResult = strBuilder.ToString();
}
catch (Exception exp)
{

strResult = "錯誤:" + exp.Message;
}

return strResult;
}

調用部分:

string alipayNotifyURL = "https://www.alipay.com/cooperate/gateway.do?service=notify_verify";
string partner = "2088************";

alipayNotifyURL = alipayNotifyURL + "&partner=" + partner + "&notify_id=" + Request.Form["notify_id"];

//獲取支付寶ATN返回結果,true是正確的訂單信息,false 是無效的
string responseTxt = Get_Http(alipayNotifyURL, 120000);

得到的便是ResponseTxt的值,這是下面的步驟要用到的。

  1. 第二步——排序:
    該部分的排序的原理與“接入部分”的原理“排序步驟”一樣,值得注意的是 ,這里的參數是支付寶通知返回時,傳回來的訂單信息的各種參數以及值。http://www.k686.com/
  2. 第三步——加密:
    該部分的加密原理與“接入部分”的原理“加密步驟”一樣,依然值得注意的部分是加密的參數信息,這些參數信息是來源于上面一步驟排序好后的參數拼接起來的字符串來加密的。
  3. 第四步——判斷:
    上面我們有得到加密的結果(命名為mysign吧)、檢驗是否是支付寶發來的消息的正確性ResponseTxt、以及通過POST或GET的方式得到的sign參數的值,那么這個判斷的含義便是通知返回里最重要
    的部分了,因為它是來檢驗下面的程序是否執行我們的數據處理的。如何判斷呢?各語言程序代碼中,都是把加密得出的結果mysign與從支付寶那或得到的sign的值進行比較,并且還要讓reponseTxt這個的
    值要等于true,這樣才達到驗證成功。值得注意的是 ,大家都有遇到過這種事,支付部分即接入部分的確是做好了,但為什么無法與支付寶的交易信息同步,出現的問題就在這個判斷上沒有成功,下面的第五部分則會詳細說明。
  4. 第五步——自身網站的數據處理
    終于判斷成功了,程序已經執行到了這里。各語言程序代碼的這塊地方的注釋都寫著“更新自己數據庫的訂單語句”或是“這里可以指定你需要顯示的內容”。如字面上的意思,這塊地方就是要我們大家來對這筆交易信息進行數
    據處理,即編寫程序。這個說法大概專業了點,簡單易懂的講法便是,支付寶的交易成功的信息和其他的一切交易狀態,自己的網站也能夠對這筆訂單同步起來,即支付寶里這筆訂單的交易狀態是“買家已付款等待賣家發貨”,
    那么自己網站里顯示的這筆狀態也因如此,那么就應當在這里面寫下諸如:

if (Request.Form["trade_status"] == "WAIT_SELLER_SEND_GOODS")// 判斷支付狀態_買家付款成功,等待賣家發貨(文檔中有枚舉表可以參考)
{
//更新自己數據庫的訂單語句,請自己填寫一下
string strOrderNO = Request.Form["out_trade_no"];//訂單號
string strPrice = Request.Form["price"];//金額
string sql = "update order_table set order_status = ‘買家已付款,等待賣家發貨’ where order_no = " + strOrderNO;
Update(sql);
}

等數據庫處理代碼。
iii. 存在的區別

  1. 大家仔細閱讀代碼不難發現,在通知頁中程序運行時,獲取參數的方法是用POST方式,而返回頁中程序運行時,獲取參數的方法是用GET方式。由此可知一些基本的信息——返回頁傳遞回來的參數信息是儲存在URL鏈接
    里的,而通知頁的參數信息是不在URL鏈接里,也能從中推斷出二者在功能上的差異。
  2. 大家可看到通知頁面比返回頁中多一個環節,那就是Response.Write("success");
    作用上不同的詳細說明,大家可以看下面的第四部分。http://www.k686.com/

三、 參數
首先大家有個疑問,技術文檔中的輸入參數列表中給出了諸多參數,而手上拿到的代碼里只寫了一部分參數來進行傳遞信息,這究竟是為什么?那么我們先帶著這個疑問往下看。
以下討論的參數不涵蓋網關gateway、加密參數sign、加密類型sign_type,因為這些都是必須的。
以實物標準雙接口為例,可把參數看做幾個功能部分組成
a) 不可缺少的參數
i. service服務參數,這個是用來區別這個接口是用的什么接口,所以絕對不能修改。
ii. partner合作身份者ID、key安全校驗碼或稱私鑰這一組參數是簽約合同生效后才能拿的到,partner是來鑒別是哪個商家與支付寶簽約,而這個Key它如同鑰匙般相當重要。
iii. seller_email收款人支付寶賬號,支付寶中有手機類型、電子郵件類型的支付寶賬號是都可以用這個參數的。
iv. subject在支付寶的收銀臺里是直接與商品名稱關聯在一起的,但是說的更準確些的話,這個參數是這筆交易的名稱,因為這筆交易不一定只買一件商品。它的作用不僅是在收銀臺里可以清晰的顯示出來,而且在支付寶的賬
戶的交易明細的列表里,它也是排在第一列,由此可推測出,它有財務對賬、作為交易查詢的篩選條件等諸多作用。非常重要。
v. out_trade_no技術文檔中給出的是商戶交易號(確保在商戶系統中唯一),顧名思義這個就是我們大家自己網站的訂單系統里的唯一訂單號,而非支付寶的。這里需要強調的,這個訂單號必須得是唯一的,如何唯一法?自己網站
里訂單系統的訂單號是絕對唯一的吧,支付寶要求的唯一就是這個,為什么非要唯一?支付寶會根據訂單號來判定這筆訂單對于這個商家的所有交易中是否是唯一的。
vi. price金額、quantity數量,這里設置有兩種方式一種商品的單價金額,多個數量(即大于等于1)。另種是數量為1,金額代表總額,甚至是包含了運費。為什么大部分的客戶要這么做?原因很簡單,第一,購物車里的東西不一定是單純的
一件或者多件相同的商品,那么為商品設置金額時就有困難了,因此這里用總額是最好的,而數量就默認為1。第二,運費的設置很多客戶是與各家快遞公司簽約、每件物品的快遞費用也不盡相同,為了省去麻煩,在程序計算的
時候干脆把運費也加進去。因此我們只需要記住一件事,這個price的金額就是所謂的總額了。
vii. payment_type支付類型,沒什么可說的直接寫成1,無需改動。
viii. 物流信息logistics_type、logistics_fee、logistics_payment這是一組物流信息,實物標準雙接口中必須得至少有一組物流信息,也就是指這三個參數了,最多可有三組,哪三組呢?logistics_type_1、logistics_fee_1、logistics_paymen
t_1(第二組);logistics_type_2、logistics_fee_2、logistics_payment_2(第三組)。后兩組為可選項。一般前面有說Price已經是總額了且包含了運費,那
么這里物流運費就直接設置成0即可,即logistics_fee=”0”,其他兩個的信息可參考技術文檔來填寫,因為要從技術文檔中的枚舉列表里來選擇,所以絕不可亂填寫。
b) 可增加的有用參數
i. 物流信息最多三組,最少一組,這已經在前部分有所提及,這里就不再細說。
ii. _input_charset,當是UTF-8的編碼格式時必須得用到且不允許為空的,即_input_charset=”utf-8”
iii. notify_url、return_url,return_url代表支付完畢后可以自動從支付寶的官方頁面跳轉回來,notify_url這個是防止調單的首選最佳工具。
iv. body,在支付寶收銀臺中的商品描述里顯示,如果subject是訂單名稱的話,那么這個body則最準確的稱之為訂單描述,其實個人認為它作為備注之類的更為恰當。很多人都很郁悶支付寶為何不能像其他公司
的接口有個自定義的參數來存放客戶想要的東西,其實body也具有類似的這種功能,它不僅容納的信息是所有參數里最大的,而且還是以字符串的形式儲存,個人認為它其實也是非常重要的不可缺少的參數之一呢。
v. discount折扣,顧名思義如果小于0,則是用原金額Price*quantity+(discount),實際金額便比原總額小了。現在有些商戶有支付寶的優惠卷,而優惠卷的用途也是在這個參數中體現,具體做法與前
面無異。
vi. show_url商品展示地址,這個鏈接的作用是在支付寶收銀臺的商品鏈接旁邊有個下劃線“詳情”的鏈接,而點鏈接彈出的一個新頁面便是這個商品展示地址的頁面。
vii. 收貨信息receive_name、receive_address、receive_zip、receive_phone、receive_mobile,這些信息若也設置為傳遞給支付寶的參數之一的話,那么在支付寶收銀臺點選下一步的時候,本該出現的填寫收貨信息頁面不見蹤影,而直接跳到了收貨信息頁面的下一個頁面去了。很多商戶在自己的網站的購物
流程中都有一個填寫收貨信息的選項卡,為了省去到支付寶收銀臺中還要填寫一次收貨信息的麻煩,那么這些收貨信息的參數就派上用場了。值得注意的是,收貨人姓名和地址是必填項,不然還是會出現收貨信息填寫頁。
viii. buyer_email買家支付寶賬號,這個設置好后呈現的效果便是,原本是空的支付寶賬號的輸入框此時已經有個支付寶賬號在里面放置。
c) 剩下的參數無需理會

整個實物標準雙接口的參數介紹完畢,那么其他接口的參數還要介紹嗎?大家從上面分析得出的東西對比技術文檔的參數列表是否看出什么來了?

1、 參數列表的最后一列叫“可空”,N代表不允許為空,Y代表允許為空,結合上面的不可缺少參數與增加的有用參數來進行比較,不難發現,不可缺少的參數全是為N的。
2、 有些為Y的參數有一組,例如buyer_email、buyer_id,凡是遇到這種的一般都是二可選一也可都不選,或是二必選一。舉例說明:二必選一的是seller_email、seller_id,二選一的
是buyer_email、buyer_id。
所有的接口的參數如此分析就能判斷出哪些是重要參數哪些可不要,結合技術文檔與程序接口來研究就能一目了然。


四、 通知返回
a) 返回頁
傳遞給支付寶時的return_url參數所對應的頁面文件。
具備的屬性:
1、支付接口中買家的購買流程已經走到支付寶里且支付寶提示支付成功時,頁面會自動跳轉回自身網站的這個頁面里來。
2、同步的,無時差
3、獲得參數的方法是用get方式獲取。
4、不論跳轉回來程序判斷是真還是假(if(sign = mysign and responseTxt = true))只跳轉回來一次,不重復。
5、這個并不是支付寶服務器調用了該頁面,而是通過與組合拼接各參數形成的URL鏈接原理等同,拼接出來的URL鏈接,之后程序上做自動跳轉。
6、基于5的原因,該頁面的程序調試可不必在服務器上而是本機上調試、運行。
b) 通知頁
傳遞給支付寶時的notify_url參數所對應的頁面文件
具備的屬性:
1、這個通知頁就是被支付寶調用才能啟動的。
2、服務器間的互動,不像返回頁肉眼可以看到,這個是看不到的。
3、獲得參數的方法是用POST方式獲取。
4、支付寶中的該筆交易存在,且該筆交易狀態發生了變更,就會被調用。
5、被調用程序判斷(if(sign = mysign and responseTxt = true)),若我們自己在該判斷中有做程序編寫,成功則不再被調用,不成功則會反復被調用。
6、異步的,第一次收到訂單信息(以下都稱之為“通知”)是與返回頁近乎等同或等同的同步時間,在判斷不成功的情況下,會收到第二次第三次等次數的通知,時間間隔從最先的一兩分鐘,到后面的幾個小時。失效時間是4
8小時。
7、基于6的原因,該頁面的程序調試必須在服務器上調試、運行。
8、程序編寫時必須采用程序執行成功,才寫頁面response.Write(“success”);,不成功則寫頁面response.Write(“fail”); 支付寶根據success來判定是否要重新再次發送通知。
9、該頁面的Html頁面中必須是空白、無任何Html標簽、無任何空格、不允許做頁面跳轉。

以C# ASP.NET實物標準雙接口代碼為例:

if (mysign == sign && responseTxt == "true")
{
if (Request.Form["trade_status"] == "WAIT_BUYER_PAY")// 判斷支付狀態等待買家付款(文檔中有枚舉表可以參考)
{
//更新自己數據庫的訂單語句,請自己填寫一下
}
else if (Request.Form["trade_status"] == "WAIT_SELLER_SEND_GOODS")// 判斷支付狀態
買家付款成功,等待賣家發貨(文檔中有枚舉表可以參考)
{
//更新自己數據庫的訂單語句,請自己填寫一下
string strOrderNO = Request.Form["out_trade_no"];//訂單號
string strPrice = Request.Form["price"];//金額
string sql = "update order_table set order_status = '買家已付款,等待賣家發貨' where order_no = @out_trade_no";
Update(sql,para);
}
else if (Request.Form["trade_status"] == "WAIT_BUYER_CONFIRM_GOODS")// 判斷支付狀態賣家已發貨等待買家確認(文檔中有枚舉表可以參考)
{
//更新自己數據庫的訂單語句,請自己填寫一下
string strOrderNO = Request.Form["out_trade_no"];//訂單號
string strPrice = Request.Form["price"];//金額
string sql = "update order_table set order_status = '賣家已發貨,等待買家確認收貨' where order_no = @out_trade_no";
Update(sql, para);
}
else if (Request.Form["trade_status"] == "TRADE_FINISHED")// 判斷支付狀態
交易成功結束(文檔中有枚舉表可以參考)
{
//更新自己數據庫的訂單語句,請自己填寫一下
string strOrderNO = Request.Form["out_trade_no"];//訂單號
string strPrice = Request.Form["price"];//金額
string sql = "update order_table set order_status = '交易成功' where order_no = @out_trade_no";
Update(sql, para);
}
else
{
//更新自己數據庫的訂單語句,請自己填寫一下
}

Response.Write("success");
}
else
{
Response.Write("fail");
}

c) 在支付寶的眾多接口中,不是所有的接口都擁有通知頁與返回頁的。
有的接口只有返回頁;有的接口有通知頁且用XML格式的內容顯示在當前頁面中;有的沒有通知頁也沒有返回頁僅僅只以XML格式的內容顯示在當前頁面中。所以,我們要根據各接口的技術文檔與程序實例來做相應的數據處
理。
d) 大家這里存在一個疑問,一般大家的做法都是把數據庫更新些在返回頁中,但是很多情況下出現了訂單不同步即掉單現象。這是為什么?
答:返回頁是當前頁面自動跳轉的,這雖然跳轉的反應速度不錯,但人的手動關閉該頁面操作絕對可以使之在沒有跳轉回來之前就關掉了該頁面,此時原本該數據庫更新的程序并沒有被啟動,這樣直接導致了掉單,所以一般大商
戶,尤其是網絡游戲行業的即時到帳充值的技術做法是:返回頁中有訂單處理程序,通知頁中也有,當返回頁中的訂單沒做過處理時,通知頁中的數據處理程序便啟動;這樣即可近乎100%解決掉單問題(還有種掉單原因是大家自己的服務器出現問題,比如MS3XML.DLL問題,這個問題至今沒有什么可以解決的辦法,只能重裝或是更換服務器,也有的服務器因為中毒才導致的)。本文來源于 http://www.k686.com/


五、 調試
接入部分做好了,通知返回部分也做好了,那么開始調試吧。
調試也分成兩大部分來做。
a) 部分網站用了框架模式frame,但這個并不適用支付寶的接口程序,因此絕對不能把支付寶的接口頁面置于整個網站的框架之下。
b) 確定好要用POST還是GET方式來傳遞參數,二者不能混用。由于有些網站中不一定只有一個接口入口,所以整個網站都必須保持一致性,不能這個接口用POST,那個接口用GET,這樣直接導致后續出現一系列連查找
原因都極其困難的現象。
c) 接入部分的調試工作,則是輸入支付寶要求的格式的值,如subject、body的值不允許有非法字符、金額格式必須是小數點后兩位數或是正整數且不是金額格式(即$123.00),以及非常重要的一個原則,傳遞的參數要么不傳遞這個參數(即傳遞的眾多參數中,這個參數完全不存在),要么這個參數不允許為空。很多人在調試時支付出現一系列“調試錯誤”有很大的一部分原因就是參
數的設置存在問題。
d) 編碼格式一定要確認再確認,在支付時直接出現“調試錯誤,SIGN不對”只有兩種原因,一是C部分已提到的參數的設置問題,另一個便是這個編碼格式的問題。編碼格式是非常重要的,絕對不能這個地方用GBK,另個地方用utf-8。
e) 通過接口走一次真實的操作,若是支付接口,則走一筆真實的交易,金額則是0.01元(支付寶是沒有測試環境的,所以請老實的使用自己簽約的號去走真實交易),不要覺得很麻煩,也不要把這個工作交個經理或者你的老板
來做,因為它直接關系到你后續的操作步驟與調試的順暢程度。
f) 返回部分在本機電腦上就可以調試完畢,之前有提到不要把支付測試工作交給自己以外的其他人,這里就可以得到充分的說明,不論是哪種語言都擁有自己風格的單步監控程序代碼的能力,返回部分就要一步一步監控程序的執行,確保1、是否執行到了“mysign == sign && responseTxt == "true"”,這個IF語句的判斷;2、是否進入了這個語句里而不是else里;3、數據庫更新程序是否執行成功,而不是卡著不動了;4、數據庫更新完畢后,程序是否走完。基本出現問題的地方就在第一步,所以不要
覺得奇怪為什么掉單?
g) 通知頁的調試,這個調試就比較麻煩了,首先這個支付寶接口已經完成且放在了服務器上,別人可以通過互聯網來進行支付;其次,要把通知頁中的“寫日志”程序啟動起來,日志內容主要記錄trade_status、tr
ade_no、out_trade_no、price、sign、mysign、responseTxt等。一般出現的原因依舊是“mysign == sign && responseTxt == "true"”這個判斷上不被通過。
具體檢測方式:
1、直接用互聯網訪問http://www.xxx.com/alipay/notify_url.asp
訪問是否能夠訪問得到,且顯示"fail"的字眼,其他如空白或是其他程序錯誤提示等內容,均屬程序執行出錯。
2、程序是否執行到,sign=mysgin and responseTxt = "true"這個判斷中,如果執行到這個判斷時跳到ELSE的判斷語句去了,則表示您的接口程序在支付時傳遞的參數信息或是您的編碼格式、合作身份者ID與安全校驗碼的設置存在問題。
3、程序已經執行到sign=mysgin and responseTxt = "true"這個判斷中,卻沒有執行到response.Write("success")這句話,說明您自己編寫進去的程序代碼執行出錯,請檢查。


六、 其他
a) 有些接口,例如支付的接口,是支持POST或者GET方式傳遞參數的。
i. POST傳遞方式:
這里需要注意的地方是:<form action=” aliay_url” …>中action的值是網關+編碼格式參數,即https://www.alipay.com/cooperate/gateway.do? _input_charset=utf-8,GBK的編碼格式可以為:https://www.alipay.com/cooperate/gateway.do?。
ii. GET傳遞方式:
是用&字符來連接起來的一長串URL鏈接字符串,通過自動跳轉不是<form action=” aliay_url” …>的方式來存放,而是用Response.Redirect(aliay_url)方式來進行跳轉。

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 227,533評論 6 531
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,055評論 3 414
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 175,365評論 0 373
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,561評論 1 307
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,346評論 6 404
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 54,889評論 1 321
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 42,978評論 3 439
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,118評論 0 286
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,637評論 1 333
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,558評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,739評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,246評論 5 355
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 43,980評論 3 346
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,362評論 0 25
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,619評論 1 280
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,347評論 3 390
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,702評論 2 370

推薦閱讀更多精彩內容