专业IM即时通讯软件开发,值得信赖!

支付宝支付和微信支付异步回调多次调用

未分类 云聊IM 65℃

最近公司在开发微信支付和支付宝支付,前期的工作都已经做好了,但是在异步回调取值的时候,异步回调一直在调用,弄得我数据一直重复的存入数据库,真觉得大姨妈来了,根本停不下来!哈哈,还是不要开车了,看到问题,仔细思考下,脑海中立马浮现的一个解决方法就是,在异步回调,里面再写一个接口,每次回调取到数据后,查询数据库,看看有没有数据,如果有就不重复存入,但是仔细一想,不对啊,这是治标不治本啊,不行,既然有问题,肯定有根源,有正确的解决方法。所以,找起根据,那就是查看文档:

1,支付宝文档,下面这是支付宝异步回调的文档:点击打开链接

服务器异步通知页面特性

必须保证服务器异步通知页面(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是不变的。

看到没,程序必须要打印出来success后,支付宝才会停止喷血,自己再回头看程序的时候,发现自己的确没有返回success,所以在程序结束后,返回一个success即可。由于我使用的php,在程序结束后。使用下面一句话即可。

echo "success";

2,微信文档 点击打开链接

支付完成后,微信会把相关支付结果和用户信息发送给商户,商户需要接收处理,并返回应答。

对后台通知交互时,如果微信收到商户的应答不是成功或超时,微信认为通知失败,微信会通过一定的策略定期重新发起通知,尽可能提高通知的成功率,但微信不保证通知
最终能成功。 (通知频率为15/15/30/180/1800/1800/1800/1800/3600,单位:秒)

注意:同样的通知可能会多次发送给商户系统。商户系统必须能够正确处理重复的通知。
推荐的做法是,当收到通知进行处理时,首先检查对应业务数据的状态,判断该通知是否已经处理过,如果没有处理过再进行处理,如果处理过直接返回结果成功。
在对业务数据进行状态检查和处理之前,要采用数据锁进行并发控制,以避免函数重入造成的数据混乱。

特别提醒:商户系统对于支付结果通知的内容一定要做签名验证,并校验返回的订单金额是否与商户侧的订单金额一致,防止数据泄漏导致出现“假通知”,造成资金损失。
技术人员可登进微信商户后台扫描加入接口报警群。

看到没,在此文档也是,在微信的异步通知后,也需要给微信服务器,返回一个信息,只不过,微信的所有数据格式都是xml的。所以我们在返回一个数据给微信即可。

echo "";

在进行返回的时候,格式没问题,可能在输出的时候,存在问题。使用下面方式即可:

echo exit('');

哈哈,就是这么简单,立马把微信和支付宝的血止住了,完美结局!

喜欢 (0)
仿微信聊天软件开发
点击这里给我发消息