支付架构调用流程以及常见支付问题解决方案
目录
支付服务特点
流程图
支付中一般都会遇到什么问题以及解决方案？
用户恶意下单（刷单）怎么办？
如何防止重复下单？
支付回调并发怎么办？
如何做到幂等性？
回调延时，如何解决?
如何保证数据一致性？
mq通知失败怎么办？
mq重复消费怎么办？
如果用户支付成功了，但是自己的订单超时了，而回调在超时之后才回调如何处理？
支付在业务中很重要，这里我根据自己做过支付模块的一些理解和大家讨论一下支付的那些事
支付服务有什么特点
安全性：幂等
健壮性：商户通知系统若挂掉，影响发货，所以通知系统要保证其可用性
及时性：及时通知，对商户的发货和订单扭转至关重要
流程图
下面我画了一种方案的时序图大家可以借鉴，还有其他方案暂不深说
时序图如上
- 客户端下单（下单的时候可以锁定库存，锁券，计算价格生成订单），跳转到支付页面，这时候已经有待支付的订单了，各种优惠已经算好，即使返回在待支付栏中也可以找到该订单进行支付
- 支付：点击支付，可以根据订单号查到此订单，进行一些简单的验证，（其中支付需要的金额一定要从该订单中取，不可信任前端的金额）
- 验证后请求支付服务，支付服务接口根据一系列参数封装，请求第三方支付的API，第三方返回对应的预支付标识，如微信的prepay_id，再根据标识等参数进行签名得到sign，最后封装签名后的参数封装返回客户端，客户端调起第三方支付。支付成功后，同步返回客户端，异步回调返回支付服务
- 支付服务接受回调，验签，记录回调过来的请求信息，一般都会有支付单号，订单号，商户号等，（可以针对订单号做个uk，如果第三方支付重复回调了就不用处理了），最后发送mq给业务方
- 业务方消费mq处理业务
- 客户端跳转到支付成功页面
方案2：有一些企业由于业务场景的不同，下单和支付也可以做在一起，选品后跳到下一个页面并没有下单， 因为退出后在待支付中没有看到待支付订单；在去结算的时候才下单，调起支付，这中间没有其他人为操作，如果不支付去待支付页面可以看到待支付订单继续支付即可
一般来说不用后续的主动查询，如果要保证及时性可以采取这个方案，因为第三方可能会回调延时，这会导致我们自己的服务接不到回调，处理不了业务，下面继续说
支付中一般都会遇到什么问题以及解决方案？
用户恶意下单（刷单）怎么办？
对userid进行限制，比如一单购买商品的数量限制、1h内未支付订单的数量限制、ip限制
如何防止重复下单？
1. 前端按钮灰度
2. 下单重定向跳转页面
3. 后端分布式锁防止并发
4. 同一笔订单生成一个唯一号，存在后端UK，作为重复判断
支付回调并发怎么办？
添加回调记录时，数据库orderSn设置uk
服务解耦
支付服务和业务方的服务解耦，防止并发量大的时候通知阻塞
使用rocketmq：解耦，削峰
如何做幂等？
对于回调可能有多次，对于消费方可能网络抖动等原因导致消费两次
回调时，orderSn设置UK即可
业务方消费时验证订单是否处理过，若可以用uk控制最好不过
业务逻辑幂等：如果已处理则消息做成功处理
回调延时，如何解决?
1.起一个定时任务定时检查订单状态做主动查询进行业务处理
缺点：不及时
2.前端跳转时检查订单状态，未支付则触发主动查询更新订单状态
缺点：不论是否延时都要调用接口查询订单状态，一定程度上影响性能，而大多数情况都是回调成功的。
注意：回调通知和主动查询都需要更新订单状态，可加分布式锁控制，防止并发
刚刚说过大多数都是回调成功的，如果采用2方案，有一个问题：主动查询和回调同时进行也就是并发怎么办？在可能有影响的点上加上分布式锁保证安全
回调通知业务方消费时处理完业务可以在redis中对订单号打一个标记，客户端主动查询若查到这个标记证明已经有回调在处理过了，那么订单一定是成功/失败，直接返回跳转即可，不用查询数据库订单，性能会好一点，极端情况下会存在回调和查询并发的情况，注意是否影响订单幂等性
如何保证数据一致性？
最大努力通知方案：对于支付服务来说已经有结果了，要尽自己最大努力告诉业务方结果，业务方处理的成功失败不关心
支付回调验证订单是否处理过：处理过则给第三方回复确认；如果处理失败了则可以有个定时任务扫描（已处理，发送失败的订单）重新发送，如果最终通知失败则通知人工处理（这种情况不多）
支付回调延时的情况如上，现在只讨论正常回调的情况
回调成功，验签成功，记录回调信息（可用于UK去重）失败（此处可能是bug哈哈，可以不处理，依赖下次回调，也可以往下走，不记录也可以发送mq，处理业务要紧），成功则发送mq，发送失败则记录失败记录，定时任务扫描发送
mq通知失败怎么办？
通知失败则1.重复通知，或者2.持久化，或者不用担心，3.web跳转可以主动查询，反查订单处理订单状态，具体方案可以灵活选择
mq重复消费怎么办？
要幂等，验证订单是否被处理过
如果用户支付成功了，但是自己的订单超时了，而回调在超时之后才回调如何处理？
1.设置支付订单的时间与支付宝交易单号的自动关闭时间一致;
2.支付宝有主动查询交易状态接口;一般我们都采取主动查询的方案
3.支付宝可通过接口主动关闭订单;
4.回调时检查订单状态,若订单已关闭则直接向支付宝发起退款请求,交易结束。
希望可以帮到大家，后面有时间我再完善一下，大家有好的想法也可以私我一起讨论
支付架构调用流程以及常见支付问题解决方案相关推荐
- 微信公众号支付申请配置流程
微信公众号支付申请配置流程 公众号支付申请步骤 微信公众号支付配置 公众号支付:用户在微信内进入商家H5页面,在页面内完成支付. 公众号支付申请步骤 注册公众账号(政府或媒体订阅号.服务号才能接入支付 ...
- 集成支付宝支付流程 和查询支付的结果
一:介绍 支付之前,在网上也查寻了资料, 支付接入坑太多,微信坑最多,api文档太复杂. 二:交互流程 建议先把开发文档仔仔细细看一遍,一定要看,刚开始的时候没有老老实实地看完,结果遇到很多的坑,浪费 ...
- php微信支付jsapi,ThinkPHP中实现微信支付(jsapi支付)流程
之前写过一篇文章讲了 PHP实现微信支付(jsapi支付)流程 ,详见文章:PHP实现微信支付(jsapi支付)流程. 当时的环境是没有使用框架的,直接在一个域名指向的目录下边新建目录之后访问该目录实 ...
- 微信架构 支付架构（下）
微信架构 & 支付架构(下) 管理网络请求 首先看看原来 iOS 处理支付网络请求的缺陷: 原来支付的请求,都是通过一个单例网络中心去发起请求,然后收到回包后,通过抛通知,或者调用闭包的方式回 ...
- 微信支付架构为什么这么牛？
" 微信支付在各个操作系统,各个应用下的挑战还是蛮大的,这也得益于腾讯架构师的专业. 作为一个重要业务,微信支付在客户端上面临着各种问题,其中最核心问题就是分平台实现导致的问题. iOS 和 ...
- 探讨一下常见支付系统的对外接口
作为一个具备用户交易能力的网站,丰富它的支付渠道对于获客和提高日活都 有不可估量的积极作用.算起来,我接触过的支付系统也有几十个了,在这里总结一下我所接触过的支付系统对外接口的设计方案. 1. 支付宝 ...
- 易宝支付架构师移动产品线技术负责人程超走在Java的路上
程超目前就职于易宝支付,任职架构师.人们常说,一个架构师工作的好坏决定了整个软件开发项目的成败.可见架构师的重要性所在,在程超看来做好一名构架师要做到"言传身教",架构师作为技术工 ...
- 【CSDN英雄会】 易宝支付架构师、移动产品线技术负责人程超:走在Java的路上
英雄会是CSDN旗下针对国内IT技术领域专家展示和交流的平台.通过线下线上的互动形式,为CSDN社区专家提供更多学习.合作.宣传的机会.英雄会后续将在北上广深等国内一二线城市建立分会,各个分会后期将组 ...
- 移动端---混合开发1 + 支付相关操作（手机app支付、网页支付）--支付流程
混合开发 1️⃣ 以前端为主导进行开发(Hybrid app)(即所有的页面部分都是用网页 h5 的技术来做的,Hybrid 是做编辑器的) uniapp.mui 是国内主流的小公司做混合开发的技术. ...
最新文章
- android 将bitmap存为 bmp格式图片大小,Android Bitmap保存為.bmp格式，圖像轉化為黑白圖片...
- 自定义ProgressBar(自定义View和ClipDrawable)
- 视频营销、B2B营销、EDM营销之营销方式大PK
- 包银消费CTO汤向军：消费金融大数据风控架构与实践
- 我的独白2017-12-20
- python常用功能_python----常用功能
- 谷歌核心算法大更新，如何趋利避害对电商网站排名影响？
- 18个C/C++的基本知识点，带好小本子记录一下
- html毕业作品,基于HTML制作的闲置交易网站设计毕业论文+开题报告+Html静态网页源码...
- Flash 平台音视频直播的实现
- msxml6 x86.msi v6.10.1129.0
- 帆软报表扩展列计算同比环比
- 你还在用二分法求2个鸡蛋100层楼的问题吗？
- 广成子：值得收藏-史上最全Linux ps命令详解
- 有机化学研究生博士生为什么被要求长时间工作
- 提权-Windows操作系统
- 用户画像如何分析 用户画像如何获取
- ubuntu下sed命令详解 - Dicky - 开源中国社区
- Linux系统搭建jupyter notebook
- ArcGIS求坡度、坡向、坡长、地形起伏度