关于支付宝接口整合的几个问题

假设顺利的话非常快就能够弄好，总之依照文档要求来。

 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（页面跳转同步通知页面路径）时，商户必须推断商户站点中是否已
经对该次的通知结果数据做过相同处理。假设不推断，存在潜在的风险，商户自行
承担因此而产生的全部损失。