但是 回首 scan 一次 上線 失敗 通過 們的 詳細

項目中用到了支付功能，采用的是ping++實現的，上線運行一年多都很正常，但是最近突然出現有買家反映說不能進行支付的情況 通過了解和溝通之後發現發現是重復拉起失敗，然後我們對問題進行了排查。 測試過程中我們的測試機重復拉起不管是支付寶還是微信都很正常，發生了很奇怪的問題。 於是對ping++的通過各種渠道對ping++訂單號的規則做了詳細的了解，總結結果如下： 一、非微信類渠道： ①、首次請求 Ping++ 返回的 Charge 對象，在接下來的 1 分鐘內如果請求上來還是相同的訂單信息（ 6 要素不要變更，order_no、channel、amount、subject、body、appid） 那麽 Ping++ 還是返回首次請求的 Charge ； 註：如果在 1 分鐘之內，使用支付寶渠道花唄分期時，更換了 extra 的 hb_fq_num 參數和 hb_fq_seller_percent 參數或者其中之一，則會返回全新的 Charge 。 ②、如果超過 1 分鐘，再次請求 Ping++ 則返回全新的 Charge 。 ③、線下掃碼通道：isv_qr / isv_scan 渠道，超過 1 分鐘後，不可用相同的訂單信息發起創建請求；isv_wap 渠道在打開鏈接後，再超過 1 分鐘後，不可用相同的訂單信息發起創建請求，若未打開鏈接，則參考 ①、② 步驟說明。 二、微信類渠道： 對於微信相同的訂單號請求，Ping++ 這裏是做了2個小時的緩存處理，也就是說在2個小時內，只要是相同信息的訂單請求，Ping++ 返回給您的是我們緩存你第一次請求拿到的 Charge 的信息（註意2小時內是要相同的訂單信息, 6 要素不要變更，order_no、channel、amount、subject、body、appid）； 超過2小時的話，即使用相同的訂單信息，訂單號相同，我們也都是直接去請求微信的，那麽微信這裏就會報錯，因為微信不允許相同訂單號的請求。 註：order_no 在微信同一個商戶號下必須唯一；如：微信公眾號和微信公眾號掃碼渠道是屬於同一個商戶號下的，則不可使用相同的 order_no 創建支付請求。 了解之後發現，買家的訂單其實是被賣家修改過價格的，所謂訂單信息不同，所以請求微信，導致拉起失敗不能進行付款 知道原因之後我們就可以進行修改了，原則上只要訂單號不同就可以了，有如下方案： 1.賣家修改價格的時候重新生成訂單號，對之前的訂單進行修改 2.每次發起支付的時候重新生成訂單，對之前訂單進行修改 3.每次發起支付的時候通過一定規則增加隨機後綴或前綴保證訂單的唯一性，在回調中進行相應的處理進行訂單號還原 通過思考發現，1和2方案的操作成本較高，而且可能會對之前的代碼造成影響，於是了我們采用3方案進行解決 By Hgq

ping++微信渠道，第二次拉起不能進行支付返回訂單號重復問題