1，问：假设有这么一种情况：
订单已下单成功并且正处于支付页面，用户调起支付网关进行支付。支付成功了一次，但是由于某种情况导致未接收到银行返回的【支付成功】等信号，系统此时还是认为未支付成功。用户此时又支付了一次并且成功了。
问题：
如果用户出现了2次支付并且都成功了，后台逻辑退款这一块如何设计？
是否可以避免这种情况的发生？如果可以怎么去避免呢。
2，以下由网友回答，仅作参考：
参考1）
A.后台设计逻辑：
1.参与的主体：
电商系统
网银或者第三方支付平台
电商用的结算平台(例如商户支付宝，商户翼支付等)
2.设计的主要流程：
电商系统调起网关支付，订单跳转到网银或者第三方支付平台中进行实际支付，这时订单中包含的信息是由电商用的结算平台先生成的一个支付订单信息(这个支付信息包含与电商系统与网银或者第三方支付平台的关联)；用户在网银或者第三方支付平台中进行实际支付(这个支付交互是网银或者第三方支付平台与结算平台的交互)，成功之后才是结算平台反馈支付信息给电商系统。
下列图中
1是用户调起网关支付，订单跳转到网银或者第三方支付平台中进行实际支付。
2是用户支付成功后，订单反馈至电商系统。
image.png
现在出现重复付款的问题就是出现在中的网银或者第三方支付平台到电商用的结算平台出现了延迟的情况，导致在电商系统中的订单一直处于未付款状态，部分用户以为未支付就最终产生了重复付款。
B.如何避免
针对这个问题，思考了各种场景以及情况，这种模式是无法避免重复付款的（必须得看结算平台的处理效率-一般情况下还是比较好的，还是少有延迟的情况）。只能后台检测重复付款的订单，异常走退款流程。
除非系统本身具有支付平台的功能。
C.延伸问题，如何处理因为支付成功后因延迟回调而订单被取消
这个问题的出现背景也是因为第三方结算平台延迟反馈而造成用户错以为没有支付而取消订单或者是系统到时时自动取消订单
解决办法：
建立异常处理机制，机制如下：
结算平台延迟返回成功的支付信息给电商系统时，如果判断出此订单已经取消。则进入异常处理机制，更改订单为已收款状态，并再次扣减订单中库存以及各种优惠（例如：价保，返利，促销费，优惠等等）的回退。当然再此扣减的时候需要先判断相关产品的库存以及用户的各种优惠是否满足订单的扣减，不满足则不允许转化。
这里是应该先判断再次扣减的库存以及各种优惠，再修改订单状态，步骤以及相关的支付信息为成功。
参考2）
第三方返回的状态实际是3种，返回成功，返回失败和无返回。当无返回时，如果处理成返回失败，就会让用户支付两笔，这本身是一种最糟糕的选择。沿着这个最糟糕的选择去做退款逻辑，是错上加错。
我们应该引入一个单独的支付层，它可以做两个事情：1.delay第2次支付请求 2.通过另一组接口查询第1次支付状态。 在最无能为力的情况下，提示用户异常并在24小时内对账后处理解决。当然用户如果确实急的不行，另下一单即可。
说回真实情况，支付宝等第三方成熟的支付平台，自然会根据重复的购物订单号来做好预防
参考3）
问题：
如果用户出现了2次支付并且都成功了，后台逻辑退款这一块如何设计？
这块其实要通过账务的对账长款能区分出来，理论上来讲第二天支付通道返回的交易流水文件每一笔跟你的订单交易记录是一一对应的。一旦有一笔订单支付N次的话，则可能出现一个现象就是支付通道返回的交易流水会多出（N-1）笔，那这些就是长款，财务确认无误后可以手动发起退款。
是否可以避免这种情况的发生？如果可以怎么去避免呢。
理论上每一笔订单发起支付的时候都会有统一下单的过程，会把订单单号作为外部交易流水号加上其他信息打包去支付方生成支付订单，如果一笔订单在支付方已经支付的话，用户再次打开这个页面应该是会被提示订单已支付。除非每次点击“支付”生成的支付通道流水号都不是唯一，则可能出现。
同时，建议你在后端做一些未支付订单主动查询的动作，例如：最近15分钟生成的未支付订单后端主动查询一下支付状态”等等，可以优化这块的困扰。
参考4）
1、如果用户出现了两次支付并且都成功了......
看你站在谁的角度去解决问题了，一般后台都是有应付、实付、立减、优惠等字段的。1）等着用户来找你（不找你的你帮公司赚了），2）财务对账发现问题，3）你主动为用户解决。至于回答中还有什么根据流水来的，首先请求流水是控制不了得；返回成功流水，那可能是你们业务暂时不涉及到组合支付，分次支付...
2、怎么解决？
前端：1）交互方式改变，有的是新开页面，例如PC，如果同时开了两个第三方页面，那只能让其继续支付了（在没收到消息前调起SDK也是一样无法避免），有的是原页面跳转，这种也一定程度上避免了用户打开很多页面自己搞乱掉了再去发起支付。2）在选择支付渠道，发生【去支付】动作时也可以做一个接口判断，有没全部付完款？在这之前还有订单及业务资源等一系列判断，与此题无关。
系统：支付页设置定时器，维金系统中查询功能也蛮好的，支付请求开始后，半小时之内去跟踪状态，查询频率由高到低。有开始你就要去考虑终止，涉及到资源问题要依据自己公司的情况，想法跟落地从来都是矛盾的。
最后，第三方信息返回延迟，失败率都没有想象中的那么不友好。场景上，例如移动端支付宝微信会有个支付后的等待动作，不会立马再让你去发起【去支付】。我的经历一般重复支付这样的问题都是内部支付系统跟订单系统太不稳定导致的...
参考5）
接口支持幂等性的话，同一条流水只会执行一次，就算无返回，再次发起时会直接返回结果，不会执行的。
网友评论