專利名稱：交易信息處理方法
技術(shù)領(lǐng)域：
本發(fā)明涉及一種交易信息處理方法，尤其涉及一種買方商戶將預(yù)付款交 付給銀行，由銀行為買賣雙方商戶的交易提供擔(dān)保的交易信息處理方法。屬于B2B電子商務(wù)領(lǐng)域。
技術(shù)背景B2B (Business-to-Business商業(yè)對商業(yè))是企業(yè)與企業(yè)之間通過互聯(lián)網(wǎng) 進行產(chǎn)品、服務(wù)及信息交換的電子商務(wù)模式?，F(xiàn)有的B2B電子商務(wù)模式主要 包括兩種 一種是企業(yè)之間直接進行的電子商務(wù)，如制造商的在線采購和在 線供貨等；另一種是通過第三方電子商務(wù)平臺進行的商務(wù)活動，各類企業(yè)可 以通過該電子商務(wù)平臺進行企業(yè)間的電子商務(wù)，如發(fā)布和查詢供求信息，與 潛在客戶/供應(yīng)商進行在線交流和商務(wù)洽談等。這種電子商務(wù)模式通常采用的 支付方式是支付保證金模式，即買賣雙方根據(jù)交易進程存入一定比例的保證 金或者預(yù)付款，買方通過第三方交易平臺支付貨款?，F(xiàn)有技術(shù)缺陷在于第一種電子商務(wù)模式需要交易雙方的企業(yè)之間已經(jīng) 建立相互信任的合作關(guān)系，或者交易一方非常強勢，而另一方處于相對被動 的地位，如大型核心企業(yè)與它的供貨商或者經(jīng)銷商等，因此這種電子商務(wù)模 式的應(yīng)用范圍較小。另一種借由第三方電子商務(wù)平臺的B2B模式中，買賣雙 方將支付保證金交給第三方交易平臺，本質(zhì)上是由第三方交易平臺在買賣雙 方之間提供了一個擔(dān)保，但該第三方是否有資格充當(dāng)結(jié)算的中介，買方用戶 是否信任該第三方的擔(dān)保仍然難以確定，存在資金安全隱患，并且結(jié)算帳戶
中的利息歸屬問題也頗有爭議。另外，第三方交易平臺的介入中斷了交易雙 方的資金流，為雙方開立發(fā)票帶來了困難。發(fā)明內(nèi)容本發(fā)明的目的是提供一種交易信息處理方法，使銀行充當(dāng)B2B電子商務(wù) 中買賣雙方商戶的交易擔(dān)保中介，并且支付結(jié)算方便，信息安全可靠。為實現(xiàn)上述目的，本發(fā)明提供了一種交易信息處理方法，包括買方商戶終端向銀行支付系統(tǒng)發(fā)送交易請求消息；銀行支付系統(tǒng)收到交易請求消息后，對交易請求消息的類型進行判斷，如果該交易請求消息為攜帶有訂單信息的訂單生成請求消息，則在銀行 支付系統(tǒng)收到賣方商戶終端發(fā)送的訂單確認(rèn)消息的情況下，將訂單信息進行 保存；如果該交易請求消息為預(yù)付款請求消息，則根據(jù)該消息查詢相應(yīng)的訂單 信息，并根據(jù)該訂單信息向銀行帳戶系統(tǒng)發(fā)送轉(zhuǎn)帳請求消息；銀行帳戶系統(tǒng)完成轉(zhuǎn)帳操作后，向銀行支付系統(tǒng)回復(fù)轉(zhuǎn)帳確認(rèn)消息。通過上述步驟，買賣雙方商戶將訂單信息保存在銀行，并且通過^l艮行對 貨款交付進行管理和轉(zhuǎn)帳，雙方都可以通過銀行指定的查詢方式查詢預(yù)付款 信息，以進行下一步的交易行為，從而促進了交易的順利進行。由于銀行是 具有較高公共信譽的單位，具有為交易雙方提供擔(dān)保的能力和資格，買賣雙 方商戶在交易過程中不需要電子商務(wù)平臺等第三方的介入，使得對預(yù)付款的 管理更加安全可靠。另外，銀行在收到預(yù)付款時，根據(jù)通常的業(yè)務(wù)流程會在 銀行預(yù)付款帳戶中予以記錄，因此不需要開立發(fā)票，從而避免了由于電子商 務(wù)平臺等第三方的介入而引起的開立發(fā)票的困難。并且，在交易過程中的利 息可以作為銀行的服務(wù)費用的一部分支付給銀行，從而避免了分歧。下面通過附圖和實施例，對本發(fā)明的技術(shù)方案做進一步的詳細(xì)描述。


圖1為本發(fā)明實施例1所述交易信息處理方法的流程圖； 圖2為本發(fā)明實施例2所述交易信息處理方法的流程圖； 圖3為本發(fā)明實施例3所述交易信息處理方法的流程圖； 圖4為本發(fā)明實施例4所述交易信息處理方法的流程圖。
具體實施方式
實施例1本實施提供了一種在B2B電子商務(wù)交易過程中由買方商戶發(fā)起生成訂單 的交易信息處理方法。如圖1所示，步驟IOI，買方商戶終端向銀行支付系統(tǒng)發(fā)送交易請求消息，在本實施例 中還包括發(fā)送攜帶有訂單信息的訂單生成請求消息。其中，訂單信息主要包 括買賣雙方商戶信息，如買賣雙方商戶的商戶號、賬戶名及賬戶號等，另外 還包括交易信息，如商品名稱、數(shù)量、單價、總價等。步驟102,銀行支付系統(tǒng)收到交易請求消息后，對交易請求消息的類型進 行判斷，在本實施例中具體為，判斷出該交易請求消息為攜帶有訂單信息的 訂單生成請求消息，并執(zhí)行步驟103。步驟103,銀行支付系統(tǒng)根據(jù)訂單信息向賣方商戶終端發(fā)送訂單確認(rèn)請求 消息，即向賣方商戶查詢是否確認(rèn)該筆訂單，具體方式可以為發(fā)送短信或自 動語音電話等。步驟104、賣方商戶終端收到訂單確認(rèn)請求消息后，向銀行支付系統(tǒng)回復(fù) 訂單確認(rèn)消息，表明對該訂單予以確認(rèn)。步驟105，銀行支付系統(tǒng)在收到訂單確認(rèn)消息的情況下，將訂單信息進行 保存，具體可以保存在銀行支付系統(tǒng)本服務(wù)器上，也可以保存在銀行內(nèi)部其 他的一些服務(wù)器上，供日后查詢。需要說明的是，如果買賣雙方事先已約定
好要生成該筆訂單，則賣方商戶不需要銀行支付系統(tǒng)發(fā)送通知消息也可以自行發(fā)送訂單確認(rèn)消息，因此步驟103及104也是可以省略的。經(jīng)過本實施例所述步驟，買賣雙方商戶將訂單信息保存在銀行，雙方都 可以通過銀行指定的查詢方式查詢訂單信息，以進行下一步的交易行為，從 而促進了交易的順利進行。由于銀行是具有較高公共信譽的單位，具有為交 易雙方提供擔(dān)保的能力和資格，買賣雙方商戶的交易信息直接發(fā)送給銀行， 而不需要電子商務(wù)平臺等第三方的介入，使得交易信息更加安全可靠。 實施例2本實施提供了一種在B2B電子商務(wù)交易過程中由買方商戶發(fā)起對預(yù)付款 進行預(yù)付的交易信息處理方法。如圖2所示，步驟201、買方商戶終端向銀行支付系統(tǒng)發(fā)送預(yù)付款預(yù)付請求消息作為交 易請求消息，目的是為了預(yù)付貨款。步驟202，銀行支付系統(tǒng)收到交易請求消息后，對交易請求消息的類型進 行判斷，在本實施例中具體為，判斷出該交易請求消息為預(yù)付款請求消息， 并且該預(yù)付款請求消息為預(yù)付款預(yù)付請求消息，即請求將預(yù)付款預(yù)付給^l行。步驟203，銀行支付系統(tǒng)根據(jù)預(yù)付款預(yù)付請求消息查詢相應(yīng)的訂單信息， 并根據(jù)查詢出的訂單信息向銀行帳戶系統(tǒng)發(fā)送預(yù)付款預(yù)付轉(zhuǎn)帳請求消息。由 于訂單信息中包含有買方商戶信息，如商戶號、賬戶名及賬戶號等，因此預(yù) 付款預(yù)付轉(zhuǎn)帳請求消息內(nèi)容為，請求銀行帳戶系統(tǒng)由買方商戶帳戶向銀行預(yù) 付款賬戶轉(zhuǎn)帳，即買方商戶將預(yù)付款交付給銀行。步驟204，銀行帳戶系統(tǒng)從買方商戶帳戶中扣除預(yù)付款金額，并在銀行預(yù) 付款賬戶中增加相應(yīng)的預(yù)付款金額，即進行轉(zhuǎn)帳操作。步驟205,轉(zhuǎn)帳完成后，銀行帳戶系統(tǒng)向銀行支付系統(tǒng)回復(fù)預(yù)付款預(yù)付轉(zhuǎn) 帳確認(rèn)消息，表明預(yù)付款已經(jīng)預(yù)付完成。通過上述步驟，買方商戶將預(yù)付款交付給銀行，雙方都可以通過銀行指 定的查詢方式查詢預(yù)付款信息，以進行下一步的交易行為，從而促進了交易
的順利進行。由于銀行是具有較高公共信譽的單位，具有為交易雙方提供擔(dān) 保的能力和資格，買方商戶的預(yù)付款直接交付給銀行，而不需要電子商務(wù)平 臺等第三方的介入，使得對預(yù)付款的管理更加安全可靠。并且買方商戶帳戶 和銀行預(yù)付款帳戶都屬于一家銀行，因此操作更加簡便，也避免了跨行操作 帶來的額外費用。另外，銀行在收到預(yù)付款時，根據(jù)通常的業(yè)務(wù)流程會在銀 行預(yù)付款帳戶中予以記錄，因此不需要開立發(fā)票，從而避免了由于電子商務(wù) 平臺等第三方的介入而引起的開立發(fā)票的困難。并且，存儲在銀行預(yù)付款帳 戶中的預(yù)付款所產(chǎn)生的利息可以作為銀行的服務(wù)費用的 一部分支付給銀行， 從而避免了分歧。實施例3本實施提供了一種在B2B電子商務(wù)交易過程中由買方商戶發(fā)起取消預(yù)付 貨款的交易信息處理方法。如圖3所示，步驟301，買方商戶終端向銀行支付系統(tǒng)發(fā)送預(yù)付款取消請求消息作為交 易請求消息，目的是要取消已經(jīng)預(yù)付的預(yù)付款。步驟302,銀行支付系統(tǒng)收到交易請求消息后，對交易請求消息的類型進 行判斷，在本實施例中具體為，判斷出該交易請求消息為預(yù)付款請求消息， 并且該預(yù)付款請求消息為預(yù)付款取消請求消息，即請求取消已經(jīng)預(yù)付給銀行 的預(yù)付款。步驟303,銀行支付系統(tǒng)根據(jù)預(yù)付款取消請求消息查詢相應(yīng)的訂單信息， 并向賣方商戶終端發(fā)送預(yù)付款取消確認(rèn)請求消息。例如通過短信通知或自動 語音電話等方式向賣方商戶查詢是否確認(rèn)取消該筆預(yù)付款。賣方商戶若同意 取消預(yù)付款，則執(zhí)行步驟304。步驟304，賣方商戶終端向銀行支付系統(tǒng)回復(fù)預(yù)付款取消確認(rèn)消息。需要 說明的是，如果買賣雙方事先已約定好要取消該筆預(yù)付款，則賣方商戶不需 要向銀行支付系統(tǒng)發(fā)送通知消息也可以自行發(fā)送預(yù)付款取消確認(rèn)消息，因此 步驟303及304也是可以省略的。
步驟305,銀行支付系統(tǒng)在收到賣方商戶終端發(fā)送的預(yù)付款取消確認(rèn)消息 的情況下，根據(jù)查詢出的訂單信息向銀行帳戶系統(tǒng)發(fā)送預(yù)付款取消轉(zhuǎn)帳請求 消息。由于訂單信息中包含有買方商戶信息，如商戶號、賬戶名及賬戶號等， 因此預(yù)付款取消轉(zhuǎn)帳請求消息內(nèi)容為，請求銀行帳戶系統(tǒng)由銀行預(yù)付款賬戶 向買方商戶帳戶轉(zhuǎn)帳，即買方商戶從銀行取回預(yù)先交納的預(yù)付款。步驟306, 4艮行帳戶系統(tǒng)從^l艮行預(yù)付款賬戶中扣除預(yù)付款金額，并在買方 商戶帳戶中增加相應(yīng)的預(yù)付款金額，即進行轉(zhuǎn)帳操作。步驟307,轉(zhuǎn)帳完成后，銀行帳戶系統(tǒng)向銀行支付系統(tǒng)回復(fù)預(yù)付款取消轉(zhuǎn) 帳確認(rèn)消息，表明預(yù)付款已經(jīng)被取消。通過上述步驟，買方商戶取消了已經(jīng)交付給銀行的預(yù)付款，并且在預(yù)付 款取消之前增加了由賣方商戶進行確認(rèn)的步驟，因此避免了買方商戶違反約 定自行取消預(yù)付款的可能性。從而促進了交易的公平性。由于銀行是具有較 高公共信譽的單位，具有為交易雙方提供擔(dān)保的能力和資格，只要經(jīng)過買賣 雙方商戶確認(rèn)，買方商戶可以順利取回預(yù)付款，避免了由于將預(yù)付款交付給 電子商務(wù)平臺等第三方而無法取回的風(fēng)險，使得對預(yù)付款的管理更加安全可 靠。并且買方商戶帳戶和銀行預(yù)付款帳戶都屬于一家銀行，因此操作更加簡 便，也避免了跨行操作帶來的額外費用。另外，存儲在銀行預(yù)付款帳戶中的 預(yù)付款所產(chǎn)生的利息可以作為銀行的服務(wù)費用的一部分支付給銀行，從而避 免了分歧。 實施例4本實施提供了一種在B2B電子商務(wù)交易過程中由買方商戶發(fā)起對將預(yù)付 款實際支付給賣方商戶的交易信息處理方法。如圖4所示，步驟401、買方商戶終端向銀行支付系統(tǒng)發(fā)送預(yù)付款實付請求消息作為交 易請求消息，目的是為了將已經(jīng)預(yù)付到銀行的預(yù)付款實際支付給賣方商戶。步驟402，銀行支付系統(tǒng)收到交易請求消息后，對交易請求消息的類型進 行判斷，在本實施例中具體為，判斷出該交易請求消息為預(yù)付款請求消息， 并且該預(yù)付款請求消息為預(yù)付款實付請求消息，即請求將預(yù)付款實際支付給 賣方商戶。步驟403,銀行支付系統(tǒng)根據(jù)預(yù)付款實付請求消息查詢相應(yīng)的訂單信息，并根據(jù)查詢出的訂單信息向銀行帳戶系統(tǒng)發(fā)送預(yù)付款實付轉(zhuǎn)帳請求消息。由 于訂單信息中包含有賣方商戶信息，如商戶號、賬戶名及賬戶號等，因此預(yù) 付款實付轉(zhuǎn)帳請求消息內(nèi)容為，請求銀行帳戶系統(tǒng)由銀行預(yù)付款賬戶向賣方 商戶帳戶轉(zhuǎn)帳，即^l行將預(yù)付款實付給買方商戶。步驟404，銀行帳戶系統(tǒng)從銀行預(yù)付款賬戶中扣除預(yù)付款金額，并在賣方 商戶帳戶中增加相應(yīng)的預(yù)付款金額，即進行轉(zhuǎn)帳操作。步驟405,轉(zhuǎn)帳完成后，銀行帳戶系統(tǒng)向銀行支付系統(tǒng)回復(fù)預(yù)付款實付轉(zhuǎn) 帳確認(rèn)消息，表明預(yù)付款已經(jīng)實際支付給賣方商戶。通過上述步驟，買方商戶將預(yù)付款實際支付給賣方商戶，從而促成了交 易的完成。由于銀行是具有較高公共信譽的單位，具有為交易雙方提供擔(dān)保 的能力和資格，只要經(jīng)過買方商戶確認(rèn)，買方商戶便可以將預(yù)付款實際支付 給賣方商戶，避免了由于將預(yù)付款交付給電子商務(wù)平臺等第三方而無法交付 給賣方商戶的風(fēng)險，使得對預(yù)付款的管理更加安全可靠。并且買賣雙方商戶 帳戶和銀行預(yù)付款帳戶都屬于一家銀行，因此操作更加簡便，也避免了跨行 操作帶來的額外費用。另外，存儲在銀行預(yù)付款帳戶中的預(yù)付款所產(chǎn)生的利 息可以作為銀行的服務(wù)費用的 一部分支付給銀行，從而避免了分歧。另外需要特別指出的是，在實際應(yīng)用上述實施例1-4中所述步驟時，買 賣雙方商戶終端與銀行支付系統(tǒng)之間傳輸?shù)乃邢?，在發(fā)送前可以利用現(xiàn) 有的電子簽名、加密等技術(shù)進行處理，收到方對收到的消息進行解密及對電 子簽名進行驗證，以保證信息的安全及消息發(fā)送方的身份合法性。而銀行支 付系統(tǒng)與銀行帳戶系統(tǒng)都屬于銀行的內(nèi)部網(wǎng)絡(luò)，因此進行信息傳遞時不需要 進行加密或電子簽名。另外，對于確認(rèn)消息，銀行與買賣雙方商戶之間可以 事先約定好，商戶端可以有多個有權(quán)發(fā)送確認(rèn)消息的授權(quán)人員，銀行支付系
統(tǒng)只有收到買方或賣方商戶所有授權(quán)人員發(fā)送的確認(rèn)消息后，才繼續(xù)進行下 一個處理步驟，以確保資金劃撥的安全性。最后所應(yīng)說明的是，以上實施例僅用以說明本發(fā)明的技術(shù)方案而非限制， 盡管參照較佳實施例對本發(fā)明進行了詳細(xì)說明，本領(lǐng)域的普通技術(shù)人員應(yīng)當(dāng) 理解，可以對本發(fā)明的技術(shù)方案進行修改或者等同替換，而不脫離本發(fā)明技 術(shù)方案的精神和范圍。
權(quán)利要求
1、一種交易信息處理方法，其特征在于，包括買方商戶終端向銀行支付系統(tǒng)發(fā)送交易請求消息；銀行支付系統(tǒng)收到交易請求消息后，對交易請求消息的類型進行判斷，如果該交易請求消息為攜帶有訂單信息的訂單生成請求消息，則在銀行支付系統(tǒng)收到賣方商戶終端發(fā)送的訂單確認(rèn)消息的情況下，將訂單信息進行保存；如果該交易請求消息為預(yù)付款請求消息，則根據(jù)該消息查詢相應(yīng)的訂單信息，并根據(jù)該訂單信息向銀行帳戶系統(tǒng)發(fā)送轉(zhuǎn)帳請求消息；銀行帳戶系統(tǒng)完成轉(zhuǎn)帳操作后，向銀行支付系統(tǒng)回復(fù)轉(zhuǎn)帳確認(rèn)消息。
2、 根據(jù)權(quán)利要求1所述的交易信息處理方法，其特征在于，所述步驟還 包括銀行支付系統(tǒng)根據(jù)訂單生成請求消息向賣方商戶終端發(fā)送訂單確認(rèn)請求 消息；賣方商戶終端收到訂單確認(rèn)請求消息后，向銀行支付系統(tǒng)回復(fù)訂單確 認(rèn)消息。
3、 根據(jù)權(quán)利要求l所述的交易信息處理方法，其特征在于，所述步驟還包括如果所述交易請求消息為預(yù)付款預(yù)付請求消息，則根據(jù)該消息查詢相 應(yīng)的訂單信息，并根據(jù)該訂單信息向銀行帳戶系統(tǒng)發(fā)送預(yù)付款預(yù)付轉(zhuǎn)帳請求 消息。
4、 根據(jù)權(quán)利要求3所述的交易信息處理方法，其特征在于，所述銀行帳 戶系統(tǒng)完成轉(zhuǎn)帳搡作還包括銀行帳戶系統(tǒng)從買方商戶帳戶中扣除預(yù)付款金 額，并在銀行預(yù)付款賬戶中增加相應(yīng)的預(yù)付款金額，完成后，向銀行支付系 統(tǒng)回復(fù)預(yù)付款預(yù)付轉(zhuǎn)帳確認(rèn)消息。
5、 根據(jù)權(quán)利要求1所述的交易信息處理方法，其特征在于，所述步驟還 包括如果所述交易請求消息為預(yù)付款取消請求消息，則根據(jù)該消息查詢相 應(yīng)的訂單信息；在收到賣方商戶終端發(fā)送的預(yù)付款取消確認(rèn)消息的情況下，根據(jù)查詢出的訂單信息向銀行帳戶系統(tǒng)發(fā)送預(yù)付款取消轉(zhuǎn)帳請求消息。
6、 根據(jù)權(quán)利要求5所述的交易信息處理方法，其特征在于，所述銀行 帳戶系統(tǒng)完成轉(zhuǎn)帳操作還包括銀行帳戶系統(tǒng)從銀行預(yù)付款賬戶中扣除預(yù)付 款金額，并在買方商戶帳戶中增加相應(yīng)的預(yù)付款金額，完成后，向銀行支付 系統(tǒng)回復(fù)預(yù)付款取消轉(zhuǎn)帳確認(rèn)消息。
7、 根據(jù)權(quán)利要求6所述的交易信息處理方法，其特征在于，所述步驟 還包括銀行支付系統(tǒng)根據(jù)預(yù)付款取消請求消息向賣方商戶終端發(fā)送預(yù)付款 取消確認(rèn)請求消息；賣方商戶終端收到該消息后，向銀行支付系統(tǒng)回復(fù)預(yù)付 款取消確認(rèn)消息。
8、 根據(jù)權(quán)利要求1所述的交易信息處理方法，其特征在于，所述步驟還 包括如果所述交易請求消息為預(yù)付款實付請求消息，則根據(jù)該消息查詢相 應(yīng)的訂單信息，并根據(jù)查詢出的訂單信息向銀行帳戶系統(tǒng)發(fā)送預(yù)付款實付轉(zhuǎn) 帳請求消息。
9、 根據(jù)權(quán)利要求8所述的交易信息處理方法，其特征在于，所述銀行帳 戶系統(tǒng)完成轉(zhuǎn)帳操作還包括銀行帳戶系統(tǒng)從銀行預(yù)付款賬戶中扣除預(yù)付款 金額，并在賣方商戶帳戶中增加相應(yīng)的預(yù)付款金額，完成后，向銀行支付系 統(tǒng)回復(fù)預(yù)付款實付轉(zhuǎn)帳確認(rèn)消息。
10、 根據(jù)權(quán)利要求1 - 9所述任意一種交易信息處理方法，其特征在于， 所述步驟還包括買方或賣方商戶終端向銀行支付系統(tǒng)發(fā)送消息前，還對該 消息進行加密和電子簽名。
全文摘要
本發(fā)明涉及一種交易信息處理方法，包括銀行支付系統(tǒng)收到交易請求消息后進行判斷，如果為訂單生成請求消息，則當(dāng)收到賣方商戶終端發(fā)送的訂單確認(rèn)消息后，將訂單信息進行保存；如果為預(yù)付款請求消息，則查詢相應(yīng)的訂單信息，并向銀行帳戶系統(tǒng)發(fā)送轉(zhuǎn)帳請求消息，進行轉(zhuǎn)帳操作?；谏鲜霾襟E，買賣雙方將預(yù)付款交付給銀行，由銀行充當(dāng)B2B電子商務(wù)中買賣雙方商戶的交易擔(dān)保中介。由于銀行是具有較高公共信譽的單位，因此使交易過程更加安全可靠，并且支付結(jié)算方便，從而促進了交易的順利進行。
文檔編號G06Q30/00GK101162518SQ20061014006
公開日2008年4月16日 申請日期2006年10月11日 優(yōu)先權(quán)日2006年10月11日
發(fā)明者穎 李, 琳 王, 郝付國 申請人:中國民生銀行股份有限公司