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

查看 83|回复 4
作者:dongpengfei1   
最近做了一个支付平台,在每个窗口部署可以二维码和银行卡支付。但窗口和服务器之间一天会有 5%的丢包率。
总会造成支付成功然后就丢包了,业务失败。每天的长帐不少,客户需要重新付一笔钱,转天财务对长帐才会退回。客户的满意度也非常低。
网络问题排查不出来,因为窗口的其他程序请求和服务器同网段的另外一台服务器一点问题没有。
有没有哪位大佬能给一个思路的。
我目前想到的是把支付信息传给另外一台服务器的程序,然后再通过它调用我的支付平台,成功与否在进行业务判断。但这个动静太大。另一方不愿意做。
另外一个方法是,我直接判断业务没有成功,就会退款,但有可能是业务的中间状态我就给退了。这样有很大可能造成短帐。这个月因为其它原因已经短帐好几次了,实在受不了把它变成一个长期的问题。找客户要钱也是个麻烦事。客户不给就得自己垫钱了。

短帐, 长帐, 支付, 服务器

vcn8yjOogEL   
TCP 抗丢包, 业务流程加双向确认
vcn8yjOogEL   
此外支付本身应该在确认交易后再开始, 吞钱这种事最开始就不应该出现
vcn8yjOogEL   
#2 不对这个和客户端无关
dongpengfei1
OP
  
@vcn8yjOogEL 不太行, 双向确认的话中间等待时长不确定。时间太长的话客户会着急。之前做过一版两分钟的等待,窗口的收费人员和客户都反馈不满意,时间太长了。
我打算节后跟另外的那个程序的人练一练,他不改我就让窗口等着。看谁先受不了。
您需要登录后才可以回帖 登录 | 立即注册

返回顶部