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