有没有什么方法能在网络不好的情况下保证支付和业务的一致性

130 天前
 dongpengfei1

最近做了一个支付平台,在每个窗口部署可以二维码和银行卡支付。但窗口和服务器之间一天会有 5%的丢包率。 总会造成支付成功然后就丢包了,业务失败。每天的长帐不少,客户需要重新付一笔钱,转天财务对长帐才会退回。客户的满意度也非常低。 网络问题排查不出来,因为窗口的其他程序请求和服务器同网段的另外一台服务器一点问题没有。

有没有哪位大佬能给一个思路的。

我目前想到的是把支付信息传给另外一台服务器的程序,然后再通过它调用我的支付平台,成功与否在进行业务判断。但这个动静太大。另一方不愿意做。

另外一个方法是,我直接判断业务没有成功,就会退款,但有可能是业务的中间状态我就给退了。这样有很大可能造成短帐。这个月因为其它原因已经短帐好几次了,实在受不了把它变成一个长期的问题。找客户要钱也是个麻烦事。客户不给就得自己垫钱了。

2871 次点击
所在节点    程序员
27 条回复
vcn8yjOogEL
130 天前
TCP 抗丢包, 业务流程加双向确认
vcn8yjOogEL
130 天前
此外支付本身应该在确认交易后再开始, 吞钱这种事最开始就不应该出现
vcn8yjOogEL
130 天前
#2 不对这个和客户端无关
dongpengfei1
130 天前
@vcn8yjOogEL 不太行, 双向确认的话中间等待时长不确定。时间太长的话客户会着急。之前做过一版两分钟的等待,窗口的收费人员和客户都反馈不满意,时间太长了。

我打算节后跟另外的那个程序的人练一练,他不改我就让窗口等着。看谁先受不了。
pagxir
130 天前
业务失败的时候,不能发起冲正么
ZZ74
130 天前
哎~~这年头

发起支付的一方产生一个 ID 之类的号,发起支付时传给支付服务。
支付服务判断这个 ID 对于这个请求方是否已存在,存在就返回支付状态。
hallDrawnel
130 天前
支付完之后,指数退避去查状态,设置一个几分钟的最大上限就可以了。或者从业务逻辑去看有没有让整个交易重入的办法,用同一个订单号去对方支付系统里重试支付。
dongpengfei1
130 天前
@vcn8yjOogEL 已经确认交易了,但在交易过程中支付成功,支付成功状态回传失败(中间丢包了)。然后业务就会认为失败。
因为我们和客户端的不是同一家,所以说这个很蛋疼。
上支付平台的时候他们已经改过一次了,直接从客户端掉我们的支付程序,然后再返给他成功状态(之前公司都是这么干的)。
我目前想到了一个办法,就是我这里加一个等待,然后让对方做一个支付回查接口和一个支付状态修改的接口。对方失败之后直接改他的支付状态。然后再让他的窗口程序加一个重试按钮,回查他自己的支付表。但窗口人员点了取消,或者直接把程序结束了,钱还是会长帐。
并且我对他们的程序员的技术表示迟疑态度,他们干过太多匪夷所思的事了,真是老天爷赏饭吃。
dongpengfei1
130 天前
@pagxir
@ZZ74
@hallDrawnel
不行不能这么干,支付宝小程序已经发生过类似的事了,不知道他们是怎么写的程序,并发量一大。就变成了支付成功对方也认为支付成功,但业务状态回查一直是支付中。然后超时就退款了。过一阵他们自己又成功了。
现在就是支付宝小程序支付的时间就硬等 30 秒。
但窗口排队的人多呀,弄不好就客户就急眼了。
xiangyuecn
130 天前
这系统能要到钱也是奇迹😂
ccde8259
130 天前
客户端向服务端同时发起三个请求,任意一个请求成功了就认为成功了……
服务端向客户端下发支付成功消息,发三遍,收到任意一个消息就认为成功了……
三个请求都发生丢包的概率 = 5%^3 = 十万分之 125……
dongpengfei1
130 天前
@ccde8259 不行,丢包有一定的连续性,并且 5%只是我那一天监控网络的时候的数值不具有太大的参考性。上上周有一个客户 20 分钟连着支付了三次都没成功,最后付的现金。他没急眼我都惊呆了。
还有一个在周五半夜付了一千多块钱然后失败了的,周一下午才退。他中间没找过来闹也是个奇迹。
dongpengfei1
130 天前
@xiangyuecn 业务系统不是我们的,老天爷赏饭吃你能有什么办法。我头发都要掉光了,终于明白什么叫做甲方爸爸了。
lance6716
130 天前
那么你愿意出多少钱买思路呢?
ccde8259
130 天前
@dongpengfei1 设备网络能不能换,比如搞个啥 5G CPE 专门跑这个业务……其实相当于拉专线把高优先级业务跟低优先级业务隔离开来
chenqh
130 天前
没看懂
dongpengfei1
130 天前
@ccde8259 换不了,窗口是纯内网电脑,并且我们这里的服务端也是个屎山。单独的支付代码拆不出来,要是能拆开的话我直接在另外一边部署上就 ok 了。
devliu1
130 天前
重试
esee
130 天前
我之前做过差不多的情景,之前是客户支付成功后等待支付系统给我一个支付结果的回调,但是不知道是回调的问题还是我后端的问题,有出现用户说支付成功了但是我没收到回调的情况,然后手动向支付系统发起查询确认这个交易状态才知道已经成功。后来我就写成双向确认,客户端支付成功缓存结果并向我后台发送一个支付成功的通知,支付系统也给我一个通知。如果支付系统确认成功就是成功,如果出现客户端显示成功但是没收到支付系统的回调,则等待多少秒后主动向支付系统查询交易状态,这样之后就没出现过状况了。
GoodAfternoon
130 天前
为保证支付成功率,流程中应该允许重复支付的存在。可以在收款回调流程判断是否存在同一订单多次收单的情况,进行自动退款即可。不一定需要依赖第二天的财务对账才能知道长款。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1004689

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX