支付宝开发中return_url和notify_url的区别分析
在处理支付宝业务中出现过这样的问题,付费完成后,在支付宝跳转到商家指定页面时,订单状态已经更新,通过调试发现是支付宝先通知notify_url,完成了订单状态.
支付宝return_url和notify_url通知顺序问题:
顺序不一定的,请别以先后顺序来做判断,具体如何判断,是根据您当前数据库里的状态和刚从支付宝里获取到的状态做对比来判断是否有做过处理了.
关于支付宝return_url和notify_url的区别,同步通知页面特性(return_url特性):
(1) 买家在支付成功后会看到一个支付宝提示交易成功的页面，该页面会停留几秒，然后会自动跳转回商户指定的同步通知页面（参数return_url）；
(2) 该页面中获得参数的方式，需要使用GET方式获取，如request.QueryString("out_trade_no")、$_GET['out_trade_no']；
(3) 该方式仅仅在买家付款完成以后进行自动跳转，因此只会进行一次；
(4) 该方式不是支付宝主动去调用商户页面，而是支付宝的程序利用页面自动跳转的函数，使用户的当前页面自动跳转；
(5) 基于(4)的原因，可在本机而不是只能在服务器上进行调试；
(6) 返回URL只有一分钟的有效期，超过一分钟该链接地址会失效，验证则会失败；
(7) 设置页面跳转同步通知页面（return_url）的路径时，不要在页面文件的后面再加上自定义参数。例如：
错误的写法：
正确的写法：
服务器异步通知页面特性(notify_url特性)：
(1) 必须保证服务器异步通知页面（notify_url）上无任何字符，如空格、HTML标签、开发系统自带抛出的异常提示信息等；
(2) 支付宝是用POST方式发送通知信息，因此该页面中获取参数的方式，如：
request.Form("out_trade_no")、$_POST['out_trade_no']。
(3) 支付宝主动发起通知，该方式才会被启用；
(4) 只有在支付宝的交易管理中存在该笔交易，且发生了交易状态的改变，支付宝才会通过该方式发起服务器通知（即时到账中交易状态为“等待买家付款”的状态默认是不会发送通知的）；
(5) 服务器间的交互，不像页面跳转同步通知可以在页面上显示出来，这种交互方式是不可见的；
(6) 第一次交易状态改变（即时到账中此时交易状态是交易完成）时，不仅页面跳转同步通知页面会启用，而且服务器异步通知页面也会收到支付宝发来的处理结果通知；
(7) 程序执行完后必须打印输出“success”（不包含引号）。如果商户反馈给支付宝的字符不是success这7个字符，支付宝服务器会不断重发通知，直到超过24小时22分钟。
一般情况下，25小时以内完成8次通知（通知的间隔频率一般是：2m,10m,10m,1h,2h,6h,15h）；
(8) 程序执行完成后，该页面不能执行页面跳转。如果执行页面跳转，支付宝会收不到success字符，会被支付宝服务器判定为该页面程序运行出现异常，而重发处理结果通知；
(9) cookies、session等在此页面会失效，即无法获取这些数据；
(10) 该方式的调试与运行必须在服务器上，即互联网上能访问；
(11) 该方式的作用主要防止订单丢失，即页面跳转同步通知没有处理订单更新，它则去处理；
(12) 通知ID（参数notify_id）只有一分钟有效期，超过一分钟该次通知会验证失败。一旦验证成功下次再验证就会失效。
