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

TCP 抗丢包, 业务流程加双向确认

此外支付本身应该在确认交易后再开始, 吞钱这种事最开始就不应该出现

#2 不对这个和客户端无关

@vcn8yjOogEL 不太行， 双向确认的话中间等待时长不确定。时间太长的话客户会着急。之前做过一版两分钟的等待，窗口的收费人员和客户都反馈不满意，时间太长了。

我打算节后跟另外的那个程序的人练一练，他不改我就让窗口等着。看谁先受不了。

哎~~这年头

发起支付的一方产生一个 ID 之类的号，发起支付时传给支付服务。
支付服务判断这个 ID 对于这个请求方是否已存在，存在就返回支付状态。

支付完之后，指数退避去查状态，设置一个几分钟的最大上限就可以了。或者从业务逻辑去看有没有让整个交易重入的办法，用同一个订单号去对方支付系统里重试支付。

@vcn8yjOogEL 已经确认交易了，但在交易过程中支付成功，支付成功状态回传失败（中间丢包了）。然后业务就会认为失败。
因为我们和客户端的不是同一家，所以说这个很蛋疼。
上支付平台的时候他们已经改过一次了，直接从客户端掉我们的支付程序，然后再返给他成功状态（之前公司都是这么干的）。
我目前想到了一个办法，就是我这里加一个等待，然后让对方做一个支付回查接口和一个支付状态修改的接口。对方失败之后直接改他的支付状态。然后再让他的窗口程序加一个重试按钮，回查他自己的支付表。但窗口人员点了取消，或者直接把程序结束了，钱还是会长帐。
并且我对他们的程序员的技术表示迟疑态度，他们干过太多匪夷所思的事了，真是老天爷赏饭吃。

@pagxir
@ZZ74
@hallDrawnel
不行不能这么干，支付宝小程序已经发生过类似的事了，不知道他们是怎么写的程序，并发量一大。就变成了支付成功对方也认为支付成功，但业务状态回查一直是支付中。然后超时就退款了。过一阵他们自己又成功了。
现在就是支付宝小程序支付的时间就硬等 30 秒。
但窗口排队的人多呀，弄不好就客户就急眼了。

这系统能要到钱也是奇迹

客户端向服务端同时发起三个请求，任意一个请求成功了就认为成功了……
服务端向客户端下发支付成功消息，发三遍，收到任意一个消息就认为成功了……
三个请求都发生丢包的概率 = 5%^3 = 十万分之 125……

@ccde8259 不行，丢包有一定的连续性，并且 5%只是我那一天监控网络的时候的数值不具有太大的参考性。上上周有一个客户 20 分钟连着支付了三次都没成功，最后付的现金。他没急眼我都惊呆了。
还有一个在周五半夜付了一千多块钱然后失败了的，周一下午才退。他中间没找过来闹也是个奇迹。

@xiangyuecn 业务系统不是我们的，老天爷赏饭吃你能有什么办法。我头发都要掉光了，终于明白什么叫做甲方爸爸了。

那么你愿意出多少钱买思路呢？

@dongpengfei1 设备网络能不能换，比如搞个啥 5G CPE 专门跑这个业务……其实相当于拉专线把高优先级业务跟低优先级业务隔离开来

没看懂

@ccde8259 换不了，窗口是纯内网电脑，并且我们这里的服务端也是个屎山。单独的支付代码拆不出来，要是能拆开的话我直接在另外一边部署上就 ok 了。

重试

我之前做过差不多的情景，之前是客户支付成功后等待支付系统给我一个支付结果的回调，但是不知道是回调的问题还是我后端的问题，有出现用户说支付成功了但是我没收到回调的情况，然后手动向支付系统发起查询确认这个交易状态才知道已经成功。后来我就写成双向确认，客户端支付成功缓存结果并向我后台发送一个支付成功的通知，支付系统也给我一个通知。如果支付系统确认成功就是成功，如果出现客户端显示成功但是没收到支付系统的回调，则等待多少秒后主动向支付系统查询交易状态，这样之后就没出现状况了。

为保证支付成功率，流程中应该允许重复支付的存在。可以在收款回调流程判断是否存在同一订单多次收单的情况，进行自动退款即可。不一定需要依赖第二天的财务对账才能知道长款。

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

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

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

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

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

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

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