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 田浩沛-银生宝电子支付公司技术总
分批分类,不然真没好办法