共计 2319 个字符，预计需要花费 6 分钟才能阅读完成。
封面送给我狗哥~
Hello，大家好，我是楼下小黑哥~
明天的文章咱们接着上次的话题，持续聊聊领取零碎异样解决办法。
在上篇文章中「领取掉单异样解决方案」，咱们次要提到的是领取过程中掉单的场景，用户明明付款胜利，银行卡都扣款了，然而订单却还显示待付款。
而在明天的文章中，咱们将聊到反复付款的异样，即同一笔订单，扣了用户两笔钱。
另外咱们还将会提到另外一种异样，用户扣款胜利，然而订单却领取失败的场景。
以上两种异样对于被扣款的用户来讲，应用体验极差，本人多付了钱，订单却还不胜利。所以如果不及时处理这两类异样，那就真的等着被投诉吧。
欢送关注我的公众号：程序通事，取得日常干货推送。如果您对我的专题内容感兴趣，也能够关注我的博客：studyidea.cn
反复付款异样
异样场景
反复付款异样个别常见于网银领取，微信领取，支付宝等这类须要跳转到一个领取网关页（网银领取），或者跳转到钱包 APP(支付宝、微信)，从而异步实现扣款的领取场景。
这种领取场景下，只能通过承受异步告诉能力晓得领取后果，咱们个别将其称为异步领取。
PS：有了异步领取，那么同步领取是什么？
其实同步领取指的就是调用领取接口之后，就能够立即返回领取后果的，比方银行卡类快捷 / 代扣等领取就是同步领取。
当然也有一些奇葩的银行卡领取渠道，同步领取后果为受理胜利，只能承受异步告诉或者查问返回领取后果。
因为银行卡领取须要返回明确领取后果，对于这类渠道只能外部设计将异步转为同步, 感兴趣能够看下之前历史文章：
架构设计 | 异步申请如何同步解决？
后盾领取流程如下：
图片来自之前的文章: 银行卡领取原理
为什么会产生反复付款？
次要起因其实跟上次外部掉单异样一样，跟业务表设计无关。
上次咱们提到，领取零碎次要表构造如下：
在这个表构造下，只有领取订单未胜利，商户就能够重复使用其外部同一订单号调用领取接口。
假如这样一个场景，用户在收银台领取时抉择招行进行网银领取，当他点击领取之后，商户零碎将会调用领取公司的网银接口。
这时领取零碎外部将会创立一笔领取单以及关联的渠道订单，并且调用招行零碎的接口。
而后用户的浏览器页面将会关上一个新页面，而后跳转到招行网站。
这时如果此时用户再次在收银台点击领取，将会再次调用领取零碎接口。这时候因为领取单已存在，所以仅仅会再创立一条渠道订单记录，并且调用招行零碎的接口。这时用户的浏览器将会再次关上一个招行的网站。
如果用户在两个招行网银页都实现领取，这时就产生了反复付款。
下面这种场景看起来有点傻, 然而实在用户操作真的会产生。除了这种，博客园上的小伙伴还提到这么上面这种状况：
解决办法
反复付款异样的次要的解决办法有两种，分为事先与预先。
事先次要的目是尽可能避免用户反复付款，次要解决办法为优化付款页面，尽可能做好提醒。
第一种优化形式，付款页面间接跳转到第三方 / 银行的网银页面，不要关上新的页面去跳转。
这种形式能够避免用户误关上两个网银付款的页面，从而导致反复付款。
然而这里会有一个问题，银行网银页面付款胜利之后，用户如何晓得其在商户侧订单状态也胜利了？
其实很简略，当初网银领取接口，个别都会有一个参数 return_url: 同步跳转地址 。
只有在接口传入这个地址，当领取胜利之后，页面最终就会跳转到这个传入的地址，商户侧就能够在地址显示订单是否领取胜利。
下面咱们提到，用户有可能会应用浏览器回退性能，跳转到领取页，从而导致反复付款。
对于这种状况，咱们能够在其回退领取页时，首先向后盾查问这笔订单领取后果，如果已领取胜利，那就间接显示胜利页面。
第二种优化，对于这种从新关上一个页面跳转到银行网站，咱们能够在页面退出弹窗提醒，询问用户是否已领取实现。
比方下面这种解决形式，当用户点击确认实现充值，能够马上向后盾发动查问订单状态。
上面来聊聊预先的解决办法， 其实解决办法很简略，发动外部退款，将多余领取的一笔反向退款回去 。
领取零碎外部能够有个定时工作，定时扫描领取单下有多条胜利渠道订单的记录，而后抉择将反复领取渠道订单发动退款。
这种形式是领取公司零碎外部的操作，不须要商户侧发动指令。
订单生效异样
异样场景
这种场景个别常见于电商购物，秒杀等购物场景。当用户下单之后，页面将会开始倒计时，用户须要在有效期内领取胜利。
假如用户点击跳转到支付宝，然而其没有立即领取，而是停留了很久，在订单最初一秒工夫内实现了领取，然而这个时候订单早已因为工夫到期而被主动勾销。
这样就产生用户扣款曾经胜利，然而订单却是失败或敞开的场景的。
另外还有一种状况，用户在有效期内领取胜利，然而因为网络、外部利用等问题，领取后果的异步告诉过了很久才收到，这时外部订单的早因为工夫到期而被勾销。
解决办法
第一种解决办法，上送有效期给领取渠道。
个别领取接口都会有一个领取有效期的字段，表明这笔领取最晚能够领取的工夫。如果超时未领取，这笔领取将会被敞开。
当然个别状况下，如果未上送，这个字段外部个别会有个默认的有效期，比方 3 天，这个工夫就比拟长了。
所以当调用领取接口时，能够将订单残余有效期传入领取接口。这样用户如果在超时工夫内未实现领取，领取将会失败。
第二种解决办法，外部发动退款。
这个解决办法仍然预先托底的解决办法，对于领取订单已敞开，然而领取却胜利的状况，发动外部退款，将钱退给用户。
外部能够有个定时工作，定时扫描领取订单已敞开然而领取却胜利的状况，而后发动退款指令。
最初
最初用思维导图形式帮大家总结一下领取零碎可能会碰到的异样。
历史领取零碎相干文章
- 收款神器！解读聚合收款码背地的原理 | 原创
- 手机没网了，却还能领取，这是什么原理？| 原创
- 微微一扫，立即扣款，付款码背地的原理你不想晓得吗？| 原创
- 领取渠道路由零碎进化史
- 从零开始设计对账零碎
