在我们支付系统设计中，经常会遇到这样一个问题，防止用户重复支付。用户明明只想购买一次，却因为系统问题，导致重复支付，带来额外的物流成本和扯皮退货的运营成本，对商家的信誉和系统的体验很不好。
那么实际我们在设计支付系统时，如何来避免这一问题呢。
为什么会出现重复支付
1.客户误操作点了两次
比如下单的按键在点按之后，在没有收到后端返回之前，按键的状态没有设为已禁用状态，还可以被按。
2.支付渠道端返回超时
用户在收银台页面点击某个支付方式后，在支付渠道（比如网银或者微信支付宝）上完成付款，但是渠道端返回的异步通知超时，导致系统付款状态尚未更新，用户并不清楚到底订单是否支付成功，而导致再次支付。
概述
如图是一个简化的下单流程，首先是提交订单，然后是支付。支付的话，一般是走支付网关（支付中心），然后支付中心与第三方支付渠道（微信、支付宝、银联）交互，支付成功以后，异步通知支付中心，支付中心更新自身支付订单状态，再通知业务应用，各业务再更新各自订单状态。
这个过程中经常可能遇到的问题是掉单，无论是超时未收到回调通知也好，还是程序自身报错也好，总之由于各种各样的原因，没有如期收到通知并正确的处理后续逻辑等等，都会造成用户支付成功了，但是服务端这边订单状态没更新，这个时候有可能产生投诉，或者用户重复支付。
由于③⑤造成的掉单称之为外部掉单，由④⑥造成的掉单我们称之为内部掉单
在我们实际支付系统设计中，我们系统设计人员经常无法区分商品订单和支付订单之间的关系，经常混为一谈。所以本文谈论的是支付订单的防重复，商品订单的防重复需要另外讨论（包括用户误操作、客户端和后台时延、以及支付和商品订单状态更新不同步等问题）。
为了防止掉单，这里可以这样处理：
1、支付订单增加一个中间状态“支付中”，当同一个订单去支付的时候，先检查有没有状态为“支付中”的支付流水，当然支付（prepay）的时候要加个锁。支付完成以后更新支付流水状态的时候再讲其改成“支付成功”状态。
2、支付中心这边要自己定义一个超时时间（比如：30秒），在此时间范围内如果没有收到支付成功回调，则应调用接口主动查询支付结果，比如10s、20s、30s查一次，如果在最大查询次数内没有查到结果，应做异常处理
3、支付中心收到支付结果以后，将结果同步给业务系统，可以发MQ，也可以直接调用，直接调用的话要加重试（比如：SpringBoot Retry）
4、无论是支付中心，还是业务应用，在接收支付结果通知时都要考虑接口幂等性，消息只处理一次，其余的忽略
5、业务应用也应做超时主动查询支付结果
对于上面说的超时主动查询可以在发起支付的时候将这些支付订单放到一张表中，用定时任务去扫
为了防止订单重复提交，可以这样处理：
1、创建订单的时候，用订单信息计算一个哈希值，判断redis中是否有key，有则不允许重复提交，没有则生成一个新key，放到redis中设置个过期时间，然后创建订单。其实就是在一段时间内不可重复相同的操作
附上微信支付最佳实践：
image
作者：MarkerHub
链接：https://juejin.cn/post/6956790589606068232
来源：掘金
如何防止重复支付提交
对于支付重复提交的处理，一般有两种主流的办法：一种是京东收银台的，京东允许客户对一笔商品订单做多次支付，而对于第二笔以上的支付，走退款流程；另外一种是对订单幂等要求比较高的银行收银台，往往是要求商品订单状态和支付订单状态强一致性。
这里，我们重点讨论第二种方式，保持支付订单的幂等性来防止重复支付。
针对一笔商品订单，在支付时，产生一个唯一的支付订单号，这个支付订单号包含了客户选定的支付落地的支付方式和真正的支付渠道。
支付系统对这个支付订单号做交易的幂等。
1.如果不存在该支付订单号，则记库，并标记状态为支付中，然后调用渠道进行支付落地。
2.收到渠道异步通知或者通过查询得到渠道支付状态时，更新该笔支付订单状态
3.如果客户再次发起支付，不给客户产生新的支付订单号，先用该笔支付订单号调用支付系统，支付系统会判断订单号幂等性，如果已支付，则报错告诉客户已支付成功，请勿重复支付；如果支付失败，则新产生流水调用渠道进行支付落地；如果支付状态未知，则告诉客户，交易状态未知，请发起查询或者关单。
4.针对状态未知这种情况，如果支持冲正和关单则最好，如果不行，只能让客户发起查询。在这种情况下，如果客户等不及，才流转到最坏的可能，客户重新下一单商品订单，这单根据最终渠道对账情况，给客户做退款。这种情况下需提示客户确认未发起前一笔支付，再新创建，否则，前一笔需要等第二个工作日状态确认后进行退款处理。
如果出现上述最坏情况怎么办
如果出现上述4里面最坏的情况，还是会有用户误操作，直到收到两份商品才发现下重了。此时就得依靠运营/客服的支持了。提供用户申诉的手段，让用户提出哪些订单是重复的，并且由销售系统店家、商品提供者和买家三方共同根据用户操作的记录来协商如何处理。我们需要让技术帮助让这种人工处理的几率尽量小。因为每次处理都会耗费较大的人工成本，和一些运营费用（比如赔款、小礼品等等）。
作者：myseries
链接：https://www.cnblogs.com/myseries/p/10933966.html
来源：cnblogs
结论
在实际设计中，无论多么好的技术，也不可能100%的拦截所有的可能性，必须依靠技术+产品设计+运营支持的综合手段才能解决这类问题。所以即便京东这一类电商等也是配合运营手段进行处理。
在实际业务场景中，可能还会有各种各样复杂的情况，我们只能以尽可能保护我们系统自己的方式，将重复下单可能性降到最小，并且即使发生，我们也不能出现短款，再结合运营手段进行差错处理。
若有收获，就点个赞吧
0 人点赞
