- 必须保证服务器异步通知页面（notify_url）上无任何字符，如空格、HTML 标签、开发系统自带抛出的异常提示信息等。
- 支付宝是用 POST 方式发送通知信息，因此该页面中获取参数的方式，如：request.Form(“out_trade_no”)、$_POST[‘out_trade_no’]。
- 支付宝主动发起通知，该方式才会被启用。
- 只有在支付宝的交易管理中存在该笔交易，且发生了交易状态的改变，支付宝才会通过该方式发起服务器通知（即时到账交易状态为“等待买家付款”的状态默认是不会发送通知的）。
- 服务器间的交互，不像页面跳转同步通知可以在页面上显示出来，这种交互方式是不可见的。
- 第一次交易状态改变（即时到账中此时交易状态是交易完成）时，不仅会返回同步处理结果，而且服务器异步通知页面也会收到支付宝发来的处理结果通知。
- 程序执行完后必须打印输出“success”（不包含引号）。如果商户反馈给支付宝的字符不是 success 这7个字符，支付宝服务器会不断重发通知，直到超过 24 小时 22 分钟。一般情况下，25 小时以内完成 8 次通知（通知的间隔频率一般是：4m,10m,10m,1h,2h,6h,15h）。
- 程序执行完成后，该页面不能执行页面跳转。如果执行页面跳转，支付宝会收不到 success 字符，会被支付宝服务器判定为该页面程序运行出现异常，而重发处理结果通知。
- cookies、session 等在此页面会失效，即无法获取这些数据。
- 该方式的调试与运行必须在服务器上，即互联网上能访问。
- 该方式的作用主要防止订单丢失，即页面跳转同步通知没有处理订单更新，它则去处理。
- 当商户收到服务器异步通知并打印出 success 时，服务器异步通知参数 notify_id 才会失效。也就是说在支付宝发送同一条异步通知时（包含商户并未成功打印出 success 导致支付宝重发数次通知），服务器异步通知参数 notify_id 是不变的。
