这个多次出现支付的情况 应该消除不了的。 你要逻辑控制订单只可足额支付一次吧。
怎么做处理,求指教
订单处理流程要做状态迁移.
状态1:待支付.
状态2:已支付待发货
支付时将订单从状态1迁移到状态2
迁移时肯定要判断原来的状态.
这个是有做的,但是我上面描述的那个情景,支付宝那边还是会支付两次
@小好人lucky: 支付宝那边不会给一个订单号支付两次的.肯定是你生成了2个支付.
@吴瑞祥: 我这边是用流水号去调用支付接口的,重新调用的话就会生成新的流水号,所以还是能支付
@小好人lucky: 生成流水号的时候判断了是否支付成功?
@吴瑞祥: 不是判断是否支付成功,支付宝那边我们每一次发起支付的时候不是都会生成一个唯一订单号out_trade_no吗?在回调还没返回的时候,如果用户点击第二次支付的时候就会重新生成一个订单号,所以用户又能支付了.
@小好人lucky: 还不是我上面问的问题...生成一个唯一订单号out_trade_no 不判断是否已经生成过订单了.或者上一个out_trade_no 是否已支付.
每一次提交/支付操作都应该伴随一个唯一的ID的,当在提交/支付过程被中断后,在客户不确认正常还是异常的情况下,二次提交应该以相同ID来提交/支付。然后根据ID确认上次提交是否正常,来避免重复支付/提交的问题。
我这边是用流水号去调用支付接口的,重新调用的话就会生成新的流水号,所以还是能支付
问题出在这个设计上,设计有问题,坑死程序员啊。
这个和技术设计没太大关系(但使用相同商户订单号提交这个是必要的),支付时只要最终没有得到支付成功的结果就有可能导致重复支付,使用相同商户订单号提交只能是减缓这种问题发生的可能性,但不能杜绝。这种比较好的方式是通过前端和业务的限制延迟用户第二次支付的时间。
使用事务吧,再调用支付接口之前,给你的方法加上事务,这样如果半路失败,会回滚,就调用不到支付接口了。
可能是我情景描述的不太对,我现在是用户支付调用支付请求后,支付宝已经在执行付款的过程中了,我们服务端还没接收到支付宝返回的成功信息,所以没跳转到支付成功页面,这时用户返回到立即支付页面,再次点击了立即支付,我们这时的订单的支付宝订单号会重新生成,用户又可以重新支付,导致了用户出现支付两次的情况.
@小好人lucky: 我大概懂了你这个流程了,你们调用支付宝接口,然后支付宝没有返回支付成功消息(但是实际已经生成订单号),你们没有接收到支付宝返回支付成功的消息参数,所以又跳回了立即支付页面,这样用户再点立即支付,就会再执行一遍程序,再走一遍刚才的流程,也就是会第二次调用支付宝接口,这样肯定会第二次支付。所以,问题在你第一次,就是用户在支付过程中,突然出现通讯中断什么问题时,就中断这个支付流程(即在调用支付宝接口之前就中断),这样就不会生成一个订单号。重新支付时,如果成功,就只有一个订单号生成,就只支付一次,如果第二次支付失败,还是会中断支付流程,不会生成订单号。所以,问题的关键在你设计的这个流程,怎么使用户在支付时突然出现问题而中断支付过程,不使他调用支付宝接口,或者说是回复到最初状态。希望这个思路对你设计和解决这个问题有帮助。
你们和支付宝应该有协议,在支付的时候,吧你们的唯一标示传过去,例如,订单号。支付宝也会判断你们这边的唯一标示,如果重复支付,支付宝也会提示失败的。你应该在好好看看支付宝给你们提供的技术文档,应该有说明。
我们这边是有唯一标示是订单号,上面我已经有描述了,用户返回再点击立即支付会重新生成支付宝订单号
@小好人lucky: 当时记得如果支付宝那边没有支付,或者支付没有成功,会生成新的流水号;如果支付宝那边支付成功了,无论你这边有没有得到支付成功的通知,支付宝都会提示重复支付。
做这个时间有点长了,有点忘了。找一下支付宝的及时对接人,交流一下吧。