微信支付模块化小小的回顾总结

微信支付模块化小小的回顾总结

最近的一个项目涉及到微信支付模块。因为之前从来没有接触过付费的内容，特意花了一些时间研究，终于拿到了付费；但仅仅能够支付是不够的。我需要使用修改用户支付的订单的支付状态，在用户下次浏览时判断：用户是否已经支付了该资源，如果已经支付，则直接放行；如果还没有付款，则需要在收银台处拉 Pay Pay。

虽然本文的标题主要是回调接口的内容，但是还是想对支付问题做一个小小的回顾和总结。

一开始遇到的问题是：当用户点击资源时，系统进行预购，然后调用支付接口获取一系列参数，但是可能会出现用户刚点击资源的情况，系统已经完成了预购，但是用户不想看，所以又退出了。过了一会儿，用户回来了。这个时候系统会重新下单，但是一开始没有考虑到这种情况，所以当用户第二次下单的时候，有时候会下单失败。最终的解决方案是：在用户请求下单之前，检查是否有之前下过的订单。如果存在，只需要修改预订时间，然后返回前端订单信息即可；

完成重复下单的问题后，出现了新的问题：当收银机被拉起时ios支付宝支付成功后回调，用户不想再支付了，所以用户选择了关闭收银机，但用户并没有退出资源界面. 是的ios支付宝支付成功后回调，用户再次点击支付，后台报错：订单已支付，请勿重复操作。什么？我还没付款……到底出了什么问题？通过DEBUG，我定位到自定义“order number”的问题，因为我这里使用的数字是视频的序列号，这个数字是固定的。当视频还没有购买时，第一次购买的人可以支付成功。这时候自定义序列号就会变成订单的订单号，并且会保存在微信后台，这样当第二人购买的时候，当我们封装一系列参数，发送到微信服务器上传的时候，就会出现“订单已经存在”的现象。微信服务器返回给我的数据标识中：return_code: SUCCESS, result_code: FAIL，在一成功一失败的情况下，是肯定不可能拉起收银台付款的。最终解决方案：使用当前年月日和一些标识生成每个唯一的订单号，解决了这个问题；微信服务器返回给我的数据标识中：return_code: SUCCESS, result_code: FAIL，在一成功一失败的情况下，是肯定不可能拉起收银台付款的。最终解决方案：使用当前年月日和一些标识生成每个唯一的订单号，解决了这个问题；微信服务器返回给我的数据标识中：return_code: SUCCESS, result_code: FAIL，在一成功一失败的情况下，是肯定不可能拉起收银台付款的。最终解决方案：使用当前年月日和一些标识生成每个唯一的订单号，解决了这个问题；

解决了无法支付的问题，接着是支付成功，微信好像没有调用逻辑业务的回调接口。这样，用户支付成功后，系统不存储用户支付成功的结果，用户下次观看时继续收费；

通过百度各路大神的建议，前后做了以下尝试：

1、关闭并开启Linux防火墙；