我在做一个网站，用的是支付宝的即时到账。我想问的是，在用户通过支付宝支付之后，我们需要等2分钟，然后才能收到支付宝服务器发的通知，从而才知道用户是否成功交易。
为了更好的用户体验，我感觉是在完成支付宝的支付界面之后，我们get request from 支付宝的服务器，如果得到的返回paramenter 里面显示交易“完成”（一般来说不会是“成功”），然后我们给用户在我们网站上的账户充值。
问题： 如果交易完成了，但是不是像预想中的那样（比如应缴金额不对等）。我们过早得给用户账户充值，用户很可能用充值已经消费了，在我们发现交易不对头的时候。
我很想知道业界是怎么对待这个问题的。
谢谢~
PS: 中文不好，还请见谅！
2分钟？ 支付宝会进行异步通知和实时通知，实时通知是在支付后直接跳转到你的网站，并携带充值成功标记；异步则是当用户支付过程中放弃或者实时通知失败，异步可以避免出错。
唔，我觉得你需要更新下接口了。
支付宝异步回调结果是近似乎同步的操作，一般不存在你表述的两分钟以后才能收到请求的问题。
或者，可以酱紫，充值结果页面跳转后，直接显示“金额正在确认中，稍后将到账”不觉得有什么不妥。
或者主动调用支付宝订单查询接口。
支付宝不是提供了两种反馈方式了吗？
1. return_url 支付完成后的页面回跳地址
2. notify_url 后台异步通知地址
说明：
1. 在支付宝完成支付后，正常流程浏览器会跳转到 return_url指定的地址，传给你的参数跟notify_url中收到的是一样的，你只要检查一下，确认支付成功后就可以 “操作入账了”，然后跳转到你们网站支付成功的页面。
2. 同时，支付完成后支付宝服务器会不断（频率按算法递减）往notify_url的地址发送支付结果信息。 你收到请求后 判断状态 “操作入账” 就行。
两种方式是同时进行的，1 可能会被用户打断（比如支付后被用户关闭窗口，那就不会跳转回来）
很多时候1和2几乎并发， 最好是在return_url和notify_url中处理相同订单的反馈的时候，上锁处理，要不然1还没处理完，2中又处理一遍，有可能会造成“重复入账”。
两分钟？你确定你的是即时到帐接口？