支付訂單的預創建方法及裝置與流程

2023-04-29 22:56:41

本申請涉及網際網路支付領域，尤其涉及一種支付訂單的預創建方法及裝置。
背景技術：
：傳統技術中，支付系統在根據商戶系統發送的訂單創建請求，創建預支付訂單後，將該預支付訂單存儲在緩存中。在對上述預支付訂單執行相應的操作(如，支付結果處理或者關閉)之後，當預支付訂單處於終態時，將預支付訂單更新為正式支付訂單，並將正式支付訂單存儲在資料庫中。然而，由於緩存為非持久性存儲，存在斷電丟失和老數據被新數據替換的可能，因此上述方法會存在預支付訂單丟失的問題。此外，上述方法中向緩存中存儲數據與向資料庫中存儲數據為兩種完全不同的方案，需要通過兩套完全不同的邏輯來實現，這增加了設計成本和設計複雜度。技術實現要素：本申請描述了一種支付訂單的預創建方法及裝置，可以提高創建的支付訂單的可靠性。第一方面，提供了一種支付訂單的預創建方法，包括：接收商戶系統發送的訂單創建請求，所述訂單創建請求包括訂單數據；根據所述訂單數據，生成預支付訂單，所述預支付訂單包含第一訂單號，所述第一訂單號是優先根據買家用戶標識確定的；將所述預支付訂單存儲在第一資料庫中；當滿足預設的數據同步條件時，將所述第一資料庫中的預支付訂單同步至第二資料庫中。第二方面，提供了一種支付訂單的預創建裝置，包括：接收單元，用於接收商戶系統發送的訂單創建請求，所述訂單創建請求包括訂單數據；生成單元，用於根據所述接收單元接收的所述訂單數據，生成預支付訂單，所述預支付訂單包含第一訂單號，所述第一訂單號是優先根據買家用戶標識確定的；存儲單元，用於將所述生成單元生成的所述預支付訂單存儲在第一資料庫中；同步單元，用於當滿足預設的數據同步條件時，將所述第一資料庫中的預支付訂單同步至第二資料庫中。本申請提供的支付訂單的預創建方法及裝置，支付系統在接收到商戶系統發送的訂單創建請求時，創建相應的預支付訂單，並將該預支付訂單存儲在第一資料庫中。之後，當滿足預設的數據同步條件時，將第一資料庫中的預支付訂單同步至第二資料庫中。也即本申請中，在創建預支付訂單之後，將該預支付訂單存儲在第一資料庫中，從而可以避免傳統技術中，將預支付訂單存儲在緩存中而可能會造成預支付訂單丟失的問題。此外，在同步前後，預支付訂單都是存儲在資料庫中的，也即可以通過相同的邏輯來實現同步前後預支付訂單的操作，從而可以降低設計成本以及複雜度。附圖說明為了更清楚地說明本發明實施例的技術方案，下面將對實施例描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本發明的一些實施例，對於本領域普通技術人員來講，在不付出創造性勞動的前提下，還可以根據這些附圖獲得其它的附圖。圖1為本申請提供的支付訂單的預創建方法的應用場景示意圖；圖2本申請一種實施例提供的支付訂單的預創建方法流程圖；圖3為本申請提供的預支付訂單的同步方法流程圖；圖4為本申請提供的預支付訂單的操作流程圖；圖5為本申請另一種實施例提供的支付訂單的預創建裝置示意圖。具體實施方式下面結合附圖，對本申請的實施例進行描述。圖1為本申請提供的支付訂單的預創建方法的應用場景示意圖，圖1中，商戶系統(如，淘寶網、天貓等)可以接收用戶的下單請求，並根據該下單請求，生成相應的訂單數據。其中，該訂單數據可以包括：商戶標識(identifier，id)、商戶訂單號、商品信息以及交易金額等。此外，該訂單數據還可以包括買家用戶標識(簡稱：買家id)等。商戶系統在生成相應的訂單數據之後，可以向支付系統(如，支付寶等)發送訂單創建請求，該訂單創建請求可以包括上述訂單數據。支付系統在接收到訂單數據之後，可以根據訂單數據，生成預支付訂單。具體地，當訂單數據包括買家id時，支付系統可以先根據買家id確定第一訂單號，之後再根據第一訂單號和訂單數據生成預支付訂單；當訂單數據不包括買家id時，支付系統可以先根據預設的用戶標識確定第一訂單號，之後再根據第一訂單號、預設的用戶標識以及訂單數據生成預支付訂單。可以理解的是，本申請的預支付訂單包含的第一訂單號可以是根據買家用戶標識確定，也可以是根據預設的用戶標識確定。因為預設的用戶標識並非是實際的買家用戶標識，所以將上述過程中生成的支付訂單稱為「預支付訂單」，上述第一訂單號可以稱為「預支付訂單號」。圖1中，支付系統在生成預支付訂單之後，可以將該預支付訂單存儲在第一資料庫(也稱預創建庫)中。在對上述預支付訂單執行相應的操作(如，支付結果處理或者關閉)之後，當預支付訂單處於終態時，將預支付訂單同步至第二資料庫(也稱正式庫)中。此處，第一資料庫和第二資料庫可以具有相同的表結構，也即該兩個資料庫可以具有相同的欄位內容，從而本申請可以通過相同的邏輯來實現向不同的資料庫中存儲預支付訂單，由此，可以降低設計成本以及複雜度。圖2本申請一種實施例提供的支付訂單的預創建方法流程圖。所述方法的執行主體可以為具有處理能力的設備：伺服器或者系統或者裝置，如，圖1中的支付系統，如圖2所示，所述方法具體包括：步驟210，接收商戶系統發送的訂單創建請求。此處的商戶系統可以是指任一可以購買商品的電子商務網站，如，淘寶網或者天貓等。具體地，用戶可以通過商戶系統瀏覽商品，並執行下單操作。在接收到用戶執行下單操作的操作指令時，商戶系統可以生成訂單數據。該訂單數據可以包括：商戶id、商戶訂單號、商品信息以及交易金額等。此外，在用戶已登錄支付系統的情況下，該訂單數據還可以包括買家用戶標識(簡稱：買家id)等。在生成訂單數據之後，商戶系統可以向支付系統發送訂單創建請求。該訂單創建請求可以包括上述訂單數據。步驟220，根據訂單數據，生成預支付訂單。此處的預支付訂單可以包含第一訂單號，其中，第一訂單號是優先根據買家用戶標識確定的。支付系統在接收到商戶系統發送的訂單創建請求之後，也即在獲取到訂單數據之後，可以判斷訂單數據是否包括買家用戶標識。若訂單數據包括買家用戶標識，則可以根據買家用戶標識，確定第一訂單號。在一種實現方式中，可以結合買家用戶標識以及預設規則，確定第一訂單號。在確定第一訂單號之後，可以根據第一訂單號以及訂單數據，生成預支付訂單。可以理解的是，生成的預支付訂單可以包含上述第一訂單號、買家用戶標識以及商戶id、商戶訂單號、商品信息以及交易金額等信息。若訂單數據不包括買家用戶標識，則可以根據預設的用戶標識，確定第一訂單號。此處的預設的用戶標識可以是預先設置的網關帳號，其與買家用戶標識具有相同的特徵：如，均由預設數量的字符或者數字構成。同樣的，支付系統可以結合預設的用戶標識以及預設規則，來確定第一訂單號。在確定第一訂單號之後，根據第一訂單號、預設的用戶標識以及訂單數據，生成預支付訂單。可以理解的是，生成的預支付訂單可以包含上述第一訂單號、預設的用戶標識以及商戶id、商戶訂單號、商品信息以及交易金額等信息。需要說明的是，上述結合買家用戶標識/預設的用戶標識以及預設規則，確定第一訂單號的過程為傳統常規技術，在此不復贅述。在一個例子中，上述第一訂單號可以由35位數字構成。由於該第一訂單號被稱為「預支付訂單號」，所以其可以具有與正式訂單號(如，下文中的第二訂單號)不同的標識信息，如，第一訂單號具有第一標識信息(如，0)，第二訂單號具有第二標識信息(如，1)。在一種實現方式中，可以將第一訂單號的第20位設為1，而將第二訂單號的第20位設為1，以此來區分上述第一訂單號與第二訂單號。步驟230，將預支付訂單存儲在第一資料庫中。此處的第一資料庫可以是根據待存儲的預支付訂單所包含的信息設計的。在一個例子中，第一資料庫的表結構可以表1所示。表1預支付訂單號標識信息商戶id商戶訂單號商品信息交易金額需要說明的是，表1中欄位「預支付訂單號」的內容為第一訂單號。欄位「標識信息」的內容可以是買家用戶標識，也可以是預設的用戶標識。可以理解的是，表1中各欄位的內容即可構成預支付訂單。當然，表1隻是一種示例性說明，在實際應用中，表1中還可以包括其它欄位，比如，交易時間，操作日誌以及凍結解凍記錄等，本申請對此不作限定。步驟240，當滿足預設的數據同步條件時，將第一資料庫中的預支付訂單同步至第二資料庫中。上述預設的數據同步條件可以包括：預支付訂單的狀態為終態等。在一個例子中，當對預支付訂單執行支付結果處理或者關閉等操作時，該預支付訂單的狀態為終態。需要說明的是，本申請中，第二資料庫可以與第一資料庫具有相同的表結構，也即第二資料庫的表結構也可以如表1所示。在第二資料庫與第一資料庫具有相同的表結構的情況下，上述步驟230與步驟240就可以通過相同的邏輯來實現。從而可以避免傳統技術中，需要通過不同的邏輯來實現向緩存(以key_value的形式存儲數據)中緩存預支付訂單以及向資料庫中存儲更新後的預支付訂單而造成的設計成本高、設計複雜度大的問題。此外，當第二資料庫與第一資料庫具有相同的表結構時，還可以提高支付訂單的預創建效率。舉例來說，在對預支付訂單執行支付結果處理操作之後，支付系統可以獲取到處理結果信息。在獲取到該處理結果信息之後，支付系統可以將預支付訂單的狀態切換為終態，從而滿足了預設的數據同步條件。在滿足預設的數據同步條件時，可以先對預支付訂單進行更新，之後再將更新後的預支付訂單存儲到第二資料庫中，其具體可以通過如圖3所示的各步驟來實現：步驟310，獲取買家用戶標識。該買家用戶標識可以包含在上述處理結果信息中，此外，還可以包含在商戶系統向支付系統發送的關閉指令中。步驟320，對第一資料庫執行鎖定操作。在一個例子中，可以通過「lock」指令來實現對第一資料庫的鎖定操作。步驟330，從執行鎖定操作後的第一資料庫中讀取預支付訂單。以第一資料庫如表1所示為例來說，可以從表1中讀取各欄位的內容。步驟340，根據買家用戶標識，確定第二訂單號。此處，可以結合步驟310中獲取的買家用戶標識以及預設規則，來確定第二訂單號。其確定過程可參考傳統支付訂單中訂單號的生成過程，在此不復贅述。需要說明的是，此處的第二訂單號具有與上述第一訂單號不同的標識信息，該第二訂單號可以稱為「正式訂單號」。步驟350，根據買家用戶標識以及第二訂單號，更新預支付訂單。其中，更新預支付訂單的過程可以為：將從表1中讀取的欄位「標識信息」的內容替換為步驟310中獲取的買家用戶標識，且將從表1中讀取的欄位「預支付訂單」的內容更新為步驟340中確定的第二訂單號。可以理解的是，更新後的預支付訂單即為實實在在的支付訂單，因此，更新後的預支付訂單也可以稱為「正式支付訂單」。步驟360，將更新後的預支付訂單存儲到第二資料庫中。也即將正式支付訂單存儲到第二資料庫中。步驟370，保存第一訂單號與第二訂單號的對應關係。在一種實現方式中，上述第一訂單號與第二訂單號的對應關係可以存儲在映射表中，該映射表的表結構可以如表2所示。表2商戶id商戶訂單號第一訂單號第二訂單號需要說明的是，該映射表可以是第一資料庫中的其它表結構。具體地，上述欄位「商戶id」、「商戶訂單號」以及「第一訂單號」的內容可以是在將預支付訂單存儲在第一資料庫的過程中寫入表1的，而欄位「第二訂單號」的內容則可以是在步驟370之後寫入表1的。此外，圖3中，步驟310-步驟330可以由第一事務執行，而步驟340-步驟360可以由第二事務執行，由此來提高預支付訂單同步的效率。可選地，在將第一資料庫中的預支付訂單同步至第二資料庫之後，還可以對上述預支付訂單執行如下操作：支付結果處理操作、關閉操作、凍結操作以及解凍操作等。其操作流程可以如圖4所示：步驟410，接收訂單操作請求。此處的訂單操作請求可以是由支付系統內部發起，也可以是從商戶系統接收的。其可以包括目標訂單號，其中，該目標訂單號的定義同上述第一訂單號或者第二訂單號的定義相同，在此不復贅述。步驟420，當目標訂單號與第二訂單號相匹配時，根據目標訂單號，從第二資料庫中讀取對應的預支付訂單並執行相應的操作。此處，目標訂單號與第二訂單號相匹配可以包括：目標訂單號與第一訂單的標識位具有相同的標識信息，如，目標訂單號的標識位(如，第20位)為1。在目標訂單號與第二訂單號相匹配時，說明該目標訂單號是根據實際的買家用戶標識確定的，因此，可以直接從二資料庫中讀取對應的預支付訂單並執行相應的操作。步驟430，當目標訂單號與第一訂單號相匹配時，根據目標訂單號，從第一訂單號與第二訂單號的對應關係中查找對應的第二訂單號。步驟440，若查找到第二訂單號，則根據第二訂單號，從第二資料庫中讀取對應的預支付訂單並執行相應的操作。步驟450，若查找不到第二訂單號，則根據目標訂單號，從第一資料庫中讀取對應的預支付訂單並執行相應的操作。同理，目標訂單號與第一訂單號相匹配可以包括：目標訂單號與第二訂單的標識位具有相同的標識信息，如，目標訂單號的標識位(如，第20位)為0。在目標訂單號與第一訂單號相匹配時，則可以先從表2中查找對應的第二訂單號。若查找到第二訂單號，則說明已將預支付訂單從第一資料庫同步至第二資料庫，因此，可以根據第二訂單號從第二資料庫中讀取對應的預支付訂單並執行相應的操作。而若查找不到第二訂單號，則說明還未將預支付訂單從第一資料庫同步至第二資料庫，因此，只能根據目標訂單號從第一資料庫中讀取對應的預支付訂單並執行相應的操作。從圖4各步驟可以看出，在將預支付訂單從第一資料庫同步至第二資料庫，且建立第一訂單號與第二訂單號的對應關係之後，所有的操作請求均會路由至第二資料庫，為減小資料庫容量成本，在業務低峰期可以開啟調度任務刪除第一資料庫中的預支付訂單。此外，本申請的技術方案還可以克服傳統技術的如下缺點：1)無法保證事務的原子性的問題。舉例來說，當將預支付訂單存儲在緩存中時，對預支付訂單執行凍結操作的操作流程如下：a，接收凍結訂單操作請求，該請求包括預支付訂單號。b，判斷緩存中是否存在預支付訂單號對應的正式訂單號。c，如果存在，則從資料庫中加載正式支付訂單，並對正式支付訂單執行凍結操作。d，如果不存在，則從緩存中獲取預支付訂單。e，更新預支付訂單的狀態為凍結狀態。f，生成凍結單。g，將預支付訂單和凍結單保存於緩存中。h，更新消費記錄，顯示預支付訂單已凍結。在上述凍結操作的操作流程中，由於步驟g和步驟h由不同的事務執行，因此當步驟g執行成功，而步驟h執行失敗時，無法同時執行回滾操作。從而會造成預支付訂單已凍結成功，但消費記錄中顯示預支付訂單未凍結的問題，由此會大大影響用戶的體驗。2)無法有效的解決並發問題。傳統技術中，對於預支付訂單的操作(包括凍結操作、解凍操作、關閉操作、支付結果處理操作等)，都需要首先判斷緩存中是否存在預支付訂單號對應的正式訂單號，因此緩存中預支付訂單號與正式訂單號的對應關係為並發共享資源，然而並沒有合適的方案可以對該共享資源進行加鎖控制以避免並發問題。與上述支付訂單的預創建方法對應地，本申請實施例還提供的一種支付訂單的預創建裝置，如圖5所示，該裝置包括：接收單元501，用於接收商戶系統發送的訂單創建請求，該訂單創建請求包括訂單數據。生成單元502，用於根據接收單元501接收的訂單數據，生成預支付訂單，該預支付訂單包含第一訂單號，第一訂單號是優先根據買家用戶標識確定的。可選地，生成單元502具體可以用於：判斷訂單數據是否包括買家用戶標識。若訂單數據包括買家用戶標識，則根據買家用戶標識，確定第一訂單號；並根據第一訂單號以及訂單數據，生成預支付訂單。若訂單數據不包括買家用戶標識，則根據預設的用戶標識，確定第一訂單號；並根據第一訂單號、預設的用戶標識以及訂單數據，生成預支付訂單。存儲單元503，用於將生成單元502生成的預支付訂單存儲在第一資料庫中。同步單元504，用於當滿足預設的數據同步條件時，將第一資料庫中的預支付訂單同步至第二資料庫中。可選地，同步單元504具體可以用於：獲取買家用戶標識。對第一資料庫執行鎖定操作。從執行鎖定操作後的第一資料庫中讀取預支付訂單。根據買家用戶標識，確定第二訂單號。根據買家用戶標識以及第二訂單號，更新預支付訂單。將更新後的預支付訂單存儲到第二資料庫中，並保存第一訂單號與所述第二訂單號的對應關係。可選地，該裝置還可以包括：讀取單元505和查找單元506。接收單元501，還用於接收訂單操作請求，該訂單操作請求包括目標訂單號。讀取單元505，用於當接收單元501接收的目標訂單號與第二訂單號相匹配時，根據目標訂單號，從第二資料庫中讀取對應的預支付訂單並執行相應的操作。查找單元506，用於當目標訂單號與第一訂單號相匹配時，根據目標訂單號，從第一訂單號與第二訂單號的對應關係中查找對應的第二訂單號。讀取單元505，還用於若查找到所述第二訂單號，則根據第二訂單號，從第二資料庫中讀取對應的預支付訂單並執行相應的操作。讀取單元505，還用於若查找不到第二訂單號，則根據目標訂單號，從第一資料庫中讀取對應的預支付訂單並執行相應的操作。可選地，該裝置還可以包括：刪除單元507，用於刪除第一資料庫中的預支付訂單。本申請實施例裝置的各功能模塊的功能，可以通過上述方法實施例的各步驟來實現，因此，本申請提供的裝置的具體工作過程，在此不復贅述。本申請提供的支付訂單的存儲裝置，接收單元501接收商戶系統發送的訂單創建請求。生成單元502根據訂單數據，生成預支付訂單。存儲單元503將預支付訂單存儲在第一資料庫中。當滿足預設的數據同步條件時，同步單元504將第一資料庫中的預支付訂單同步至第二資料庫中。由此，可以提高支付訂單存儲的可靠性。需要說明的是，本申請實施例提供的支付訂單的存儲裝置可以是圖1的支付系統中的一個功能模塊。本領域技術人員應該可以意識到，在上述一個或多個示例中，本發明所描述的功能可以用硬體、軟體、固件或它們的任意組合來實現。當使用軟體實現時，可以將這些功能存儲在計算機可讀介質中或者作為計算機可讀介質上的一個或多個指令或代碼進行傳輸。以上所述的具體實施方式，對本發明的目的、技術方案和有益效果進行了進一步詳細說明，所應理解的是，以上所述僅為本發明的具體實施方式而已，並不用於限定本發明的保護範圍，凡在本發明的技術方案的基礎之上，所做的任何修改、等同替換、改進等，均應包括在本發明的保護範圍之內。當前第1頁12