鄭昀編纂 基於網絡資料 創建於2015/9/9 最后更新於2015/10/16
關鍵詞：在線支付，異常，重復支付，沖正，out_trade_no
輕點
第一季了解更多知識。特別感謝知乎梁川、天順等知乎網友的精彩答案。
本文檔適用人員：交易領域的產品研發人員
提綱：
- 交易中的異常處理
- 何謂沖正
- 重復支付
電商核心交易流程中，由於涉及的對象較多，如自家的訂單中心、資金帳戶中心、庫存中心、支付中心，第三方支付的接口，銀行，自家的支付網關等等，每個對象都可能處於不可知狀態，網絡消息的投遞也不能保證先后順序，還可能丟包，所以有大量的異常分支需要處理。
0x00，交易中的異常處理
1.1.何謂沖正
我們來看看百度百科上關於沖正的定義：
一筆交易在終端已經置為成功標志，但是發送到主機的帳務交易包沒有得到響應，即終端交易超時，所以不確定該筆交易是否在主機端也成功完成。為了確保用戶的利益，終端重新向主機發送請求，請求取消該筆交易的流水，如果主機端已經交易成功，則回滾交易，否則不處理，然后將處理結果返回給終端。沖正，就為系統認為可能交易失敗時采取的補救手法。
學術上這么解釋也許夠了，但還是不夠嚴謹的，因為沖正交易不光要求對已有交易進行回滾，語義上他還要求應答系統對該交易流水進行冪等控制——
將該交易流水插入冪等表，即便后續該交易報文再抵達，也予以拒絕交易。
如果沒有上面我補充的這段，沖正交易的實現是有邏輯漏洞的。
雖然概率極低，但由於各鏈路節點處理信息的效率不一致，所以也有可能出現沖正交易先抵達目標系統，正常交易晚抵達的情況。如果該目標系統的沖正交易並未作以上邏輯判斷，那就會引起用戶糾紛。
最后，我們來看看沖正交易的使用場景。
通常，目前國內線上支付系統鮮有沖正交易（除非部分快捷支付接口，銀行當時是使用信用卡無磁無密網關包裝出來的，會保留沖正接口），大多數的場景發生在線下。
例如，你去商場購買了一個包包，價值5萬元，刷信用卡消費。
POS機在發送交易報文的時候……不幸掉單了，嗯，就是那么不幸，POS機無論如何收不到來自於收單系統的回執單據。經過漫長的等待，POS機忍不住了，自動給收單系統發了一筆沖正交易……收單行回執，沖正交易處理成功，事件完畢。
這個時候，你會發現服務員又笑眯眯地找你，要你重新刷一下卡……
或許有同學會問，那萬一的沖正交易也掉單了呢……
是的，會有這種奇葩情況，通常系統會對沖正交易重發N次，N次后如果還沒應答就算了，概率太低了，等用戶來投訴吧——
很多時候人工保障比你動腦筋想異常中的異常如何系統自動處理來得反而高效和低成本。
或許還有同學會問，那POS機上的撤銷交易和沖正是什么關系呢？
其實兩個接口的內部實現可以說是類似的，業務場景上，撤銷交易更偏向於由人工發起對原單據的撤銷，可以理解為業務行為；
沖正更類似於系統保障機制，可以不由業務人員感知到，僅此而已。
（出處1）
1.2.重復支付
在線支付對重復支付一般解決方案如下：
1）支付接口判重
第三方支付在接收到支付請求后，根據與商家約定的判定重復支付的參數組合對支付請求進行校驗及判重，如果為重復訂單，則不繼續后續流程。
由於涉及每一次支付請求都需要查詢交易數據，影響系統性能；且由於不同商家的判重標准不盡相同，一般都需要對接口做定制，因此除非是大商戶，一般都不提供此功能。
而且此種方案，並不能杜絕重復支付的問題，例如：用戶開了兩個窗口，都已經跳轉到銀行網銀頁面上，此時侯第三方支付已經無法控制用戶支付行為了。
（鄭昀注：
1. 從電商平台的角度，我們傳給支付寶的
商戶唯一訂單號 out_trade_no，這是第三方支付判重的唯一依據。
2. 用戶可能會連續變更
待付款訂單 的支付方式，如從支付寶切成微信支付，如從支付寶之網銀直連變為支付寶這種第三方支付內部變更，還有可能通過修改購買份數從而變更待付款訂單的應付金額（當然有些情況下電商鎖定訂單，不允許修改），那么，為了保證電商平台能夠識別
支付成功通知 對應於用戶的同一個訂單的哪一次支付行為，我們的 out_trade_no 參數里會包含一個序列號。
我2012年寫的《
電商課題：支付交易一般性准則》里曾經給出過一個例子：
例一：修改訂單，訂單應付金額或支付方式發生變化背景：訂單在沒有支付成功之前，顧客都是可以修改的。做了以下修改后，可能會引起訂單應付金額或支付方式發生變化：
- 余額支付的金額變化
- 購買份數的調整
- 優惠券/代金券的使用
而支付寶等第三方支付，對於一個用 商戶唯一訂單號標識的交易，禁止變更 total_fee（交易總金額）字段！所以，我們的同一個訂單，發起不同應付金額的支付請求時，必須更換 out_trade_no ，流程如下圖4.2所示：
圖4.2 訂單應付金額變化，out_trade_no 必須變化
）
2）重復支付+退款接口
如果重復支付的訂單尚未與第三方支付平台結算，則：
在用戶支付成功后，商戶系統是可以判斷是否為重復支付，商戶系統可以自動調用退款接口，對判定為重復支付的訂單發起退款請求（商戶平台訂單號+支付平台支付流水號）。
也可以由商戶運營人員在運營后台發起退款請求（本質上也是調用退款接口）。
（鄭昀注：電商平台的支付中心必須能夠判定重復支付，並自動發起原路退返。
舉個例子，
10點01分：訂單001，
應付金額10元，用戶選擇支付寶發起支付，out_trade_no=XX_001_0001，用戶登錄支付寶后產生了應付賬單，但未付款；
10點02分：訂單001，用戶修改購買份數，
應付金額變更為5元，用戶選擇支付寶發起支付，out_trade_no=XX_001_0002；
10點03分：用戶把XX_001_0001和XX_001_0002都付款成功了；
10點03分10秒：XX_001_0001的支付成功通知到達。電商平台的支付中心標記該交易支付成功，但因該交易關閉而不再路由給訂單中心，訂單狀態不會發生變化。有專門的定時任務處理這種異常交易，T+N 天后如果用戶仍沒有處理，那么系統會自動發起原路退返，退到用戶支付寶賬戶10元；
10點03分20秒：XX_002_0002的支付成功通知到達。電商平台標記訂單為已付款狀態，同時標記該訂單有重復支付，用戶如果登錄到商城，會收到站內消息通知，個人中心頁面也有提示。
）
3）批量代付退款
如果重復支付的訂單已經與第三方支付平台已經結算（第三方支付與銀行也完成對賬、結算），則：
對在線支付，一般采用批量代付的方案，將重復支付訂單退款與提現、轉賬等業務以批量文件方式提交給代付渠道代付出去。
如果是POS收單，可以采用沖正、消費撤銷、退貨等命令，對重復支付的訂單進行反向交易。在線支付一般較少采用沖正方式。
另外在商戶端，為避免重復支付，在業務邏輯上也可以做一些處理，包括：
1、保證交易訂單號的唯一性。很多商戶系統開發能力有限，經常出現交易訂單號不唯一的情況。
2、在發起支付請求后，更改訂單狀態，避免用戶再次發起支付請求。（慎用，只不過在一些業務場合會也會采用此種方案）。
3、對因掉單等原因引起的訂單狀態未知的情況，先調用第三方支付接口的查詢接口確認訂單的支付狀態。
（出處2）
參考資料：
1，2014，知乎天順的專欄文章，
http://zhuanlan.zhihu.com/workandlife/19861292；
2，2015，知乎梁川的回答，
http://www.zhihu.com/question/36459849/answer/67597515；
-EOF-
更多知識：
電商交易背景知識合集第一季 (2015-09-08 17:42)
歡迎訂閱我的微信訂閱號『老兵筆記』，請掃描二維碼關注：
