支付寶接口回調處理問題？

網站集成支付寶接口進行訂單支付和會員餘額充值，訂單支付因為提前生成有訂單沒什麼疑問，但我做餘額充值的時候，提交請求到支付寶的這個時候，要不要把生成的訂單請求數據先存入資料庫，然後在支付寶的回調return和notify中進行訂單處理，改變會員餘額，但這樣的話如果會員提交充值，沒有完成支付的話，會產生很多無用的單。

如果是會員提交請求的時候，不存訂單信息，直接在回調同步異步函數中判斷支付成功，存充值記錄和改會員餘額，這樣有沒有安全隱患，我看了支付寶的接口文檔，“商戶需要驗證該通知資料中的out_trade_no是否為商家系統中建立的訂單號，並判斷total_fee是否確實為該訂單的實際金額（即商家訂單建立時的金額）」這樣的話我就做不了這樣的操作，

請做過的大神給個意見，非常感謝！ ！ ！

回覆內容：

網站集成支付寶接口進行訂單支付和會員餘額充值，訂單支付因為提前生成有訂單沒什麼疑問，但我做餘額充值的時候，提交請求到支付寶的這個時候，要不要把生成的訂單請求數據先存入資料庫，然後在支付寶的回調return和notify中進行訂單處理，改變會員餘額，但這樣的話如果會員提交充值，沒有完成支付的話，會產生很多無用的單。

如果是會員提交請求的時候，不存訂單信息，直接在回調同步異步函數中判斷支付成功，存充值記錄和改會員餘額，這樣有沒有安全隱患，我看了支付寶的接口文檔，“商戶需要驗證該通知資料中的out_trade_no是否為商家系統中建立的訂單號，並判斷total_fee是否確實為該訂單的實際金額（即商家訂單建立時的金額）」這樣的話我就做不了這樣的操作，

請做過的大神給個意見，非常感謝！ ！ ！

當然要提交時就保存訂單, 那幾筆"無用"的單難道比可靠性更重要么

額外舉一個好處, 你們還可以根據你認為的"無用"的單和實際支付的單的比例來看這個支付的流失率, 為支付流程優化做準備和參考數據

你開始的方案是正確的