專利名稱：一種實現(xiàn)支付的系統(tǒng)及方法
技術領域：
本發(fā)明涉及通信和計算機技術領域，特別是指一種實現(xiàn)支付的系統(tǒng)及方法。
背景技術：
目前，各個銀行之間通過4 實現(xiàn)通存通取業(yè)務。 一般情況下，銀行不提 供貨到付款這樣的擔保業(yè)務。如果用戶之間要進行安全的支付，就必須通過提 供安全支付功能的第三方支付平臺進行。參見圖1所示，支付平臺1與支付平臺2都是第三方平臺，支付平臺1與 支付平臺2都為用戶提供服務，由于支付平臺1和2之間沒有做到互通，所以 屬于支付平臺1和支付平臺2的用戶之間需要進行交易，目前沒有提供任何安 全保障。例如提供擔保服務的支付平臺1內部的用戶A和用戶B可以直接 進行安全交易，支付平臺2內部的用戶C和用戶D也可以直接進行安全交易， 但是，支付平臺1內部的用戶和支付平臺2內部的用戶之間，如用戶A和用戶 C之間目前無法進行有安全擔保的交易。綜上所述，目前的支付系統(tǒng)無法實現(xiàn)跨支付平臺進行安全支付，因此，用 戶體驗不好，用戶之間交易非常不方便。發(fā)明內容本發(fā)明的目的是提供一種實現(xiàn)支付的系統(tǒng)及方法，使跨支付平臺的用戶實 現(xiàn)安全支付。本發(fā)明方提供的一種實現(xiàn)支付的方法包括A.第一支付平臺收到第一用戶發(fā)送的含有第二支付平臺信息、第二用戶
賬戶以及金額信息的支付-清求后，判斷本次業(yè)務是否屬于需要擔保的延遲到賬業(yè)務，如果屬于，執(zhí)行步驟B，否則，結束本流程；B. 第一支付平臺將支付款從第一用戶賬戶轉入具有安全保障的賬戶；C. 當?shù)谝恢Ц镀脚_收到第一用戶的到賬請求后，從所述具有安全保障的 賬戶中將款轉給第二用戶賬戶。所述具有安全保障的賬戶為第 一支付平臺的系統(tǒng)賬戶，或第二支付平臺的 系統(tǒng)賬戶。當所述具有安全保障的賬戶為第 一支付平臺的系統(tǒng)賬戶時，步驟B第 一支 付平臺是直接將支付款從第 一用戶賬戶轉入自身的系統(tǒng)賬戶。當所述具有安全保障的賬戶為第二支付平臺的系統(tǒng)賬戶時，并且第一支付 平臺和第二支付平臺之間具有信任關系時，步驟B包括B11 、第一支付平臺從第一用戶賬戶將支付款轉入自身系統(tǒng)的賬戶；B12 、第 一 支付平臺將支付款從自身系統(tǒng)的賬戶中將支付款轉入第二支付 平臺的系統(tǒng)賬戶；B12、第二支付平臺通知第二用戶有未到賬付款。當所述具有安全保障的賬戶為第二支付平臺的系統(tǒng)賬戶，第 一支付平臺和 第二支付平臺之間不具有信任關系時，該方法進一步包括預先為第一支付平臺在第二支付平臺中開設的預存一定資金的私有賬戶， 則步驟B包括B21、第一支付平臺將款從個人賬戶轉入自身的系統(tǒng)賬戶；B22、第一支付平臺確定所述私有賬戶的資金是否充足，如果不足，則第一支付平臺從自身的系統(tǒng)賬戶將所述支付款轉入所述在第二支付平臺中開設的預存一定資金的私有賬戶，否則，執(zhí)行步驟B23;B23、第二支付平臺將款從所述私有賬戶中轉入第二支付平臺的系統(tǒng)賬戶。 當所述具有安全保障的系統(tǒng)賬戶為第一支付平臺的系統(tǒng)賬戶時，步驟C包括Cll、當?shù)谝恢Ц镀脚_收到第一用戶的到賬請求后，將款從自身系統(tǒng)賬戶 中轉入第二支付平臺系統(tǒng)賬戶；C12、笫二支付平臺將款從自身系統(tǒng)賬戶轉入第二用戶賬戶。 當所述具有安全保障的系統(tǒng)賬戶為第二支付平臺的系統(tǒng)賬戶時，步驟C包括C21、當?shù)谝恢Ц镀脚_收到第一用戶的到賬請求后，第一支付平臺通知第 二平臺進行到賬操作；C22、第二支付平臺收到該通知后，從自身的系統(tǒng)賬戶中將款轉入第二用 戶賬戶。在步驟B之后，進一步包4舌當?shù)谝恢Ц镀脚_收到第一用戶的撤銷付款請求后，在第一支付平臺和第二 支付平臺做出撤銷許可后，從所述具有安全保障的賬戶中將支付款轉給第一用 戶賬戶。在步驟A之前，該方法進一步包括Al、第一支付平臺收到該支付請求后，利用第一用戶身份信息對第一用戶 進行認證，如果認證通過，則執(zhí)行步驟A,否則，結束本流程。在步驟A中如果本次業(yè)務不屬于需要擔保的延遲到賬業(yè)務，在結束本流程 之前，該方法進一步包括.-第 一支付平臺將支付款直接轉入第二用戶賬戶。所述具有安全保障的賬戶為催收支付項，在步驟A之前，該方法還進一步 包括Al 、第二支付平臺收到第二用戶的含有第一支付平臺信息、第一用戶賬戶、 金額的催款請求后，向第一支付平臺發(fā)送催款請求；A2、第一支付平臺根據(jù)收到的催款請求，建立催款支付項，并根據(jù)催款支 付項向第一用戶進行催收。當所述催款支付項是在第一支付平臺中建立時，步驟C包括C31 、第 一支付平臺將支付款從催款支付項中轉入第二支付平臺的系統(tǒng)賬戶；C32、第二支付平臺將所述支付款從自身的系統(tǒng)賬戶轉入第二用戶賬戶。步驟A2中所述催款支付項是在第一支付平臺中建立，或在第二支付平臺 在第一支付平臺的私有賬戶中建立。在步驟B和步驟C之間，該方法進一步包括第二支付平臺通知第二用 戶有未到賬的付款。本發(fā)明提供的 一種實現(xiàn)支付的系統(tǒng)包括包括一個以上為用戶提供轉賬業(yè) 務的支付平臺，其特征在于，支付平臺之間彼此相連；其中，第一支付平臺，用于如果本次業(yè)務屬于需要擔保的延遲到賬業(yè)務，根據(jù)收 到第一用戶的含有第二支付平臺信息、第二用戶賬戶、金額的支付請求，將所 述金額的支付款轉入具有安全保障的賬戶；接收并轉發(fā)來自第一用戶的的轉賬 指令；第二支付平臺，用于根據(jù)第一支付平臺的轉賬指令通過所述具有安全保障 的賬戶將支付款轉入笫二用戶賬戶。所述具有安全保障的賬戶為第一支付平臺的系統(tǒng)賬戶，或第二支付平臺的系統(tǒng)賬戶。如果本次業(yè)務不屬于需要擔保的延遲到賬業(yè)務，所述第一支付平臺還用 于將所述金額的支付款直接轉入第二用戶賬戶。所述第 一支付平臺還包括認證單元，用于對接收到的第 一用戶的所述支付 請求中第一用戶身份信息進行認證。所述第二支付平臺還包括通知模塊，用于在第一支付平臺將所述金額的支 付款轉入具有安全保障的賬戶后，通知第二用戶有未到賬的付款，和/或，用于 在支付款轉入第二用戶賬戶后，通知第二用戶支付款轉入成功。通過上述本發(fā)明的技術方案可知，本發(fā)明利用具有安全保障的賬戶實現(xiàn)跨 支付平臺需要進行擔保交易的安全支付問題。在本發(fā)明中，具有安全保障的賬 戶包括即具有信任關系的兩個支付平臺的系統(tǒng)賬戶，不具有信任關系的支付平 臺中 一個支付平臺在另 一個支付平臺的私有賬戶，當交易雙方?jīng)]有達成協(xié)議之 前，從支付用戶賬戶將支付款轉移到具有安全保障的賬戶中，如果交易雙方達 成協(xié)議，再從具有安全保障的賬戶中將所述支付款轉移到收入用戶賬戶。


圖1為現(xiàn)有技術中支付系統(tǒng)的結構示意圖；圖2為為本發(fā)明的系統(tǒng)結構示意圖；圖3為實現(xiàn)本發(fā)明方法的具體實施例一流程示意圖；圖4為實現(xiàn)本發(fā)明方法的具體實施例二流程示意圖；圖5為實現(xiàn)本發(fā)明方法的具體實施例三流程示意圖；圖6為實現(xiàn)本發(fā)明方法的具體實施例四流程示意圖。
具體實施方式
需要i兌明的是，以下將支付用戶稱為第一用戶，支付用戶所屬支付平臺稱 為第一支付平臺，收入用戶稱為第二用戶，收入用戶所屬支付平臺稱為第二支 付平臺。參見圖2所示，實現(xiàn)本發(fā)明的支付系統(tǒng)包括一個以上為用戶提供轉賬業(yè)務 的支付平臺，支付平臺之間彼此相連。其中，第一支付平臺，用于在本次業(yè)務 屬于需要擔保的延遲到賬業(yè)務時，根據(jù)收到第一用戶的含有第二支付平臺信 息、第二用戶賬戶、金額的支付請求，將所述金額的支付款轉入具有安全保障 的賬戶；接收并轉發(fā)來自第一用戶的的轉賬指令；第二支付平臺，用于根據(jù)第 一支付平臺的轉賬指令通知所述具有安全保障的賬戶將支付款轉入第二用戶 賬戶。所述第一支付平臺還包括認證單元，用于對接收到的第一用戶的所述支 付請求中第一用戶身份信息進行認證。當然，如果本次業(yè)務不屬于需要擔保的延遲到賬業(yè)務，所述第一支付平臺
需要將所述金額的支付款直接轉入第二用戶賬戶。所述第二支付平臺還包括通知模塊，用于在第 一支付平臺將所述金額的支 付款轉入具有安全保障的賬戶后，通知第二用戶有未到賬的付款，和/或，用于 在支付款轉入第二用戶賬戶后，通知第二用戶支付款轉入成功。在本發(fā)明中，所述具有安全保障的賬戶為第一支付平臺的系統(tǒng)賬戶，或第 二支付平臺的系統(tǒng)賬戶。下面結合圖2和圖3,以支付方發(fā)起支付請求為實施例一詳細描述本發(fā)明 的技術方案。參見圖3所示，本實施例實現(xiàn)支付的具體過程如下步驟301:第一用戶向第一支付平臺發(fā)送含有第一用戶身份信息、第二支 付平臺信息、第二用戶賬戶以及金額信息的支付請求。步驟302:第一支付平臺收到該支付請求后，利用第一用戶身份信息對第 一用戶進行i人證，如果認證通過，則執(zhí)行步驟303，否則，結束本流程。步驟303:第一支付平臺判斷本次業(yè)務是否屬于需要擔保的延遲到賬業(yè)務， 如果是，則執(zhí)行步驟304,否則，執(zhí)行步驟307。步驟304:第一支付平臺將支付款從第一用戶賬戶轉入第一支付平臺的系 統(tǒng)賬戶，并通知第二支付平臺第一用戶已經(jīng)支付。步驟305:第二支付平臺收到該通知后，再通知第二用戶第一用戶已經(jīng)支付。步驟306:第二用戶收到該通知后，完成和第一用戶約定的交易任務戶。 如果第一用戶同意到賬，通知第一支付平臺進行到賬操作。步驟307:第一支付平臺進行到賬操作，結束本流程。進行到賬操作具體 步驟為第一支付平臺將轉款到第二支付平臺。第二支付平臺將款轉入第二用 戶賬戶，通知第二用戶已到賬。在步驟303中，如果本次業(yè)務屬于需要擔保的延遲到賬業(yè)務，作為替代方 案，步驟304-307可以這樣執(zhí)行第一支付平臺將支付款從第一用戶賬戶轉
入第二支付平臺，第二支付平臺暫存該支付款，然后第二支付平臺通知第二用 戶有未到賬的付款。第二用戶收到該通知后，完成和第一用戶約定的交易任務戶，第一用戶同意到賬，通知第一支付平臺進行到賬操作；第一支付平臺收到 該通知后，通知第二支付平臺進行轉賬操作。第二支付平臺將款轉入第二用戶賬戶。下面結合圖2和圖4,以收入方發(fā)起催款請求為實施例二詳細說明本發(fā)明的技術方案。參見圖4所示，本實施例實現(xiàn)安全支付的具體過程如下步驟401:第二用戶向第二支付平臺發(fā)送催款請求，其中包括第二用戶身份信息、第一支付平臺信息、第一用戶賬戶信息、金額。步驟402:第二支付平臺收到該催款請求后，利用第二用戶身份信息對第二用戶進行認證，如果認證通過，通知第一支付平臺建立催收支付項，否則，結束本流程。步驟403:第一支付平臺收到該通知后，建立催收支付項。 步驟404:第一支付平臺向第一用戶發(fā)送催款通知。 步驟405:第一用戶收到該催款通知后，如果同意支付，則向第一支付平 臺發(fā)送付款請求。步驟406:第一支付平臺收到該付款請求后，判斷本次業(yè)務是否為延遲到賬業(yè)務，如果是，執(zhí)行步驟407,否則，執(zhí)行步驟411。步驟407:第 一支付平臺從第一用戶賬戶將支付款轉入催收支付項。 步驟408:第一支付平臺通知第二支^f十平臺第一用戶已經(jīng)支付。 步驟409:第二支付平臺收到該通知后，再向笫二用戶發(fā)送第一用戶已經(jīng)支付的通知。步驟410:第一用戶和第二用戶完成交易。如果第一用戶同意支付，則向 第 一 支付平臺發(fā)送同意支付的通知。步驟411:第一支付平臺進行到賬操作。第一支付平臺進行到賬操作的步驟可以包括第一支付平臺將款轉入第二支付平臺；第二支付平臺將款轉入第 二用戶賬戶，并通知第二用戶已到賬。步驟410中如果第一用戶不同意支付款項，則向第一支付平臺發(fā)送撤銷付 款的通知，在第一支付平臺和第二支付平臺都做出撤銷許可后，將款從催收支 付項中轉入第一用戶賬戶，結束本流程。在步驟407中，如果本次業(yè)務屬于需要擔保的延遲到賬業(yè)務，作為替代方 案，步驟408~411可以這樣執(zhí)行笫二支付平臺建立催收支付項，再通知第 一支付平臺。當笫一用戶向第一支付平臺發(fā)送同意支付的通知后，第一支付平 臺通知第二支付平臺第 一用戶同意支付，并將支付款從第 一 支付平臺轉入第二 支付平臺催收支付項，第二支付平臺再從催收支付項將支付款轉入第二用戶賬 戶。以下實施例三是以第一支付平臺作為普通用戶在第二支付平臺建立自己 的私有賬戶，并與存有一定資金的情況下，實現(xiàn)支付的方法。下面結合圖2和圖5以支付用戶為發(fā)起方為實施例三詳細說明本發(fā)明的技 術方案。參見圖5所示，本實施例實現(xiàn)安全支付的具體過程如下步驟501:第一用戶向第一支付平臺發(fā)送支付請求，其中含有第一用戶身 份信息、第二支付平臺信息，第二用戶賬戶信息、金額等信息。步驟502:第一支付平臺收到該支付請求后，對第一用戶進行認證，如果 認證通過，則將款從第一用戶賬戶轉入系統(tǒng)賬戶，即第一支付平臺的系統(tǒng)賬戶， 否則，結束本流程。步驟503:第一支付平臺操作自己在第二支付平臺的私有賬戶，將款轉入 第二支付平臺的系統(tǒng)賬戶。步驟504:第二支付平臺判斷本次業(yè)務是否需要安全擔保的延遲到賬，如 果是，執(zhí)行步驟505,否則，第一支付平臺操作自己在第二支付平臺上的私有 賬戶執(zhí)行直接到賬，款立刻匯入第二用戶賬戶，結束本流程。
步驟505:第二支付平臺通知第二用戶第一用戶已經(jīng)支付。步驟506:第一用戶和第二用戶完成交易。如果第一用戶同意支付，第一 用戶向第 一 支付平臺發(fā)送到賬請求。步驟507:第一支付平臺收到該支付請求后，進^f亍轉賬操作。第 一支付平臺進行轉賬操作的步驟可以包括第 一支付平臺向第二支付平 臺發(fā)送到賬通知，第二支付平臺收到該通知后，將款從自身系統(tǒng)賬戶轉入第二 用戶賬戶，最后通知第二用戶轉賬成功。步驟506中如果第一用戶不同意支付，則向第一支付平臺發(fā)送撤銷請求， 在第一支付平臺和第二支付平臺都同意撤銷的情況下，第一支付平臺將款從系 統(tǒng)賬戶轉入第 一用戶賬戶。實施例四是以第二支付平臺作為普通用戶在第一支付平臺建立自己的私 有賬戶，并與存有一定資金的情況下，實現(xiàn)支付的方法。下面結合圖2和圖6以收入用戶為發(fā)起方為實施例四詳細說明本發(fā)明的技 術方案。參見圖6所示，本實施例實現(xiàn)安全支付的具體過程如下步驟601:第二用戶向第二支付平臺發(fā)送催收支付項建立請求，其中包括第二用戶身份信息、第一支付平臺信息、第一用戶賬戶信息、金額等。步驟602:第二支付平臺收到該請求后，對第二用戶進行認證，如果認證通過，通知第一支付平臺建立第二支付平臺在第一支付平臺的私有賬戶到第一用戶的催收支付項。步驟603:第二支付平臺收到該通知后，建立從第二支付平臺私有賬戶到第一用戶賬戶的催收支付項。步驟604:第一支付平臺通知第一用戶有催收款項。步驟605:第一用戶收到該通知后，向第一支付平臺發(fā)送支付請求。步驟606:第一支付平臺收到支付請求后，判斷本次業(yè)務是否屬于延遲到賬類型，如果是，則將款從第一用戶賬戶轉入催收支付項，執(zhí)行步驟607,否
貝'J, ^M亍步驟610。步驟607:第一支付平臺通知第二支付平臺有未到賬的付款。步驟608:笫二支付平臺收到該通知后，通知第二用戶有未到賬的付款。步驟609:第一用戶和第二用戶完成交易。如果第一用戶同意支付，第一用戶向第 一 支付平臺發(fā)送到賬請求。步驟610:第一支付平臺進行到賬操作。即第一支付平臺將款轉入第二支付平臺在第一支付平臺的私有賬戶；第一支付平臺通知第二支付平臺款已經(jīng)到賬；第二支付平臺收到該通知后，從系統(tǒng)賬戶向第二用戶賬戶轉款，并通知第二用戶轉賬已經(jīng)成功。顯然，本領域的技術人員可以對本發(fā)明進行各種改動和變型而不脫離本發(fā) 明的精神和范圍。這樣，倘若本發(fā)明的這些修改和變型屬于本發(fā)明權利要求及 其等同技術的范圍之內，則本發(fā)明也意圖包含這些改動和變型在內。
權利要求
1、一種實現(xiàn)支付的方法，其特征在于，該方法包括以下步驟A.第一支付平臺收到第一用戶發(fā)送的含有第二支付平臺信息、第二用戶賬戶以及金額信息的支付請求后，判斷本次業(yè)務是否屬于需要擔保的延遲到賬業(yè)務，如果屬于，執(zhí)行步驟B，否則，結束本流程；B.第一支付平臺將支付款從第一用戶賬戶轉入具有安全保障的賬戶；C.當?shù)谝恢Ц镀脚_收到第一用戶的到賬請求后，從所述具有安全保障的賬戶中將款轉給第二用戶賬戶。
2、 根據(jù)權利要求1所述的方法，其特征在于，所述具有安全保障的賬戶 為第一支付平臺的系統(tǒng)賬戶，或第二支付平臺的系統(tǒng)賬戶。
3、 根據(jù)權利要求1所述的方法，其特征在于，當所述具有安全保障的賬 戶為第 一支付平臺的系統(tǒng)賬戶時，步驟B第 一支付平臺是直接將支付款從第一 用戶賬戶轉入自身的系統(tǒng)賬戶。
4、 根據(jù)權利要求1所述的方法，其特征在于，當所述具有安全保障的脹 戶為第二支付平臺的系統(tǒng)賬戶時，并且第 一支付平臺和第二支付平臺之間具有 信任關系時，步驟B包括B11 、第一支付平臺將支付款從第一用戶賬戶轉入自身系統(tǒng)的賬戶； B12 、第 一支付平臺將支付款從自身系統(tǒng)的賬戶中將支付款轉入第二支付 平臺的系統(tǒng)賬戶；B12、第二支付平臺通知第二用戶有未到賬付款。
5、 根據(jù)權利要求1所述的方法，其特征在于，當所述具有安全保障的賬 戶為第二支付平臺的系統(tǒng)賬戶，第 一支付平臺和第二支付平臺之間不具有信任 關系時，該方法進一步包括預先為第一支付平臺在第二支付平臺中開設的預存一定資金的私有賬戶， 則步驟B包括B21、第一支付平臺將款從個人賬戶轉入自身的系統(tǒng)賬戶；B22、第一支付平臺確定所述私有賬戶的資金是否充足，如果不足，則第 一支付平臺從自身的系統(tǒng)賬戶將所述支付款轉入所述在第二支付平臺中開設 的預存一定資金的私有賬戶，否則，執(zhí)行步驟B23;B23、第二支付平臺將款從所述私有賬戶中轉入第二支付平臺的系統(tǒng)賬戶。
6、 根據(jù)權利要求1所述的方法，其特征在于，當所述具有安全保障的系統(tǒng)賬戶為第一支付平臺的系統(tǒng)賬戶時，步驟C包括Cll、當?shù)谝恢Ц镀脚_收到第一用戶的到賬請求后，將款從自身系統(tǒng)賬戶 中轉入第二支付平臺系統(tǒng)賬戶；C12、第二支付平臺將款從自身系統(tǒng)賬戶轉入第二用戶賬戶。
7、 根據(jù)權利要求1所述的方法，其特征在于，當所述具有安全保障的系 統(tǒng)賬戶為第二支付平臺的系統(tǒng)賬戶時，步驟C包括C21、當?shù)谝恢Ц镀脚_收到第一用戶的到賬請求后，第一支付平臺通知第 二平臺進行到賬操作；C22、第二支付平臺收到該通知后，從自身的系統(tǒng)賬戶中將款轉入第二用 戶賬戶。
8、 根據(jù)權利要求1所述的方法，其特征在于，在步驟B之后，進一步包括當?shù)谝恢Ц镀脚_收到第一用戶的撤銷付款請求后，在第一支付平臺和第二 支付平臺做出撤銷許可后，從所述具有安全保障的賬戶中將支付款轉給第一用 戶賬戶。
9、 根據(jù)權利要求1所述的方法，其特征在于，在步驟A之前，該方法進 一步包括Al、第一支付平臺收到該支付請求后，利用第一用戶身份信息對第一用戶 進行認證，如果認證通過，則執(zhí)行步驟A,否則，結束本流程。
10、 根據(jù)權利要求1所述的方法，其特征在于，在步驟A中如果本次業(yè)務 不屬于需要擔保的延遲到賬業(yè)務，在結束本流程之前，該方法進一步包括 第 一支付平臺將支付款直接轉入第二用戶賬戶。
11、 根據(jù)權利要求1所述的方法，其特征在于，所述具有安全保障的賬戶為催收支付項，在步驟A之前，該方法還進一步包括Al 、第二支付平臺收到第二用戶的含有第一支付平臺信息、第一用戶賬戶、 金額的催款請求后，向第一支付平臺發(fā)送催款請求；A2、第一支付平臺根據(jù)收到的催款請求，建立催款支付項，并根據(jù)催款支 付項向第一用戶進行催收。
12、 根據(jù)權利要求11所述的方法，其特征在于，當所述催款支付項是在 第一支付平臺中建立時，步驟C包括C31 、第 一支付平臺將支付款從催款支付項中轉入第二支付平臺的系統(tǒng)賬戶；C32、第二支付平臺將所述支付款從自身的系統(tǒng)賬戶轉入第二用戶賬戶。
13、 根據(jù)權利要求11或12所述的方法，其特征在于，步驟A2中所述催 款支付項是在第一支付平臺中建立，或在第二支付平臺在第一支付平臺的私有 賬戶中建立。
14、 根據(jù)權利要求1所述的方法，其特征在于，在步驟B和步驟C之間， 該方法進一步包括第二支付平臺通知第二用戶有未到賬的付款。
15、 一種實現(xiàn)支付的系統(tǒng)，包括一個以上為用戶提供轉賬業(yè)務的支付平臺， 其特征在于，支付平臺之間彼此相連；其中，第一支付平臺，用于如果本次業(yè)務屬于需要擔保的延遲到賬業(yè)務，根據(jù)收 到第一用戶的含有第二支付平臺信息、第二用戶賬戶、金額的支付請求，將所 述金額的支付款轉入具有安全保障的賬戶；接收并轉發(fā)來自第一用戶的轉賬指 令；第二支付平臺，用于根據(jù)第一支付平臺的轉賬指令通過所述具有安全保障 的賬戶將支付款轉入第二用戶賬戶。
16、 根據(jù)權利要求15所述的系統(tǒng)，其特征在于，所述具有安全保障的賬 戶為第 一支付平臺的系統(tǒng)賬戶，或第二支付平臺的系統(tǒng)賬戶。
17、 根據(jù)權利要求15所述的系統(tǒng)，其特征在于，如果本次業(yè)務不屬于需 要擔保的延遲到賬業(yè)務，所迷第一支付平臺還用于將所述金額的支付款直接 轉入第二用戶賬戶。
18、 根據(jù)權利要求15所述的系統(tǒng)，其特征在于，所述第一支付平臺還包 括認證單元，用于對接收到的第一用戶的所述支付請求中第一用戶身份信息進 行認證。
19、 根據(jù)權利要求15所述的系統(tǒng)，其特征在于，所述第二支付平臺還包 括通知模塊，用于在第一支付平臺將所迷金額的支付款轉入具有安全保障的賬 戶后，通知第二用戶有未到賬的付款，和/或，用于在支付款轉入第二用戶賬戶 后，通知第二用戶支付款轉入成功。
全文摘要
本發(fā)明公開了一種實現(xiàn)支付的系統(tǒng)，包括一個以上為用戶提供轉賬業(yè)務的支付平臺，支付平臺之間彼此相連；其中，第一支付平臺，用于如果本次業(yè)務屬于需要擔保的延遲到賬業(yè)務，根據(jù)收到第一用戶的含有第二支付平臺信息、第二用戶賬戶、金額的支付請求，將所述金額的支付款轉入具有安全保障的賬戶；接收并轉發(fā)來自第一用戶的轉賬指令；第二支付平臺，用于根據(jù)第一支付平臺的轉賬指令通過所述具有安全保障的賬戶將支付款轉入第二用戶賬戶。同時，本發(fā)明還公開一種實現(xiàn)支付的方法。應用本發(fā)明，可以實現(xiàn)跨支付平臺的安全支付。
文檔編號G06Q20/00GK101154282SQ20061014065
公開日2008年4月2日 申請日期2006年9月29日 優(yōu)先權日2006年9月29日
發(fā)明者立 王, 錢志龍 申請人:阿里巴巴公司