这是一个创建于 338 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近做了一个支付平台，在每个窗口部署可以二维码和银行卡支付。但窗口和服务器之间一天会有 5%的丢包率。 总会造成支付成功然后就丢包了，业务失败。每天的长帐不少，客户需要重新付一笔钱，转天财务对长帐才会退回。客户的满意度也非常低。 网络问题排查不出来，因为窗口的其他程序请求和服务器同网段的另外一台服务器一点问题没有。
有没有哪位大佬能给一个思路的。
我目前想到的是把支付信息传给另外一台服务器的程序，然后再通过它调用我的支付平台，成功与否在进行业务判断。但这个动静太大。另一方不愿意做。
另外一个方法是，我直接判断业务没有成功，就会退款，但有可能是业务的中间状态我就给退了。这样有很大可能造成短帐。这个月因为其它原因已经短帐好几次了，实在受不了把它变成一个长期的问题。找客户要钱也是个麻烦事。客户不给就得自己垫钱了。
 |
1
vcn8yjOogEL 338 天前  2
TCP 抗丢包, 业务流程加双向确认
|
|
2
vcn8yjOogEL 338 天前
此外支付本身应该在确认交易后再开始, 吞钱这种事最开始就不应该出现
|
|
3
vcn8yjOogEL 338 天前
#2 不对这个和客户端无关
|
 |
4
dongpengfei1 OP @vcn8yjOogEL 不太行， 双向确认的话中间等待时长不确定。时间太长的话客户会着急。之前做过一版两分钟的等待，窗口的收费人员和客户都反馈不满意，时间太长了。
我打算节后跟另外的那个程序的人练一练，他不改我就让窗口等着。看谁先受不了。 |
 |
5
pagxir 338 天前 via Android
业务失败的时候，不能发起冲正么
|
 |
6
ZZ74 338 天前 1
哎~~这年头
发起支付的一方产生一个 ID 之类的号，发起支付时传给支付服务。 支付服务判断这个 ID 对于这个请求方是否已存在，存在就返回支付状态。 |
 |
7
hallDrawnel 338 天前
支付完之后，指数退避去查状态，设置一个几分钟的最大上限就可以了。或者从业务逻辑去看有没有让整个交易重入的办法，用同一个订单号去对方支付系统里重试支付。
|
|
8
dongpengfei1 OP @vcn8yjOogEL 已经确认交易了，但在交易过程中支付成功，支付成功状态回传失败（中间丢包了）。然后业务就会认为失败。
因为我们和客户端的不是同一家，所以说这个很蛋疼。 上支付平台的时候他们已经改过一次了，直接从客户端掉我们的支付程序，然后再返给他成功状态（之前公司都是这么干的）。 我目前想到了一个办法，就是我这里加一个等待，然后让对方做一个支付回查接口和一个支付状态修改的接口。对方失败之后直接改他的支付状态。然后再让他的窗口程序加一个重试按钮，回查他自己的支付表。但窗口人员点了取消，或者直接把程序结束了，钱还是会长帐。 并且我对他们的程序员的技术表示迟疑态度，他们干过太多匪夷所思的事了，真是老天爷赏饭吃。 |
|
9
dongpengfei1 OP @pagxir
@ZZ74 @hallDrawnel 不行不能这么干，支付宝小程序已经发生过类似的事了，不知道他们是怎么写的程序，并发量一大。就变成了支付成功对方也认为支付成功，但业务状态回查一直是支付中。然后超时就退款了。过一阵他们自己又成功了。 现在就是支付宝小程序支付的时间就硬等 30 秒。 但窗口排队的人多呀，弄不好就客户就急眼了。 |
 |
10
xiangyuecn 338 天前
这系统能要到钱也是奇迹😂
|
 |
11
ccde8259 338 天前
客户端向服务端同时发起三个请求，任意一个请求成功了就认为成功了……
服务端向客户端下发支付成功消息，发三遍，收到任意一个消息就认为成功了…… 三个请求都发生丢包的概率 = 5%^3 = 十万分之 125…… |
|
12
dongpengfei1 OP @ccde8259 不行，丢包有一定的连续性，并且 5%只是我那一天监控网络的时候的数值不具有太大的参考性。上上周有一个客户 20 分钟连着支付了三次都没成功，最后付的现金。他没急眼我都惊呆了。
还有一个在周五半夜付了一千多块钱然后失败了的，周一下午才退。他中间没找过来闹也是个奇迹。 |
|
13
dongpengfei1 OP @xiangyuecn 业务系统不是我们的，老天爷赏饭吃你能有什么办法。我头发都要掉光了，终于明白什么叫做甲方爸爸了。
|
 |
14
lance6716 338 天前 via Android
那么你愿意出多少钱买思路呢？
|
|
15
ccde8259 338 天前
@dongpengfei1 设备网络能不能换，比如搞个啥 5G CPE 专门跑这个业务……其实相当于拉专线把高优先级业务跟低优先级业务隔离开来
|
 |
16
chenqh 338 天前
没看懂
|
|
17
dongpengfei1 OP @ccde8259 换不了，窗口是纯内网电脑，并且我们这里的服务端也是个屎山。单独的支付代码拆不出来，要是能拆开的话我直接在另外一边部署上就 ok 了。
|
 |
18
devliu1 338 天前 via Android
重试
|
 |
19
esee 338 天前 1
我之前做过差不多的情景，之前是客户支付成功后等待支付系统给我一个支付结果的回调，但是不知道是回调的问题还是我后端的问题，有出现用户说支付成功了但是我没收到回调的情况，然后手动向支付系统发起查询确认这个交易状态才知道已经成功。后来我就写成双向确认，客户端支付成功缓存结果并向我后台发送一个支付成功的通知，支付系统也给我一个通知。如果支付系统确认成功就是成功，如果出现客户端显示成功但是没收到支付系统的回调，则等待多少秒后主动向支付系统查询交易状态，这样之后就没出现过状况了。
|
 |
20
GoodAfternoon 338 天前
为保证支付成功率，流程中应该允许重复支付的存在。可以在收款回调流程判断是否存在同一订单多次收单的情况，进行自动退款即可。不一定需要依赖第二天的财务对账才能知道长款。
|
|
21
dongpengfei1 OP @esee 业务系统不是我们的，甲方接入支付平台的时候，找业务系统那边加支付选项的时候，他们硬是做了一个月。结果还是有部分支付页面没有调用我们。
我都好了奇了，这种不应该是在支付列表里面写好配置好，加了选项就能用的东西吗？为什么要一个页面做一个支付接口。 节后肯定要和他们 batlle 一下。让他们把双向确认的接口加上。 |
|
22
dongpengfei1 OP @GoodAfternoon 业务系统那边做不到 /(ㄒoㄒ)/~~
他们的代码实在太烂了。他们给我的接口信息只有订单号，钱数，支付状态（还是他掉我写的客户端的 dll 给他返的），收费员编号，客户信息。 客户信息还是我因为对账催了一个星期，才把之前小程序支付的时候本来就有的信息给加上的。就两个列，客户信息他竟然加了一个星期，你能想象的到吗？ 最早长帐的时候财务只能把这些长帐原路退回，但不知道退回了那些客户。然后中间短帐了，我还是找他们要的日志，一点一点的对出来的客户信息。我这边根本不知道是谁支付了这笔钱。 他们根本就不按照你的 api 手册去做。 妈的，节后肯定要和他们练练不是他死就是我活。 而且我们的屎山也非常的大。 你有见过流水线式的代码吗？不面向对象也就算了，至少也得面向函数吧。他写了流水线式的代码。还不敢动，影响了好几家公司的业务。弄不好就是罪过，每当加功能的时候我都害怕。一个系统配置文件走了仨（谁能相信，改了其中一个配置文件不好使，得改其它配置文件的相同的选项）。 要不是合适工作不好找早跑路了，这干的是要人命的活。 |
 |
23
julyclyde 336 天前
你这 5%也太高了点……
如果你的业务真的很严肃，应该改一下线路 如果是垃圾业务就忍了吧 |
|
24
dongpengfei1 OP @julyclyde 我是给甲方干的人家说自己的网没问题，并且在其它同网段的服务器也没问题。只有我的这个支付平台有问题。
|
|
25
dongpengfei1 OP 朋友们，没打过，业务方不肯改，甲方也不配合。还是从拖着等甲方去查他们的网络吧。
|
|
26
julyclyde 334 天前
@dongpengfei1 同网段其他也没问题？？？
|
|
27
dongpengfei1 OP @julyclyde 对，同网段其他的服务器就没问题。他这个是分两个区域，之间是专线连接。服务器所在的区一点问题没有。
找甲方，他就不认。就说为什么同一个网段同一个机架上的其他服务器就没事。我都无语了。 他们网络知识也没有，拓补图也不给。 这个就是他们专线之间防火墙的事。弄的我把客户端分别连到正式和测试两个服务器上了。目前业务一天也就一两笔有问题的。 唉，以后解决就更难了。 |
Select Language