08:21:01 EagleCheng-兴业银行架构师

有个问题和各位探讨一下,商户给第三方发了一个代付请求,之后商户主动轮询查询该订单状态,极端情况下,订单数据还没落地,查询请求已经到了,这样就会返回订单不存在,一般商户会认为该状态为支付失败。

08:22:59 Bison-拉卡拉北京网络金融部副总

商户加个缓冲时间,过了缓冲时间还是查无此订单,再做相应处理

08:23:52 Bison-拉卡拉北京网络金融部副总

可以定时查,但在缓冲时间内查无订单,忽略,下个定时继续查

08:24:14 华-南京亚软-IT总监

@Eagle-兴业-架构-上海?设置订单状态层级,比如未支付,支付确认中,支付已确认,支付成功

08:24:50 Bison-拉卡拉北京网络金融部副总

这个问题需要商户兼容

08:24:59 Bison-拉卡拉北京网络金融部副总

很多第三方实现方式不同

08:25:05 张泽雄-民生金服 项目总监

返回订单不存在是不对的

08:25:45 华-南京亚软-IT总监

要求商户也做类似层级,比如发起请求时商户订单变成了查询中,这时从你方服务获取的状态是未支付,需要告知商户应该保留查询中状态,因为查询中的状态高于未支付

08:26:08 ibmHuang

多次查询补偿呢

08:28:03 王晗

这种时效性不高,隔几分钟后查,把这种当成处理中状态,多次查询。

08:35:07 EagleCheng-兴业银行架构师

依赖于设置超时间隔时间,在极端情况下还是会出现问题,目前我们就发生一次这种情况。还依赖于第三方和后端的渠道约定的时间,感觉就是个循环依赖

08:44:55 EagleCheng-兴业银行架构师

目前在考虑状态层级,和@付享通_罗华_总监?的思路类似

08:46:00 张泽雄-民生金服 项目总监

根本原因在于你的订单落地性能问题上

08:46:32 张泽雄-民生金服 项目总监

订单落不了地,查询又依赖于库,肯定是查无此订单了

08:50:27 张泽雄-民生金服 项目总监

比如当你有两个RAC时,下单请求落在了A上,查询请求落在了B上,如果A无法及时落地,B节点查询是查不出来的。

09:00:34 袁军-架构师-快捷通

另外,做好幂等性,让商户原订单号重发交易。

09:07:10 张泽雄-民生金服 项目总监

幂等是一个方案,幂等的本质就是以C代Q

10:20:39 yuesheng.yin

以C代Q ?

10:55:55 右军

推荐一个北京的活动,北京的朋友可以选择参加。

10:55:56 右军

ArchData技术峰会北京站

16:57:27 dio

我现在看到早鸟就想到了ico。。。。。群里面有没有专门做区块链支付的产品

17:58:23 龚正-滴滴-支付金融

[糗大了]

17:59:02 龚正-滴滴-支付金融

做一些区块链产品

18:10:30 小强-海航-PM-北京

[强]

18:14:20 田浩沛-银生宝电子支付公司技术总

18:16:06 薛又轩-点融网金融机构总监

牛牛牛

18:53:33 stranger-同城旅游支付PL

大家在拉账单的时候,怎么保证账单在短时间内完全无误的都落库呢?

18:53:46 stranger-同城旅游支付PL

特别数据量教大的,账户多的情况下

21:54:46 田浩沛-银生宝电子支付公司技术总

分批分类,不然真没好办法