總摘要: 訂單重復(fù)支付
2018-01-18
- 摘要: 訂單重復(fù)支付.
1. 問個問題，對于支付冪等的接口，當(dāng)該訂單已被退款后，再次支付返回什么結(jié)果？是已退款還是已支付? [北京-srtao]
廣州-小護士<-> 9:01:23
再次支付肯定是支付失敗啦。因為該訂單已付過款了
成都-Sêiyǎ(-) 9:03:14
重新生成支付訂單嘛
北京-srtao(-) 9:03:19
肯定都不成功的，但是冪等不是要求多次相同請求，會返回相同結(jié)果嗎，這時應(yīng)該返回什么狀態(tài)呢
長沙-艾爾(-) 9:03:47
=。=如果0是下單 1是未支付 2是支付中 3是已支付 那已退款暫且作為4吧- -按理說狀態(tài)到4了，肯定已經(jīng)是最終結(jié)果了。?？隙ú荒苣嫦蛐薷臓顟B(tài)了。。
北京-w(-) 9:03:40
訂單已退款, 最終一致性，把重復(fù)支付的做自動退款, 或者增加 人工審核階段，把那些問題訂單人工核對后 退款
深圳-令狐(-) 9:07:44
有些情況可能造成用戶重復(fù)支付，比如很晚才收到支付回調(diào)
北京-w(-) 9:07:58
主動查詢。 不能等客戶找上門來 你才退款 ，那樣離開除就不遠(yuǎn)了
北京-alex(-) 9:08:12
哦，支付中的訂單也應(yīng)該有標(biāo)志的
杭州－東子(-) 9:08:39
第三方根據(jù)你傳的信息就告訴你，重復(fù)支付了……
蘇州-winylee(-) 9:10:25
自己系統(tǒng)系統(tǒng)支付中的狀態(tài)還是知道的啊, 你訂單支付 沒有返回結(jié)果的時候 訂單應(yīng)該是支付中狀態(tài)
北京-w(-) 9:10:27
你自己流量大的時候呢? 客戶端網(wǎng)絡(luò)原因的情況呢? 上游網(wǎng)絡(luò)原因呢?
蘇州-winylee(-) 9:11:16
你自己的訂單狀態(tài)自己是知道的 , 客服端不知道 你服務(wù)肯定知道, 你支付的時候 難道都不做校驗的嗎？都交給第三方？ 1、2訂單合并支付 1、2訂單就是支付中，1、2、3在合并支付，你自己應(yīng)該校驗啊 肯定不通過啊
北京-w(-) 9:12:55
我們公司小，沒遇到你那種情況. 假設(shè)，你送上游返回超時了，條碼支付，這時候你狀態(tài)應(yīng)該更新成什么？
蘇州-winylee(-) 9:14:28
你只要支付了 就是支付中 ，然后是支付完成支付失敗
深圳-rubin(-) 9:15:56
支付回調(diào)有一定延遲，，多渠道支付可能會重復(fù)支付， 可以在回調(diào)處做處理
杭州－東子(-) 9:16:19
你在購物車?yán)锩婀催x了倆個產(chǎn)品，然后點擊購買，首先出來一個確認(rèn)頁面，你點擊去下單，這時候產(chǎn)生了訂單號，你點擊去付款這時候產(chǎn)生了支付流水號
深圳-rubin(-) 9:17:18
同一支付號只能支付一次，其余需要退款
北京-alex(-) 9:18:13
你們的訂單號和流水號都是要生成器生成的嗎？發(fā)號機是第三方支付給的？
深圳-rubin(-) 9:19:13
有專門的發(fā)號機的， 系統(tǒng)制定的規(guī)則
杭州－東子(-) 9:19:24
然后你不去付款，你就可以在我的訂單里面看到倆個待付款的，你可以合并付款，也可以單獨付款，
這倆個訂單號和支付流水號都不同的， 其實在后臺是倆個交易, 給用戶看是合并的, 所以一個失敗了,不影響另一個的
深圳-令狐(-) 9:22:40
接著說下去。比如這時候產(chǎn)生了支付流水號A，用戶最終是否支付，要以支付寶或者微信的回調(diào)為準(zhǔn)。 接下來有兩種可能：1：用戶并沒有支付，訂單當(dāng)前狀態(tài)是“待付款”。用戶在訂單列表查到了這筆訂單，再次點擊了“立即付款”，此時需要重新生成支付流水號B；2：用戶對支付流水號A支付了，但是并未收到微信或者支付寶的回調(diào)結(jié)果。用戶在訂單列表查到了這筆訂單并再次點擊“立即付款”，又重新生成了支付流水號。第一種情況是正常的，第二種情況就會造成重復(fù)支付
杭州－東子(-) 9:23:46
不會生成b的， a又沒失敗，狀態(tài)還是待支付，你一個支付流水信息在你的系統(tǒng)中最終狀態(tài)只有失敗成功， 待支付的一直不支付，一定時間之后，你也要定時任務(wù)跑批改成失敗
深圳-rubin(-) 9:24:51
是的，需要等待A的回調(diào)，，當(dāng)然你也可以主動去輪訓(xùn)第三方獲取結(jié)果， 如果你要把A設(shè)置為支付失敗，你需要去輪訓(xùn)第三方的
杭州－東子(-) 9:25:51
你用用戶不支付他就不會用新的， 你如果點了支付，密碼也輸入了，那這個支付狀態(tài)就是支付中，或者叫做去支付，他的下一個狀態(tài)就是失敗或者成功
北京-空城(-) 9:27:10
卡死呢
深圳-rubin(-) 9:27:25
其實不用怕的，上幾個月，出問題再找補救方案
杭州－東子(-) 9:27:30
這個狀態(tài)只能查詢第三方支付信息得知，支付中的講道理頁面就沒有支付按鈕了
深圳-令狐(-) 9:28:37
問題就在這里。業(yè)務(wù)系統(tǒng)和第三方支付的超時未支付自動關(guān)閉時間是不一致的。這就是為什么每次點擊“立即付款”的時候，都需要重新生成
杭州－東子(-) 9:28:57
你要想重新就要在發(fā)起新的訂單了
北京-w(-) 9:29:29
先取消原訂單吧。
杭州－東子(-) 9:30:31
你用第三方的東西，他沒辦法遷就你的，你就遷就他一下，超時比他晚點，關(guān)閉之前拿著信息再去查一遍他， 畢竟第三方提供了查詢支付成功失敗的接口
深圳-rubin(-) 9:31:07
如果是在支付中-->輪訓(xùn)第三方-->獲取第三方結(jié)果為處理中-->該支付單還是為支付中
如果是在支付中-->輪訓(xùn)第三方-->獲取第三方結(jié)果為支付成功-->該支付單還是為支付成功
如果是在支付中-->輪訓(xùn)第三方-->獲取第三方結(jié)果為支付失敗-->該支付單還是為支付失敗
北京-w(-) 9:31:16
有一種好像是，超多多長時間輪詢之后，掉取消接口，取消成功 則訂單關(guān)閉 設(shè)定支付失敗
北京-alex(-) 9:35:45
@杭州－東子 支付流水號是自己生成還是支付機構(gòu)給的
杭州－東子(-) 9:35:59
你自己系統(tǒng)的，你服務(wù)拆分，你有個訂單服務(wù)，根據(jù)你們自己規(guī)則生成了訂單號，你還有個支付服務(wù)，也是一個模塊，專門做各種對接第三方支付的，這個系統(tǒng)自己的規(guī)則生成的流水號
深圳-令狐(-) 9:37:18
@杭州－東子 你倒是提醒我了，這個接口我們都沒用過。 仔細(xì)想了一下，用上這個接口，業(yè)務(wù)系統(tǒng)會更加完善
杭州－東子(-) 9:37:28
第三方支付的那個號他也有個流水號
北京-alex(-) 9:39:12
哦，那訂單里面的支付流水號顯示的應(yīng)該是自己生成的，不是銀行的流水號， 接支付寶的流程和銀行有啥區(qū)別？
杭州－東子(-) 9:40:47
接口api不同，數(shù)據(jù)庫字段不同，能共用的少一些，流程上都差不多
北京-w(-) 9:41:04
支付機構(gòu)不允許直接接入支付寶 只允許銀行間聯(lián)，商城可以自己接入支付寶
北京-alex(-) 9:42:22
回調(diào)流程和查詢功能在設(shè)計上大同小異？【是的】
杭州－東子(-) 9:42:59
一般你的訂單號做的有意義一些，可以包括訂單時間，類型，支付方式，配送方式，每幾位代表不同的
杭州－東子(-) 9:43:11
退款啥的都差不多的感覺
深圳-rubin(-) 9:43:52
退款的不一樣。。。很多支付渠道的退款流程 查詢第三方的退款情況都不準(zhǔn)確
