本發(fā)明涉及電子商務領域，尤其涉及一種基于同一資金服務器的支付系統(tǒng)及其支付方法、裝置和服務器。

背景技術：

電子商務已越來越廣泛地應用于各種商業(yè)貿易活動中，所謂電子商務是指在商業(yè)貿易活動中，在因特網(wǎng)開放的網(wǎng)絡環(huán)境下，基于瀏覽器及服務器應用方式，實現(xiàn)消費者的網(wǎng)上購物、商戶之間的網(wǎng)上交易和在線電子支付以及各種商務活動、交易活動、金融活動和相關的綜合服務活動的一種商業(yè)運營模式。

目前，很多銀行或者企業(yè)都提供了網(wǎng)絡支付的服務，允許客戶操作計算機、手機等終端設備來實現(xiàn)網(wǎng)絡支付，網(wǎng)絡支付的方式為客戶提供了很大的便利。而網(wǎng)絡支付的過程中，多為使用借記卡內的現(xiàn)有資金或信用卡直接支付，或將現(xiàn)有資金或信用卡內的信用額度等額資金直接劃撥到第三方機構作為擔保進行交易，一旦商戶未提供商品或服務時有或者發(fā)生客戶爭議時，資金安全難以得以保證。由此可見，現(xiàn)階段需要新的支付系統(tǒng)、方法、裝置和資金管理服務器，以降低用戶資金風險，保障買賣雙方的利益。

技術實現(xiàn)要素：

有鑒于此，本發(fā)明要解決的技術問題是提供一種基于同一資金服務器的支付系統(tǒng)及其支付方法、裝置和服務器，以降低用戶資金風險，保障買賣雙方的利益。

本發(fā)明解決上述技術問題所采用的技術方案如下：

一種基于同一資金服務器的支付系統(tǒng)，包括至少一個客戶端、至少一個商戶端、信息中心服務器和資金管理服務器，所述資金管理服務器分別與所述客戶端、商戶端和信息中心服務器連接，其中：

所述客戶端，用于向所述資金管理服務器發(fā)送至少包括有支付金額的支付請求信息；

所述商戶端，用于接收所述資金管理服務器發(fā)送的電子承諾支付憑證；

資金管理服務器，用于接收所述客戶端發(fā)送的支付請求信息；比較客戶端授信貸款額度和支付金額判斷能否生成電子承諾支付憑證予以支付；若能，資金管理服務器凍結所述客戶端賬戶內與所述支付金額對應的授信貸款額度，生成由所述資金管理服務器承諾按約定條件解付資金的的電子承諾支付憑證，并將所述電子承諾支付憑證信息發(fā)送給商戶端替所述客戶端進行信用承諾支付，并將所述電子承諾支付憑證信息同步到所述信息中心服務器；

信息中心服務器，用于存儲并監(jiān)管所述電子承諾支付憑證信息。

如果客戶端賬戶授信貸款額度小于支付金額時，則比較客戶端賬戶資金余額和支付金額判斷能否生成電子承諾支付憑證予以支付。

如果客戶端賬戶授信貸款額度小于支付金額時，則比較客戶端賬戶授信透支額度和支付金額判斷能否生成電子承諾支付憑證予以支付。

根據(jù)本發(fā)明的另一個方面，提供的一種基于同一資金服務器的網(wǎng)絡支付方法，該方法包括以下步驟：

資金管理服務器接收客戶端發(fā)送的支付請求信息，其中，支付請求信息至少包括支付金額；

比較所述客戶端授信貸款額度和所述支付金額判斷能否生成電子承諾支付憑證予以支付；

若能，所述資金管理服務器凍結所述客戶端賬戶內與所述支付金額對應的授信貸款額度；生成由所述資金管理服務器承諾按約定條件解付資金的的電子承諾支付憑證，將所述電子承諾支付憑證信息發(fā)送給商戶端替所述客戶端進行信用承諾支付，并將所述電子承諾支付憑證信息同步到信息中心服務器。

如果客戶端賬戶授信貸款額度小于支付金額時，則比較客戶端賬戶授 信透支額度和支付金額判斷能否生成電子承諾支付憑證予以支付；進一步，如果客戶端賬戶授信透支額度小于支付金額時，則比較客戶端賬戶資金余額和支付金額判斷能否生成電子承諾支付憑證予以支付。

如果客戶端賬戶授信貸款額度小于支付金額時，則比較客戶端賬戶資金余額和支付金額判斷能否生成電子承諾支付憑證予以支付；進一步，如果客戶端賬戶資金余額小于支付金額時，則比較客戶端賬戶授信透支額度和支付金額判斷能否生成電子承諾支付憑證予以支付。

根據(jù)本發(fā)明的又一個方面，提供的一種基于同一資金服務器的支付裝置，所述裝置包括接收模塊、判斷模塊和處理模塊，其中。

接收模塊，設置為接收客戶端發(fā)送的支付請求信息，其中，所述支付請求信息包括支付金額；

判斷模塊，設置為根據(jù)所述客戶端資金余額、授信透支余額或授信貸款余額和所述支付金額判斷是否允許支付；

處理模塊，設置為當允許支付時，凍結所述客戶端賬戶內的所述支付金額對應的資金或授信透支額度或授信貸款額度；生成電子承諾支付憑證，將所述電子承諾支付憑證信息發(fā)送給商戶端，并同步到信息中心服務器。

一種基于同一資金服務器的服務器，所述服務器包括上述任意一項權利要求所述的支付裝置。

本發(fā)明提供的基于同一資金服務器的支付系統(tǒng)及其方法、裝置和服務器，通過資金管理服務器和信息中心服務器對買賣雙方的信息進行監(jiān)管，將監(jiān)管功能合并到銀行或其他具備信用支付能力的機構；同時通過凍結客戶端賬戶的賬戶余額或授信透支額度或授信貸款額度，并生成電子支付憑證同步到信息中心服務器進行實時監(jiān)控，能降低資金風險，保障買賣雙方的利益；此方案充分利用了資金管理服務器的信用中樞和信息中心服務器的風控中心功能，以更加優(yōu)化的信用機制促進網(wǎng)絡交易和保障交易資金安全，為交易雙方提供了信用媒介，還通過對資金的監(jiān)管能降低資金風險，保障交易雙方的利益。此外，還通過增加貸款功能方便了客戶，也豐富了銀行或其他具備信用支付能力的機構的業(yè)務。

附圖說明

圖1為本發(fā)明實施例一提供的一種基于同一資金服務器的支付系統(tǒng)的示意圖；

圖2為本發(fā)明實施例二提供的一種基于同一資金服務器的支付方法的流程圖；

圖3為本發(fā)明實施例三提供的一種基于同一資金服務器的支付方法的流程圖；

圖4為本發(fā)明實施例四提供的一種基于同一資金服務器的支付方法的流程圖；

圖5為本發(fā)明實施例五提供的一種基于同一資金服務器的支付方法的流程圖；

圖6為本發(fā)明實施例六提供的一種基于同一資金服務器的支付方法的流程圖；

圖7為本發(fā)明實施例七提供的一種基于同一資金服務器的支付裝置的模塊結構圖；

圖8為本發(fā)明實施例八提供的一種基于同一資金服務器的支付系統(tǒng)的模塊結構圖。

具體實施方式

為了使本發(fā)明所要解決的技術問題、技術方案及有益效果更加清楚、明白，以下結合附圖和實施例，對本發(fā)明進行進一步詳細說明。應當理解，此處所描述的具體實施例僅僅用以解釋本發(fā)明，并不用于限定本發(fā)明。

實施例一

如圖1所示，本發(fā)明實施例提供的一種基于同一資金服務器的支付系統(tǒng)，該系統(tǒng)包括至少一個客戶端10、至少一個商戶端20，信息中心服務器40和資金管理服務器30，資金管理服務器30分別與客戶端10、商戶端20和信息中心服務器40連接，其中：

客戶端10，與資金管理服務器30相連接，用于向資金管理服務器30發(fā)送支付請求信息，其中支付請求信息包括支付金額。

具體地，客戶端10適用于付款方(買方)，包括手機、個人電腦、PAD等智能設備，客戶端10的賬戶信息是用戶注冊時填寫，并存儲在資金管理 服務器和/或信息中心服務器的數(shù)據(jù)庫中的，客戶端10的賬戶信息包括用戶ID、開戶銀行、賬戶名稱、銀行賬號、信用額度等信息，還可以包括客戶的收貨/服務地址信息。支付請求信息是在用戶選擇購買具體的商品/服務后，填寫/確認收貨/服務地址等信息，客戶端10按預設的規(guī)則根據(jù)商品/服務的價格、商品/服務所屬的商戶生成的數(shù)據(jù)包，將該數(shù)據(jù)包發(fā)送給資金管理服務器30。支付請求信息至少包括支付金額，還可以包括商戶信息和商品信息。其中，商戶信息可以直接是商戶收款賬號，也可以唯一標識商戶的信息(如商戶ID)，由資金管理服務器30根據(jù)商戶唯一標識從數(shù)據(jù)庫中查找商戶對應的銀行賬號信息。在具體應用中，商戶端20的賬戶信息相對客戶端10應該是保密的，故商戶信息優(yōu)選為商戶ID，資金管理服務器30利用商戶ID與其收款賬號存在對應的關系來查詢商戶的收款賬號。也就是說，客戶端10只需告知資金管理服務器30向哪個商戶的哪個商品支付多少款項，資金管理服務器30便能調出商戶的賬號實現(xiàn)支付。

商戶端20，與資金管理服務器30相連接，用于接收資金管理服務器30發(fā)送的電子承諾支付憑證。

具體地，商戶端20適用于收款方(賣方)，商戶端包括但不限于服務器、POS機等設備。商戶包括但不限于生產(chǎn)制造商、代理商、物流公司等。商戶信息也是用戶開戶時進行注冊并存儲在資金管理服務器和/或信息中心服務器的數(shù)據(jù)庫中的，商戶信息包括但不限于商戶ID、商戶名稱、商戶開戶銀行、商戶賬戶名稱、商戶銀行賬號等信息。

資金管理服務器30，用于接收客戶端10發(fā)送的支付請求信息；根據(jù)客戶端10的授信透支額度、資金余額、授信貸款額度和支付金額判斷是否允許支付；如果允許支付，則凍結客戶端賬戶內與支付金額對應的授信額度或資金余額，生成由所述資金管理服務器承諾按約定條件解付資金的電子承諾支付憑證，將電子承諾支付憑證信息發(fā)送給商戶端20，并同步到信息中心服務器40。

具體地，資金管理服務器30接收到支付請求信息的數(shù)據(jù)包后，按預設的規(guī)則進行解析，獲取相關支付信息，相關支付信息包括但不限于商戶信息、商品信息和支付金額等必要信息，即向哪個商戶的哪個商品支付多少款項。

信息中心服務器40，與資金管理服務器30相連，用于存儲客戶端10 和商戶端20的電子承諾支付憑證信息。

具體地，客戶端10和商戶端20都可以通過互聯(lián)網(wǎng)向信息中心服務器40獲取電子承諾支付憑證信息以便后繼的處理，比如利用該數(shù)據(jù)進行雙通道的驗證信息的正確與否。資金管理服務器30還可以根據(jù)電子承諾支付憑證信息的狀態(tài)進一步確定是否劃款操作，即請求支付只是凍結資金，確認簽收后進行劃款操作。

在本實施例中，同一資金管理服務器30，還可同時與多個客戶端10和多個商戶端20均通過互聯(lián)網(wǎng)連接。即商戶端20賬戶所在的服務器與客戶端10所在的服務器均為同一資金管理服務器30。同一資金管理服務器30，可以為物理意義上的單一服務器，也可以為物理意義上的多臺服務器，如多臺物理服務器并行工作，根據(jù)業(yè)務量的不同，自動分配服務器的資源，共同實現(xiàn)資金管理。資金管理服務器包括但不限于銀行、企業(yè)等組織中的服務器。實際應用中，可以理解為同一銀行的集群資金管理服務器，但并不局限于銀行，還可以能在互聯(lián)網(wǎng)中支持資金流動的其它機構，亦或是其他具備信用支付能力的機構，也就是通常說的第三方機構。通過資金管理服務器和信息中心服務器對買賣雙方的信息進行監(jiān)管，將監(jiān)管功能合并到銀行或其它具備信用支付能力的機構。

實施例二

如圖2所示，本發(fā)明實施例提供的一種基于同一資金服務器的支付方法，應用于資金管理服務器，該方法包括以下步驟：

S101、資金管理服務器30接收客戶端發(fā)送的支付請求信息，支付請求信息至少包括支付金額。

具體地，資金管理服務器接收的支付請求信息包括：商戶信息、商品信息和支付金額，還可以包括客戶端信息(如客戶ID)。其中，商戶信息可以直接是商戶收款賬號，也可以唯一標識商戶的信息(如商戶ID)，由資金管理服務器根據(jù)商戶唯一標識從數(shù)據(jù)庫中查找商戶對應的銀行賬號信息。在具體應用中，商戶端的賬戶信息相對客戶端應該是保密的，故商戶信息優(yōu)選為商戶ID，資金管理服務器利用商戶ID與其收款賬號存在對應的關系來查詢商戶的收款賬號。也就是說，客戶端只需告知資金管理服務器向哪個商戶的哪個商品支付多少款項，資金管理服務器便能調出商戶的賬號實 施相應的支付操作。

S102、比較客戶端授信貸款額度和支付金額判斷能否生成電子承諾支付憑證予以支付，如果允許支付，否則終止本次支付。

本步驟進一步包括：判斷客戶端授信貸款額度是否大于或等于支付金額，如果是，則允許本次支付；否則終止本次支付。其中，客戶端的銀行賬號可以是客戶端在支付請求信息中告知資金管理服務器的，也可以資金管理服務器根據(jù)客戶端ID從數(shù)據(jù)庫中查詢的，從而獲取對應賬戶資金余額。只有在客戶端的賬戶授信貸款額度大于或等于支付金額時，才表示客戶具有支付能力，此時才允許進行支付行為。優(yōu)先采用賬戶資金余額支付，可以節(jié)省付款周期，保障客戶的利益。

S103、資金管理服務器凍結客戶端賬戶內的支付金額對應的授信貸款額度；

具體地，當賬戶授信貸款額度足以支付時，凍結銀行賬戶內支付金額對應的授信貸款額度。本步驟只凍結授信貸款額度以確保后繼有足夠的授信透支額度完成本次交易，但不并直接劃款到商戶賬號，這樣保障了買賣雙方的利益，后繼可以由客戶端、商戶端或者物流公司發(fā)送解付信息確認交付完成，由資金管理服務器在接收到解付信息后，將與支付資金等額的資金劃款到商戶賬號。

S104、資金管理服務器生成電子承諾支付憑證；

具體地，由于支付請求信息是買方通過客戶端操作發(fā)送給資金管理服務器的，其支付信息客觀上是得到了客戶確認并授權銀行支付的。資金管理服務器凍結相應的資金或授信貸款額度，同時將生成根據(jù)支付信息生成電子承諾支付憑證，商戶端根據(jù)該電子承諾支付憑證提供相應的商品/服務。

S105、將電子承諾支付憑證發(fā)給商戶端替客戶端進行信用承諾支付并同步到信息中心服務器。

具體地，本步驟將生成的電子憑證信息發(fā)送給信息中心服務器，以便信息中心服務器進行后繼跟蹤。

本發(fā)明實施例的一種基于同一資金服務器的支付方法，通過資金管理服務器接收客戶端的支付請求信息，根據(jù)買方的賬戶授信貸款額度判斷是否允許支付，同時通過凍結客戶端賬戶的授信貸款額度，并生成電子承諾 支付憑證同步到信息中心服務器進行實時監(jiān)控，能降低資金風險，保障買賣雙方的利益。

S106、資金管理服務器接收解付信息。

資金管理服務器接收并判斷解付信息是否符合約定的解付資金條件。

S107、資金管理服務器判斷并將解付信息同步到信息中心服務器。

S108、如解付信息符合約定的解付資金條件，資金管理服務器將資金劃撥到商戶端的賬戶。

實施例三

如圖3所示，本發(fā)明實施例提供的一種基于同一資金服務器的支付方法，應用于資金管理服務器，該方法包括以下步驟：

S201、資金管理服務器30接收客戶端發(fā)送的支付請求信息，支付請求信息包括支付金額。

具體地，資金管理服務器接收的支付請求信息包括：商戶信息、商品信息和支付金額，還可以包括客戶端信息(如客戶ID)。其中，商戶信息可以直接是商戶收款賬號，也可以唯一標識商戶的信息(如商戶ID)，由資金管理服務器根據(jù)商戶唯一標識從數(shù)據(jù)庫中查找商戶對應的銀行賬號信息。在具體應用中，商戶端的賬戶信息相對客戶端應該是保密的，故商戶信息優(yōu)選為商戶ID，資金管理服務器利用商戶ID與其收款賬號存在對應的關系來查詢商戶的收款賬號。也就是說，客戶端只需告知資金管理服務器向哪個商戶的哪個商品支付多少款項，資金管理服務器便能調出商戶的賬號實施相應的支付操作。

S203、查詢客戶端賬戶的授信貸款額度是否充足，如果不足，執(zhí)行步驟S204，否則執(zhí)行步驟S207；

S204、查詢客戶端賬戶的資金余額是否充足，如果不足，終止本次支付，否則執(zhí)行步驟S207；

具體地，當賬戶授信貸款額度足以支付時，凍結銀行賬戶內支付金額對應的授信貸款額度額度，當賬戶授信貸款額度不足以支付，資金余額足以支付時，凍結客戶端賬戶內支付金額對應的資金余額。本步驟只凍結授信貸款額度或資金余額以確保后繼有足夠的資金完成本次交易，但不并直接劃款到商戶賬號，這樣保障了買賣雙方的利益，后繼可以由客戶端、商 戶端或者物流公司發(fā)送解付信息確認交付完成，由資金管理服務器在接收到解付信息后，將相應金額的資金劃款到商戶賬號。

S207、凍結客戶端賬戶內的支付金額對應的資金或授信透支額度；

S208、生成電子承諾支付憑證；

S209、將電子承諾支付憑證信息發(fā)送給商戶端和信息中心服務器；

S210、商戶端向資金管理服務器發(fā)送接收解付信息；

需要說明的是，本步驟S210中，商戶端向資金管理服務器發(fā)送接收解付信息僅僅是一種舉例，實際應用中，還可以由客戶端、物流服務器或者其他能夠獲知交付狀態(tài)的實體向資金管理服務器發(fā)送解付信息。

S211、資金管理服務器將解付信息同步到信息中心服務器。

具體地，資金管理服務器將更新的電子承諾支付憑證信息同步到信息中心服務器，當商品/服務交付完成后，可以將相應的金額劃款到商戶的賬戶。

S212、將相應數(shù)額的資金劃撥到商戶端的賬戶。

S213、結束流程。

本發(fā)明實施例的支付方法，通過資金管理服務器接收客戶端的支付請求信息，根據(jù)買方的資金余額和授信貸款額度判斷是否允許支付，同時通過凍結客戶端賬戶的資金余額或授信貸款余額，并生成電子承諾支付憑證同步到信息中心服務器進行實時監(jiān)控，能降低資金風險，保障買賣雙方的利益。

實施例四

如圖4所示，本發(fā)明實施例提供的一種基于同一資金服務器的支付方法，應用于資金管理服務器，該方法該包括以下步驟：

S201、資金管理服務器30接收客戶端發(fā)送的支付請求信息，支付請求信息包括支付金額。

具體地，資金管理服務器接收的支付請求信息包括：商戶信息、商品信息和支付金額，還可以包括客戶端信息(如客戶ID)。其中，商戶信息可以直接是商戶收款賬號，也可以唯一標識商戶的信息(如商戶ID)，由資金管理服務器根據(jù)商戶唯一標識從數(shù)據(jù)庫中查找商戶對應的銀行賬號信息。在具體應用中，商戶端的賬戶信息相對客戶端應該是保密的，故商戶信息 優(yōu)選為商戶ID，資金管理服務器利用商戶ID與其收款賬號存在對應的關系來查詢商戶的收款賬號。也就是說，客戶端只需告知資金管理服務器向哪個商戶的哪個商品支付多少款項，資金管理服務器便能調出商戶的賬號實施相應的支付操作。

S203、查詢客戶端賬戶的授信貸款余額是否充足，如果不足，執(zhí)行步驟S205，否則執(zhí)行步驟S207；

S205、查詢客戶端賬戶的授信透支額度是否充足，如果不足，終止本次支付，否則執(zhí)行步驟S207；

具體地，當賬戶授信貸款余額足以支付時，凍結銀行賬戶內支付金額對應的授信貸款余額，當賬戶授信貸款余額不足以支付，授信透支額度足以支付時，凍結銀行賬戶內支付金額對應的授信透支額度。本步驟只凍結授信額度以確保后繼有足夠的額度完成本次交易，但不并直接劃款到商戶賬號，這樣保障了買賣雙方的利益，后繼可以由客戶端、商戶端或者物流公司發(fā)送解付信息確認交付完成，由資金管理服務器在接收到解付信息后，將解凍的資金或與等額的資金劃款到商戶賬號。

S207、凍結客戶端賬戶內的支付金額對應的授信透支額度或授信貸款額度；

S208、生成電子承諾支付憑證；

S209、將電子承諾支付憑證信息發(fā)送給商戶端和信息中心服務器；

S210、商戶端向資金管理服務器發(fā)送接收解付信息；

需要說明的是，本步驟S210中，商戶端向資金管理服務器發(fā)送接收解付信息僅僅是一種舉例，實際應用中，還可以由客戶端、物流服務器或者其他能夠獲知交付狀態(tài)的實體向資金管理服務器發(fā)送解付信息。

S211、資金管理服務器將解付信息同步到信息中心服務器。

具體地，資金管理服務器將更新的電子承諾支付憑證信息同步到信息中心服務器，當商品/服務交付完成后，可以將凍結的資金或等額資金劃款到商戶的賬戶。

S212、將凍結的資金劃撥到商戶端的賬戶。

S213、結束流程。

本發(fā)明實施例的基于凍結授信透支額度或授信貸款余額的支付方法， 通過資金管理服務器接收客戶端的支付請求信息，根據(jù)買方的授信透支額度和授信貸款余額判斷是否允許支付，同時通過凍結客戶端賬戶的支付金額，并生成電子承諾支付憑證同步到信息中心服務器進行實時監(jiān)控，能降低資金風險，保障買賣雙方的利益。

實施例五

如圖5所示，本發(fā)明優(yōu)選實施例提供的一種支付方法，應用于基于同一資金管理服務器的支付系統(tǒng)，該方法包括以下步驟：

S201、客戶端向資金管理服務器發(fā)送支付請求信息，支付請求信息包括支付金額，資金管理服務器接收客戶端發(fā)送的支付請求信息。

其中，支付請求信息由多個數(shù)據(jù)包組成，至少包括商戶信息、商品信息和支付金額。還可以包括客戶端信息(如客戶ID)。其中，商戶信息可以直接是商戶收款賬號，也可以唯一標識商戶的信息(如商戶ID)，由資金管理服務器根據(jù)商戶唯一標識從數(shù)據(jù)庫中查找商戶對應的銀行賬號信息。在具體應用中，商戶端的賬戶信息相對客戶端應該是保密的，故商戶信息優(yōu)選為商戶ID，資金管理服務器利用商戶ID與其收款賬號存在對應的關系來查詢商戶的收款賬號。也就是說，客戶端只需告知資金管理服務器向哪個商戶的哪個商品支付多少款項，資金管理服務器便能調出商戶的賬號實施相應的支付操作。

客戶端向資金管理服務器發(fā)送支付請求信息的方式可以采用現(xiàn)有的方式進行，比如采用數(shù)字簽名或者數(shù)字信封的方式發(fā)送。數(shù)字簽名是指用戶用自己的私鑰對原始數(shù)據(jù)的哈希摘要進行加密所得的數(shù)據(jù)。信息接收者使用信息發(fā)送者的公鑰對附在原始信息后的數(shù)字簽名進行解密后獲得哈希摘要，并通過與自己用收到的原始數(shù)據(jù)產(chǎn)生的哈希摘要對照，便可確信原始信息是否被篡改。這樣就保證了數(shù)據(jù)傳輸?shù)牟豢煞裾J性。數(shù)字信封則采用密碼技術保證了只有規(guī)定的接收人才能閱讀信息的內容。數(shù)字信封中采用了單鑰密碼體制和公鑰密碼體制。信息發(fā)送者首先利用隨機產(chǎn)生的對稱密碼加密信息，再利用接收方的公鑰加密對稱密碼，被公鑰加密后的對稱密碼被稱之為數(shù)字信封。在傳遞信息時，信息接收方要解密信息時，必須先用自己的私鑰解密數(shù)字信封，得到對稱密碼，才能利用對稱密碼解密所得到的信息。這樣就保證了數(shù)據(jù)傳輸?shù)恼鎸嵭院屯暾浴?/p>

S203、查詢客戶端賬戶的授信貸款余額是否充足，如果不足，執(zhí)行步驟S204，否則執(zhí)行步驟S207；

S204、查詢客戶端賬戶的資金余額是否充足，如果不足，執(zhí)行步驟S205，否則執(zhí)行步驟S207；

S205、查詢客戶端賬戶的授信透支額度是否充足，如果不足，終止本次支付，否則執(zhí)行步驟S207；

S207、凍結客戶端賬戶內的支付金額對應的資金或授信透支余額或授信貸款余額；

S208、生成電子承諾支付憑證；

S209、將電子承諾支付憑證信息發(fā)送給商戶端和信息中心服務器；

S210、商戶端向資金管理服務器發(fā)送接收解付信息；

需要說明的是，本步驟S210中，商戶端向資金管理服務器發(fā)送接收解付信息僅僅是一種舉例，實際應用中，還可以由客戶端、物流服務器或者其他能夠獲知交付狀態(tài)的實體向資金管理服務器發(fā)送解付信息。

S211、資金管理服務器將解付信息同步到信息中心服務器。

具體地，資金管理服務器將更新的電子承諾支付憑證信息同步到信息中心服務器，當商品/服務交付完成后，可以將凍結的資金劃款到商戶的賬戶。

S212、將凍結的資金劃撥到商戶端的賬戶。

S213、結束流程。

本發(fā)明實施例，在實施例三的基礎上，通過增加授信額度的可選功能，不僅方便了買方，而且極大豐富了銀行或其它機構的貸款業(yè)務；此外，還通過增加信息中心服務器對買賣雙方的電子承諾支付憑證進行同步跟蹤，將商品的流轉軌跡和資金的流轉軌跡有效的結合，使得買賣雙方的權益均能得到有效保護。

實施例六

如圖6所示，本發(fā)明優(yōu)選實施例提供的一種支付方法，應用于基于同一資金管理服務器的支付系統(tǒng)，該方法包括以下步驟：

S201、客戶端向資金管理服務器發(fā)送支付請求信息，支付請求信息包括支付金額，資金管理服務器接收客戶端發(fā)送的支付請求信息。

其中，支付請求信息由多個數(shù)據(jù)包組成，至少包括商戶信息、商品信息和支付金額。還可以包括客戶端信息(如客戶ID)。其中，商戶信息可以直接是商戶收款賬號，也可以唯一標識商戶的信息(如商戶ID)，由資金管理服務器根據(jù)商戶唯一標識從數(shù)據(jù)庫中查找商戶對應的銀行賬號信息。在具體應用中，商戶端的賬戶信息相對客戶端應該是保密的，故商戶信息優(yōu)選為商戶ID，資金管理服務器利用商戶ID與其收款賬號存在對應的關系來查詢商戶的收款賬號。也就是說，客戶端只需告知資金管理服務器向哪個商戶的哪個商品支付多少款項，資金管理服務器便能調出商戶的賬號實施相應的支付操作。

客戶端向資金管理服務器發(fā)送支付請求信息的方式可以采用現(xiàn)有的方式進行，比如采用數(shù)字簽名或者數(shù)字信封的方式發(fā)送。數(shù)字簽名是指用戶用自己的私鑰對原始數(shù)據(jù)的哈希摘要進行加密所得的數(shù)據(jù)。信息接收者使用信息發(fā)送者的公鑰對附在原始信息后的數(shù)字簽名進行解密后獲得哈希摘要，并通過與自己用收到的原始數(shù)據(jù)產(chǎn)生的哈希摘要對照，便可確信原始信息是否被篡改。這樣就保證了數(shù)據(jù)傳輸?shù)牟豢煞裾J性。數(shù)字信封則采用密碼技術保證了只有規(guī)定的接收人才能閱讀信息的內容。數(shù)字信封中采用了單鑰密碼體制和公鑰密碼體制。信息發(fā)送者首先利用隨機產(chǎn)生的對稱密碼加密信息，再利用接收方的公鑰加密對稱密碼，被公鑰加密后的對稱密碼被稱之為數(shù)字信封。在傳遞信息時，信息接收方要解密信息時，必須先用自己的私鑰解密數(shù)字信封，得到對稱密碼，才能利用對稱密碼解密所得到的信息。這樣就保證了數(shù)據(jù)傳輸?shù)恼鎸嵭院屯暾浴?/p>

S203、查詢客戶端賬戶的授信貸款額度是否充足，如果不足，執(zhí)行步驟S204，否則執(zhí)行步驟S207；

S204、查詢客戶端賬戶的授信透支額度是否充足，如果不足，執(zhí)行步驟S204，否則執(zhí)行步驟S207；

S205、查詢客戶端賬戶的資金余額是否充足，如果不足，終止本次支付，否則執(zhí)行步驟S207；

S207、凍結客戶端賬戶內的支付金額對應的資金或授信透支余額或授信貸款余額；

S208、生成電子承諾支付憑證；

S209、將電子承諾支付憑證信息發(fā)送給商戶端和信息中心服務器；

S210、商戶端向資金管理服務器發(fā)送接收解付信息；

需要說明的是，本步驟S210中，商戶端向資金管理服務器發(fā)送接收解付信息僅僅是一種舉例，實際應用中，還可以由客戶端、物流服務器或者其他能夠獲知交付狀態(tài)的實體向資金管理服務器發(fā)送解付信息。

S211、資金管理服務器將解付信息同步到信息中心服務器。

具體地，資金管理服務器將更新的電子承諾支付憑證信息同步到信息中心服務器，當商品/服務交付完成后，可以將凍結的資金劃款到商戶的賬戶。

S212、將凍結的資金劃撥到商戶端的賬戶。

S213、結束流程。

本發(fā)明實施例，在實施例三的基礎上，通過增加授信額度的可選功能，不僅方便了買方，而且極大豐富了銀行或其它第三方機構的貸款業(yè)務；此外，還通過增加信息中心服務器對買賣雙方的電子承諾支付憑證進行同步跟蹤，將商品的流轉軌跡和資金的流轉軌跡有效的結合，使得買賣雙方的權益均能得到有效保護。

實施例七

如圖7所示，本發(fā)明實施例提供的一種支付裝置，包括接收模塊301、判斷模塊302、處理模塊303，其中：

接收模塊301，設置為接收客戶端發(fā)送的支付請求信息，其中，支付請求信息包括支付金額。

具體地，接收模塊301接收的支付請求信息包括：商戶信息、商品信息和支付金額，還可以包括客戶端信息(如客戶ID)。其中，商戶信息可以直接是商戶收款賬號，也可以唯一標識商戶的信息(如商戶ID)。在具體應用中，商戶端的賬戶信息相對客戶端應該是保密的，故商戶信息優(yōu)選為商戶ID，也就是說，客戶端只需告知資金管理服務器向哪個商戶的哪個商品支付多少款項，由本裝置調出商戶的賬號實施相應的支付操作。

判斷模塊302，設置為根據(jù)客戶端資金余額、授信透支余額或授信貸款余額和支付金額判斷是否允許支付。

作為一種優(yōu)選的方案，判斷模塊302具體設置為：判斷客戶端賬戶的授信貸款余額是否大于或等于支付金額時，如果是，則允許支付；否則進一 步判斷客戶端賬戶資金余額的是否大于或等于支付金額，如果是，則允許支付；否則再進一步判斷賬戶授信透支額度是否大于支付金額，如果是，則允許支付，否則不允許支付。如此，依次判斷賬戶的支付能力，優(yōu)先采用賬戶授信貸款余額支付的方式，可以節(jié)省付款周期，保障商家的利益。其中，客戶端的銀行賬號可以是客戶端在支付請求信息中告知本裝置的，也可以是本裝置根據(jù)客戶端信息從數(shù)據(jù)庫中查詢的，獲取對應賬戶資金余額、信用余額和貸款余額。只有在客戶端的資金余額、授信透支額度、授信貸款額度大于或等于支付金額時，才表示客戶具有進行支付行為的能力，此時才允許進行支付行為。當采用資金管理服務器根據(jù)客戶信息獲取銀行賬號或信用卡賬號時，一個客戶可能有多個賬號，還可以采用混合支付方式。

處理模塊303，設置為當允許支付時，凍結客戶端賬戶內對應的授信透支額度；生成電子承諾支付憑證，將電子承諾支付憑證信息發(fā)送給商戶端，并同步到信息中心服務器。

優(yōu)選地，處理模塊303進一步包括凍結單元3031、憑證生成單元3032和同步單元3033，其中：

凍結單元3031，設置為當允許支付時，凍結客戶端賬戶內的支付金額對應的授信透支額度；

憑證生成單元3032，設置為生成電子承諾支付憑證；

同步單元3033，設置為將電子承諾支付憑證信息發(fā)送給商戶端，并同步到信息中心服務器。

此外，處理模塊303還可以包括劃款單元，設置為接收到解付信息后，將解付信息同步到信息中心服務器，并將對應的資金劃撥到商戶端的賬戶。

需要說明的是，上述方法實施例二和實施例三中的技術特征在本裝置均對應適用，這里不再重述。

此外，本發(fā)明還提供了一種資金管理服務器，該資金管理服務器包括實施例四中的支付裝置，這里不再重述。

本發(fā)明實施例的支付裝置和資金管理服務器，通過接收客戶端的支付請求信息，根據(jù)買方的資金余額、授信貸款額度和授信透支額度判斷是否允許支付，同時通過凍結客戶端賬戶的支付金額，并生成電子承諾支付憑證同步到信息中心服務器進行實時監(jiān)控，能降低資金風險，保障買賣雙方的利益。此外，還通過增加貸款功能，不僅方便了買方，而且極大豐富了銀行或其他具備信用支付能力的機構的業(yè)務。

實施例八

如圖8所示，本發(fā)明優(yōu)選實施例提供的一種基于同一資金服務器的支付系統(tǒng)，該系統(tǒng)包括客戶端10、商戶端20和資金管理服務器30，其中：

客戶端10，包括支付請求模塊101，設置為向資金管理服務器30發(fā)送支付請求信息，其中，支付請求信息包括：商戶信息、商品信息和支付金額。

商戶端20，包括憑證接收模塊201和憑證更新模塊202,其中，憑證接收模塊201設置為接收資金管理服務器30發(fā)送的電子承諾支付憑證。

資金管理服務器30包括接收模塊301、判斷模塊302、和處理模塊303，其中：

接收模塊301，設置為接收客戶端發(fā)送的支付請求信息；

判斷模塊302，設置為根據(jù)客戶端授信透支額度和支付金額判斷是否允許支付；

作為一種優(yōu)選實施例，判斷模塊302設置為：判斷客戶端賬戶的授信貸款額度是否大于或等于支付金額時，如果是，則允許支付；否則進一步判斷客戶端賬戶的資金余額是否大于或等于支付金額，如果是，則允許支付。

處理模塊303，設置為當允許支付時，凍結客戶端賬戶內的支付金額對應的授信貸款額度；生成電子承諾支付憑證，將電子承諾支付憑證信息發(fā)送給商戶端，并同步到信息中心服務器。

作為一種優(yōu)選實施例，資金管理服務器30的接收模塊301還設置為接收解付信息；處理模塊303還包括劃款模塊，設置為接收到解付信息后，將解付信息同步到信息中心服務器，并將凍結的資金劃撥到商戶端的賬戶。

具體地，由于支付請求信息是買方通過客戶端10操作發(fā)送給資金管理服務器30的，其支付信息客觀上是得到了客戶端10確認并授權銀行支付的。資金管理服務器30凍結相應的資金或信用額度，同時將生成根據(jù)支付信息 生成電子承諾支付憑證，商戶端20根據(jù)該電子承諾支付憑證提供相應的商品/服務。

本領域普通技術人員可以理解實現(xiàn)上述實施例方法中的全部或部分步驟是可以通過程序來控制相關的硬件完成，所述的程序可以在存儲于一計算機可讀取存儲介質中，所述的存儲介質，如ROM/RAM、磁盤、光盤等。

以上參照附圖說明了本發(fā)明的優(yōu)選實施例，并非因此局限本發(fā)明的權利范圍。本領域技術人員不脫離本發(fā)明的范圍和實質內所作的任何修改、等同替換和改進，均應在本發(fā)明的權利范圍之內。