## 支付流程設計 以及細節安全 業務場景：一個預定可以首次預定，還可以在預定有效期內對其進行多次續訂。 目標：設計一個高效，友好，安全的支付方案流程。 >[tip] 注意：無論哪種方案，用戶都有可能打開多個窗口，生成多個支付二維碼支付 **需要注意問題：** 1. 數據一致性校驗（防止用戶在過期的界面提交，這樣會造成實際生成的訂單金額等數據可能與用戶在點擊提交前的頁面上看到的不一致，會讓用戶感到困惑） 2. 安全校驗（防止用戶篡改信息，一般是保護訂單等信息不被非法篡改） 3. 并發問題（用戶同時打開多個頁面進行操作，生成多個訂單，造成多支付二維碼重復支付的問題） **安全，防止并發問題需確保：** 1. 保證同一預定同一時刻只能被一個線程進行操作（包括預定下面的資源，訂單等） 2. 每次創建訂單，都會檢查當前預定狀態是否滿足創建訂單，并將名下其他待支付的訂單標記為失效 3. 收到支付回執時檢查預定和訂單的狀態是否分別滿足狀態，以及狀態是否相互吻合，如：預定是否為待支付或生效中（預定待支付時訂單類型應該是預定訂單，預定生效中時訂單類型應該是預定訂單），訂單是否失效了，失效則安排退款等 ***** **方案一：** 1. 獲取價格信息，根據其顯示界面，表單 2. 點擊確認，提交表單生成訂單，根據訂單生成支付二維碼，并返回支付信息 > 選擇價格時不創建訂單，等確認提交時，一次性生成訂單和支付信息 >[tip] 需要注意的地方：以最后生成訂單的時刻為準來做數據校驗 ---- **方案二：** 1. 獲取價格信息，自動創建訂單（每次天數選擇都會自動生成新的訂單） 2. 點擊支付按鈕，根據前次的訂單信息生成支付二維碼 > 選擇價格時就創建訂單，每次返回訂單信息，點擊“提交”按鈕時，根據前次的訂單信息生成支付信息 >[tip] 需要注意的地方： > 1. 提交時檢查訂單是否存在，狀態是否正確，order_id是否被篡改等； > 2. 如果對數據時效性要求高，還需要對數據一致性進行校驗，過期數據，可認為是過期訂單，直接作廢處理，提示用戶頁面過期，引導重新生成訂單。 > 3. 以最后生成支付信息時為準做數據校驗的 ---- **方案三：** 1. 獲取價格信息，自動創建訂單，并根據訂單生成支付二維碼 > 選擇價格時就創建訂單，并根據其訂單信息生成支付信息，一并返回，一步到位沒有其他提交操作，直接就返回支付信息 > 優點：步驟少，快 >[tip] 缺點/缺陷：由于是直接生成了支付信息，所以無法像方案一和方案二那樣做數據過期校驗了，**總不能以收到支付回執時的信息為準來做數據校驗吧**，（通常以最后生成訂單的時刻為準來做數據校驗，方案二例外，是以最后生成支付信息時為準做數據校驗的），所以如果對過期數據有要求的話，就不能采用此方案。（支付信息也有支付有效期的參數，如果對數據過期不是特別苛刻，也可以用這個） ***** ~~~ 預定類型，預定應該是預定成功的第一個訂單，如果不適用預鎖定方式的話，訂單類型不應該是創建時生成，這樣會導致多個預定類型的訂單 除非采用預加鎖的方式，而不是支付回執成功后才加鎖 預加鎖也不能解決這個問題，因為訂單是每次點擊提交都會生成的（同時生成支付信息） 只能在回執時寫入訂單類型了 這樣也還解決不了，別人開多個窗口提交支付，可以繞過系統對于預定次數的限制 所以不能每次點擊提交就同時生成訂單信息和支付信息，這樣不可控 只能獲取價格時生成訂單信息，點擊提交時才根據訂單信息生成支付信息，這樣就可以控制訂單狀態了，使得對于一個預定，同時只能存在一個有效的訂單，而又可以做到不限制用戶可以任意的創建訂單，這樣就從根源上解決了多訂單同時支付的混亂問題了 如果需要做成直接選擇價格后直接就能出來支付信息，而不需要多點擊一下，就可以做個假二維碼讓用戶點一下刷新，刷新時才是根據訂單生成支付信息 ~~~ ~~~ 這樣也還是不能解決用戶同時打開多個支付二維碼支付的問題，只能回執時，檢測到訂單狀態 是關閉取消的狀態，就安排退款，還要檢測預定狀態是否正確 不能徹底解決這個問題，生成新訂單時關閉舊訂單，回執時處理，目前來看算是最合理最直觀的處理方案了 那現在就可以生成支付信息，沒必要再提交一次 不過現在生成支付信息也有個問題，那就是不能校驗舊數據了（這是個何時生成訂單，何時又根據訂單生成支付信息的問題） 如果再次提交時生成支付信息，我們就可以以最后生成支付信息的時候為準來校驗舊數據（其實支付接口也可以設置過期關閉參數） 每種方案都有它的好處和缺陷，具體視情況而定，如果不過分擔心舊數據的情況，可以通過超時關閉支付的來參數控制 如果對舊數據比較嚴格，時間比較精確實時的話，那么就采用最后生成支付信息的一刻校驗數據的方案 ~~~