总摘要: 订单重复支付
2018-01-18
- 摘要: 订单重复支付.
1. 问个问题，对于支付幂等的接口，当该订单已被退款后，再次支付返回什么结果？是已退款还是已支付? [北京-srtao]
广州-小护士<-> 9:01:23
再次支付肯定是支付失败啦。因为该订单已付过款了
成都-Sêiyǎ(-) 9:03:14
重新生成支付订单嘛
北京-srtao(-) 9:03:19
肯定都不成功的，但是幂等不是要求多次相同请求，会返回相同结果吗，这时应该返回什么状态呢
长沙-艾尔(-) 9:03:47
=。=如果0是下单 1是未支付 2是支付中 3是已支付 那已退款暂且作为4吧- -按理说状态到4了，肯定已经是最终结果了。。肯定不能逆向修改状态了。。
北京-w(-) 9:03:40
订单已退款, 最终一致性，把重复支付的做自动退款, 或者增加 人工审核阶段，把那些问题订单人工核对后 退款
深圳-令狐(-) 9:07:44
有些情况可能造成用户重复支付，比如很晚才收到支付回调
北京-w(-) 9:07:58
主动查询。 不能等客户找上门来 你才退款 ，那样离开除就不远了
北京-alex(-) 9:08:12
哦，支付中的订单也应该有标志的
杭州－东子(-) 9:08:39
第三方根据你传的信息就告诉你，重复支付了……
苏州-winylee(-) 9:10:25
自己系统系统支付中的状态还是知道的啊, 你订单支付 没有返回结果的时候 订单应该是支付中状态
北京-w(-) 9:10:27
你自己流量大的时候呢? 客户端网络原因的情况呢? 上游网络原因呢?
苏州-winylee(-) 9:11:16
你自己的订单状态自己是知道的 , 客服端不知道 你服务肯定知道, 你支付的时候 难道都不做校验的吗？都交给第三方？ 1、2订单合并支付 1、2订单就是支付中，1、2、3在合并支付，你自己应该校验啊 肯定不通过啊
北京-w(-) 9:12:55
我们公司小，没遇到你那种情况. 假设，你送上游返回超时了，条码支付，这时候你状态应该更新成什么？
苏州-winylee(-) 9:14:28
你只要支付了 就是支付中 ，然后是支付完成支付失败
深圳-rubin(-) 9:15:56
支付回调有一定延迟，，多渠道支付可能会重复支付， 可以在回调处做处理
杭州－东子(-) 9:16:19
你在购物车里面勾选了俩个产品，然后点击购买，首先出来一个确认页面，你点击去下单，这时候产生了订单号，你点击去付款这时候产生了支付流水号
深圳-rubin(-) 9:17:18
同一支付号只能支付一次，其余需要退款
北京-alex(-) 9:18:13
你们的订单号和流水号都是要生成器生成的吗？发号机是第三方支付给的？
深圳-rubin(-) 9:19:13
有专门的发号机的， 系统制定的规则
杭州－东子(-) 9:19:24
然后你不去付款，你就可以在我的订单里面看到俩个待付款的，你可以合并付款，也可以单独付款，
这俩个订单号和支付流水号都不同的， 其实在后台是俩个交易, 给用户看是合并的, 所以一个失败了,不影响另一个的
深圳-令狐(-) 9:22:40
接着说下去。比如这时候产生了支付流水号A，用户最终是否支付，要以支付宝或者微信的回调为准。 接下来有两种可能：1：用户并没有支付，订单当前状态是“待付款”。用户在订单列表查到了这笔订单，再次点击了“立即付款”，此时需要重新生成支付流水号B；2：用户对支付流水号A支付了，但是并未收到微信或者支付宝的回调结果。用户在订单列表查到了这笔订单并再次点击“立即付款”，又重新生成了支付流水号。第一种情况是正常的，第二种情况就会造成重复支付
杭州－东子(-) 9:23:46
不会生成b的， a又没失败，状态还是待支付，你一个支付流水信息在你的系统中最终状态只有失败成功， 待支付的一直不支付，一定时间之后，你也要定时任务跑批改成失败
深圳-rubin(-) 9:24:51
是的，需要等待A的回调，，当然你也可以主动去轮训第三方获取结果， 如果你要把A设置为支付失败，你需要去轮训第三方的
杭州－东子(-) 9:25:51
你用用户不支付他就不会用新的， 你如果点了支付，密码也输入了，那这个支付状态就是支付中，或者叫做去支付，他的下一个状态就是失败或者成功
北京-空城(-) 9:27:10
卡死呢
深圳-rubin(-) 9:27:25
其实不用怕的，上几个月，出问题再找补救方案
杭州－东子(-) 9:27:30
这个状态只能查询第三方支付信息得知，支付中的讲道理页面就没有支付按钮了
深圳-令狐(-) 9:28:37
问题就在这里。业务系统和第三方支付的超时未支付自动关闭时间是不一致的。这就是为什么每次点击“立即付款”的时候，都需要重新生成
杭州－东子(-) 9:28:57
你要想重新就要在发起新的订单了
北京-w(-) 9:29:29
先取消原订单吧。
杭州－东子(-) 9:30:31
你用第三方的东西，他没办法迁就你的，你就迁就他一下，超时比他晚点，关闭之前拿着信息再去查一遍他， 毕竟第三方提供了查询支付成功失败的接口
深圳-rubin(-) 9:31:07
如果是在支付中-->轮训第三方-->获取第三方结果为处理中-->该支付单还是为支付中
如果是在支付中-->轮训第三方-->获取第三方结果为支付成功-->该支付单还是为支付成功
如果是在支付中-->轮训第三方-->获取第三方结果为支付失败-->该支付单还是为支付失败
北京-w(-) 9:31:16
有一种好像是，超多多长时间轮询之后，掉取消接口，取消成功 则订单关闭 设定支付失败
北京-alex(-) 9:35:45
@杭州－东子 支付流水号是自己生成还是支付机构给的
杭州－东子(-) 9:35:59
你自己系统的，你服务拆分，你有个订单服务，根据你们自己规则生成了订单号，你还有个支付服务，也是一个模块，专门做各种对接第三方支付的，这个系统自己的规则生成的流水号
深圳-令狐(-) 9:37:18
@杭州－东子 你倒是提醒我了，这个接口我们都没用过。 仔细想了一下，用上这个接口，业务系统会更加完善
杭州－东子(-) 9:37:28
第三方支付的那个号他也有个流水号
北京-alex(-) 9:39:12
哦，那订单里面的支付流水号显示的应该是自己生成的，不是银行的流水号， 接支付宝的流程和银行有啥区别？
杭州－东子(-) 9:40:47
接口api不同，数据库字段不同，能共用的少一些，流程上都差不多
北京-w(-) 9:41:04
支付机构不允许直接接入支付宝 只允许银行间联，商城可以自己接入支付宝
北京-alex(-) 9:42:22
回调流程和查询功能在设计上大同小异？【是的】
杭州－东子(-) 9:42:59
一般你的订单号做的有意义一些，可以包括订单时间，类型，支付方式，配送方式，每几位代表不同的
杭州－东子(-) 9:43:11
退款啥的都差不多的感觉
深圳-rubin(-) 9:43:52
退款的不一样。。。很多支付渠道的退款流程 查询第三方的退款情况都不准确
