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

假设顺利的话很是快就可以弄好，总之依照文档要求来。

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