關於支付寶接口整合的幾個問題

假設順利的話很是快就可以弄好，總之依照文檔要求來。

 1.  jsp頁面可以改爲action嗎？

答案是可以。原來的頁面基本不用改，直接複製到action中，開頭加上一句
HttpServletRequest request = ServletActionContext.getRequest();

最後的 out.println("success"); 換成例如如下：

HttpServletResponse response = ServletActionContext.getResponse();
  response.setCharacterEncoding("UTF-8");
  response.setContentType("text/html;charset=utf-8");
  response.setHeader("pragma", "no-cache");
  response.setHeader("cache-control", "no-cache");
try {
    response.getWriter().write("success");
} catch (IOException e) {
    e.printStackTrace();
 }

其它的不用變，僅僅是要依據返回的狀態寫業務邏輯。

2. ILLEGAL_SIGN 錯誤碼。
形成這個錯誤的緣由比較多，當中兩點是：

（1）傳遞了值爲空的參數， 假設要爲空的參數，那麼該參數就不能傳遞給支付寶，即請求的URL連接裏不能存在該參數的提交，
也就是說要傳遞的參數，必須保證有值。

（2）安全校驗碼（Key）寫錯了，我就是這個緣由，當時上級給我資料時說隨便用個12345在後面再改過來，結果忘了。

 3. 本地測試(不用放到server上，僅僅要電腦能上網便可)：

可以測試整個流程包含下訂單到支付成功以及得到支付寶返回的數據以及

本身業務邏輯的處理（相應return_url.jsp的內容）。notify_url.jsp相應的要在server上才幹夠測試。

return_url地址寫成： http://192.168.1.xxx:8080/xxx/alipay_returnUrl.action;  ip爲本機的ip地址。

 4.同步通知和異步通知

同步通知和異步通知的前後順序不肯定，因此必須對該次結果是否作過處理加個推斷。

文檔中有這樣一句話：

當商戶有傳遞參數notify_url（server異步通知頁面路徑）
或return_url（頁面跳轉同步通知頁面路徑）時，商戶必須推斷商戶站點中是否已 經對該次的通知結果數據作過相同處理。假設不推斷，存在潛在的風險，商戶自行 承擔所以而產生的所有損失。