服务端如何防止重复支付

简介: 服务端如何防止重复支付

概述

image.png

如图是一个简化的下单流程,首先是提交订单,然后是支付。支付的话,一般是走支付网关(支付中心),然后支付中心与第三方支付渠道(微信、支付宝、银联)交互,支付成功以后,异步通知支付中心,支付中心更新自身支付订单状态,再通知业务应用,各业务再更新各自订单状态。

这个过程中经常可能遇到的问题是掉单,无论是超时未收到回调通知也好,还是程序自身报错也好,总之由于各种各样的原因,没有如期收到通知并正确的处理后续逻辑等等,都会造成用户支付成功了,但是服务端这边订单状态没更新,这个时候有可能产生投诉,或者用户重复支付。

由于③⑤造成的掉单称之为外部掉单,由④⑥造成的掉单我们称之为内部掉单

为了防止掉单,这里可以这样处理:

1、支付订单增加一个中间状态“支付中”,当同一个订单去支付的时候,先检查有没有状态为“支付中”的支付流水,当然支付(prepay)的时候要加个锁。支付完成以后更新支付流水状态的时候再讲其改成“支付成功”状态。

2、支付中心这边要自己定义一个超时时间(比如:30秒),在此时间范围内如果没有收到支付成功回调,则应调用接口主动查询支付结果,比如10s、20s、30s查一次,如果在最大查询次数内没有查到结果,应做异常处理

3、支付中心收到支付结果以后,将结果同步给业务系统,可以发MQ,也可以直接调用,直接调用的话要加重试(比如:SpringBoot Retry)

4、无论是支付中心,还是业务应用,在接收支付结果通知时都要考虑接口幂等性,消息只处理一次,其余的忽略

5、业务应用也应做超时主动查询支付结果

对于上面说的超时主动查询可以在发起支付的时候将这些支付订单放到一张表中,用定时任务去扫

为了防止订单重复提交,可以这样处理:

1、创建订单的时候,用订单信息计算一个哈希值,判断redis中是否有key,有则不允许重复提交,没有则生成一个新key,放到redis中设置个过期时间,然后创建订单。其实就是在一段时间内不可重复相同的操作

附上微信支付最佳实践:

image.png


目录
相关文章
|
NoSQL Java Redis
服务端如何防止订单重复支付!
如图是一个简化的下单流程,首先是提交订单,然后是支付。 支付的话,一般是走支付网关(支付中心),然后支付中心与第三方支付渠道(微信、支付宝、银联)交互。 支付成功以后,异步通知支付中心,支付中心更新自身支付订单状态,再通知业务应用,各业务再更新各自订单状态。
服务端如何防止订单重复支付!
|
5月前
|
消息中间件 NoSQL 中间件
关于实现订单超时的几种方案(详细细节版)
关于实现订单超时的几种方案(详细细节版)
105 0
关于实现订单超时的几种方案(详细细节版)
|
5月前
|
JSON 监控 供应链
如果请求的商品不存在,如何处理?
在电商领域,了解商品详情对于消费者和商家来说都至关重要。消费者需要了解商品的具体信息以做出购买决策,而商家需要掌握商品详情来优化库存管理和营销策略。京东开放平台提供的商品详情 API 允许我们批量获取多个商品的详细信息。通过该 API,我们可以一次性查询多个商品,提高获取信息的效率,更好地满足业务需求。
|
8月前
|
消息中间件 NoSQL 数据库
订单超时未支付自动取消--实现简述
订单超时未支付自动取消--实现简述
146 0
|
10月前
|
存储 NoSQL Redis
下单接口防重提交问题
下单接口防重提交问题
|
消息中间件 存储 资源调度
订单超时怎么处理?我们用这种方案
在电商业务下,许多订单超时场景都在24小时以上,对于超时精度没有那么敏感,并且有海量订单需要批处理,推荐使用基于定时任务的跑批解决方案。
1053 0
订单超时怎么处理?我们用这种方案
|
消息中间件 负载均衡 Java
下单消息的发送和接收案例|学习笔记
快速学习下单消息的发送和接收案例
160 0
下单消息的发送和接收案例|学习笔记
|
消息中间件 Java RocketMQ
支付业务服务端测试|学习笔记
快速学习支付业务服务端测试
81 0
支付业务服务端测试|学习笔记
|
消息中间件 Java RocketMQ
发送确认订单失败消息演示|学习笔记
快速学习发送确认订单失败消息
70 0
发送确认订单失败消息演示|学习笔记
|
消息中间件 Dubbo 测试技术
Rest 方式测试支付下单和支付回调|学习笔记
快速学习 Rest 方式测试支付下单和支付回调
163 0
Rest 方式测试支付下单和支付回调|学习笔记