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

[dongpengfei1]

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

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

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

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

[dongpengfei1]

@esee 业务系统不是我们的，甲方接入支付平台的时候，找业务系统那边加支付选项的时候，他们硬是做了一个月。结果还是有部分支付页面没有调用我们。
我都好了奇了，这种不应该是在支付列表里面写好配置好，加了选项就能用的东西吗？为什么要一个页面做一个支付接口。
节后肯定要和他们 batlle 一下。让他们把双向确认的接口加上。

[dongpengfei1]

@GoodAfternoon 业务系统那边做不到 /(ㄒoㄒ)/~~
他们的代码实在太烂了。他们给我的接口信息只有订单号，钱数，支付状态（还是他掉我写的客户端的 dll 给他返的），收费员编号，客户信息。
客户信息还是我因为对账催了一个星期，才把之前小程序支付的时候本来就有的信息给加上的。就两个列，客户信息他竟然加了一个星期，你能想象的到吗？
最早长帐的时候财务只能把这些长帐原路退回，但不知道退回了那些客户。然后中间短帐了，我还是找他们要的日志，一点一点的对出来的客户信息。我这边根本不知道是谁支付了这笔钱。
他们根本就不按照你的 api 手册去做。
妈的，节后肯定要和他们练练不是他死就是我活。
而且我们的屎山也非常的大。
你有见过流水线式的代码吗？不面向对象也就算了，至少也得面向函数吧。他写了流水线式的代码。还不敢动，影响了好几家公司的业务。弄不好就是罪过，每当加功能的时候我都害怕。一个系统配置文件走了仨（谁能相信，改了其中一个配置文件不好使，得改其它配置文件的相同的选项）。
要不是合适工作不好找早跑路了，这干的是要人命的活。

[julyclyde]

你这 5%也太高了点……
如果你的业务真的很严肃，应该改一下线路
如果是垃圾业务就忍了吧

[dongpengfei1]

@julyclyde 我是给甲方干的人家说自己的网没问题，并且在其它同网段的服务器也没问题。只有我的这个支付平台有问题。

[dongpengfei1]

朋友们，没打过，业务方不肯改，甲方也不配合。还是从拖着等甲方去查他们的网络吧。

[julyclyde]

@dongpengfei1 同网段其他也没问题？？？

[dongpengfei1]

@julyclyde 对，同网段其他的服务器就没问题。他这个是分两个区域，之间是专线连接。服务器所在的区一点问题没有。
找甲方，他就不认。就说为什么同一个网段同一个机架上的其他服务器就没事。我都无语了。
他们网络知识也没有，拓补图也不给。
这个就是他们专线之间防火墙的事。弄的我把客户端分别连到正式和测试两个服务器上了。目前业务一天也就一两笔有问题的。
唉，以后解决就更难了。