本申請(qǐng)涉及互聯(lián)網(wǎng)應(yīng)用技術(shù)領(lǐng)域，尤其涉及一種基于權(quán)限分離控制的網(wǎng)絡(luò)交易方法及裝置。

背景技術(shù)：

在網(wǎng)絡(luò)交易的過(guò)程中，對(duì)于買方用戶而言，“下單”和“支付”是兩種最基本的操作，其中“下單”是指買方用戶選擇并確定待購(gòu)買商品的操作，“支付”則是指買方用戶針對(duì)已確定的待購(gòu)買商品，向賣方用戶轉(zhuǎn)出相應(yīng)額度資金的過(guò)程。

一般而言，“下單”和“支付”都是由同一用戶完成，然而在有些情況下，可能會(huì)存在“下單”和“支付”由不同用戶完成的需求。例如在企業(yè)采購(gòu)的應(yīng)用場(chǎng)景中，根據(jù)企業(yè)內(nèi)部的職權(quán)分配，應(yīng)該是由采購(gòu)員進(jìn)行下單、由老板或財(cái)務(wù)負(fù)責(zé)人完成支付?，F(xiàn)有的網(wǎng)絡(luò)交易系統(tǒng)并不能很好地滿足上述實(shí)際需求，從而導(dǎo)致用戶使用不便，還會(huì)造成系統(tǒng)資源的不必要消耗。

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

針對(duì)上述技術(shù)問(wèn)題，本申請(qǐng)?zhí)峁┮环N基于權(quán)限分離控制的網(wǎng)絡(luò)交易方法及裝置，技術(shù)方案如下：

一種基于權(quán)限分離控制的網(wǎng)絡(luò)交易方法，應(yīng)用于交易系統(tǒng)側(cè)，預(yù)先建立并保存不同賬戶之間的綁定關(guān)系，任意兩個(gè)相互綁定賬戶的一方至少具有買方用戶下單權(quán)限，另一方至少具有買方用戶支付權(quán)限，所述網(wǎng)絡(luò)交易方法包括：

接收第一賬戶提交的訂單；

根據(jù)預(yù)存的綁定關(guān)系，確定與第一賬戶綁定的第二賬戶；

針對(duì)所述第一賬戶提交的訂單，向第二賬戶發(fā)起支付請(qǐng)求；

等待第二賬戶確認(rèn)所述支付請(qǐng)求后，確定所述訂單支付成功。

一種基于權(quán)限分離控制的網(wǎng)絡(luò)交易裝置，應(yīng)用于交易系統(tǒng)側(cè)，預(yù)先建立并保存不同賬戶之間的綁定關(guān)系，任意兩個(gè)相互綁定賬戶的一方至少具有買方用戶下單權(quán)限，另一方至少具有買方用戶支付權(quán)限，所述網(wǎng)絡(luò)交易裝置包括：

訂單接收模塊，用于接收第一賬戶提交的訂單；

支付賬戶確定模塊，用于根據(jù)預(yù)存的綁定關(guān)系，確定與第一賬戶綁定的第二賬戶；

支付請(qǐng)求發(fā)起模塊，用于針對(duì)所述第一賬戶提交的訂單，向第二賬戶發(fā)起支付請(qǐng)求；

支付確定模塊，用于等待第二賬戶確認(rèn)所述支付請(qǐng)求后，確定所述訂單支付成功。

本申請(qǐng)所提供的技術(shù)方案，通過(guò)采用買方用戶下單權(quán)限及支付權(quán)限的分離機(jī)制，允許在一筆交易中，由不同的賬戶分別完成下單和支付操作，從而避免多名用戶使用同一賬戶所導(dǎo)致的使用不便問(wèn)題，同時(shí)有效降低系統(tǒng)側(cè)資源的不必要消耗。

應(yīng)當(dāng)理解的是，以上的一般描述和后文的細(xì)節(jié)描述僅是示例性和解釋性的，并不能限制本申請(qǐng)。

附圖說(shuō)明

為了更清楚地說(shuō)明本申請(qǐng)實(shí)施例或現(xiàn)有技術(shù)中的技術(shù)方案，下面將對(duì)實(shí)施例或現(xiàn)有技術(shù)描述中所需要使用的附圖作簡(jiǎn)單地介紹，顯而易見(jiàn)地，下面描述中的附圖僅僅是本申請(qǐng)中記載的一些實(shí)施例，對(duì)于本領(lǐng)域普通技術(shù)人員來(lái)講，還可以根據(jù)這些附圖獲得其他的附圖。

圖1是本申請(qǐng)的網(wǎng)絡(luò)交易方法的流程示意圖；

圖2是本申請(qǐng)的網(wǎng)絡(luò)交易裝置的結(jié)構(gòu)示意圖。

具體實(shí)施方式

為了使本領(lǐng)域技術(shù)人員更好地理解本申請(qǐng)中的技術(shù)方案，下面將結(jié)合本申請(qǐng)實(shí)施例中的附圖，對(duì)本申請(qǐng)實(shí)施例中的技術(shù)方案進(jìn)行詳細(xì)地描述，顯然，所描述的實(shí)施例僅僅是本申請(qǐng)一部分實(shí)施例，而不是全部的實(shí)施例?；诒旧暾?qǐng)中的實(shí)施例，本領(lǐng)域普通技術(shù)人員所獲得的所有其他實(shí)施例，都應(yīng)當(dāng)屬于本申請(qǐng)保護(hù)的范圍。

首先需要說(shuō)明的是，在本申請(qǐng)中，以“用戶”指代真實(shí)的操作者，例如采購(gòu)員和財(cái)務(wù)負(fù)責(zé)人分別為不同的用戶；“賬戶”則表示網(wǎng)絡(luò)中的虛擬身份標(biāo)識(shí)，真實(shí)的用戶在網(wǎng)絡(luò)中的活動(dòng)都是以“賬戶”的行為體現(xiàn)的，實(shí)際應(yīng)用中，盡管多個(gè)真實(shí)用戶使用同一賬戶的情況是允許的，但是這樣也會(huì)導(dǎo)致使用上的不便。

現(xiàn)有的網(wǎng)絡(luò)交易體系主要是針對(duì)獨(dú)立的買家用戶設(shè)計(jì)，也就是說(shuō)，默認(rèn)一筆交易中的下單和支付都是由同一人完成。但是，在這種機(jī)制下，針對(duì)背景技術(shù)中提到的下單和支付由不同人完成的需求場(chǎng)景，則需要下單人員和支付人員使用同一交易賬戶完成各自的操作，這樣在實(shí)際使用時(shí)，下單人員提交訂單后，或者要找來(lái)支付人員在當(dāng)前設(shè)備上完成支付，或者以電話等方式告知支付人員，再由支付人員在其他設(shè)備上以同一賬戶登錄并完成支付。

可見(jiàn)，由于“用戶”的實(shí)際權(quán)限與“賬戶”所具有的權(quán)限不一致，因此需要采取多用戶共用同一賬戶這樣的“非常規(guī)”的方式來(lái)解決問(wèn)題，但是無(wú)論采用哪種方式，用戶的實(shí)際操作過(guò)程都很繁瑣。而且由于是多人共同使用同一賬戶，那么難免會(huì)出現(xiàn)無(wú)法同時(shí)使用、操作沖突、反復(fù)登錄等各類問(wèn)題，影響工作效率。對(duì)于系統(tǒng)側(cè)而言，也會(huì)因此而增加很多額外處理，例如錯(cuò)誤提示、身份認(rèn)證等，造成處理資源的不必要浪費(fèi)。

針對(duì)現(xiàn)有技術(shù)所存在的問(wèn)題，本申請(qǐng)?zhí)峁┑募夹g(shù)方案是，允許為不同的賬戶配置不同的買方操作權(quán)限，包括下單權(quán)限、支付權(quán)限等，并且對(duì)具有不同操作權(quán)限的賬戶進(jìn)行綁定。在實(shí)際進(jìn)行交易時(shí)，具有綁定關(guān)系的賬戶可以協(xié)同完成一筆交易操作，這樣就有效避免了多人共享同一賬戶所導(dǎo)致的各種問(wèn)題。

假設(shè)在一家小型企業(yè)中，A為采購(gòu)員、B為財(cái)務(wù)主管，那么根據(jù)本申請(qǐng)方案，在交易系統(tǒng)中，可以為用戶A和用戶B分別注冊(cè)不同的賬戶，假設(shè)所注冊(cè)的賬戶標(biāo)識(shí)分別為ID_a和ID_b，其中賬戶ID_a具有買方用戶的下單權(quán)限，賬戶ID_b具有買方用戶的支付權(quán)限。然后進(jìn)一步建立賬戶ID_a和賬戶ID_b的綁定關(guān)系，并在交易系統(tǒng)側(cè)進(jìn)行保存。這里建立綁定關(guān)系的意義在于：在當(dāng)前交易系統(tǒng)中，允許被綁定的兩個(gè)賬戶共同作為買方來(lái)協(xié)作完成同一筆交易。

圖1所示，為本申請(qǐng)?zhí)峁┑木W(wǎng)絡(luò)交易方法的交互流程圖，這里需要說(shuō)明的是，圖中涉及的交互主體：賬戶ID_a和賬戶ID_b，既可以理解為邏輯上的交互主體，即交易系統(tǒng)中軟件體系中“賬戶”對(duì)象的兩個(gè)具體實(shí)例，也可以理解為實(shí)際的用戶設(shè)備，例如當(dāng)前正在使用賬戶登錄的手機(jī)、PC機(jī)等等；“交易系統(tǒng)”也可以理解為廣義上的用于完成網(wǎng)絡(luò)交易的軟件及硬件平臺(tái)，這些并不影響對(duì)本申請(qǐng)方案的說(shuō)明。

S101，賬戶ID_a向交易系統(tǒng)提交訂單；

根據(jù)前面的說(shuō)明，賬戶ID_a是具有下單權(quán)限的賬戶，正常情況下，該賬戶由實(shí)際執(zhí)行下單任務(wù)的用戶(例如采購(gòu)員)使用，這里假設(shè)由采購(gòu)員A使用賬戶ID_a，采購(gòu)員A電商平臺(tái)選定待購(gòu)商品的型號(hào)、樣式、數(shù)量、商家等等，通過(guò)特定操作以生成相應(yīng)的訂單并提交至交易系統(tǒng)，為方便描述，后續(xù)將以X標(biāo)識(shí)該訂單，該訂單中除了攜帶待購(gòu)商品的相關(guān)信息之外，還應(yīng)攜帶提交賬戶的標(biāo)識(shí)即ID_a，表明該訂單是由賬戶ID_a提交。

S102，根據(jù)預(yù)存的綁定關(guān)系，確定與賬戶ID_a綁定的賬戶；

交易系統(tǒng)接收到一筆訂單后，首先解析出該訂單的提交賬戶標(biāo)識(shí)，然后進(jìn)一步根據(jù)預(yù)先存儲(chǔ)的賬戶綁定關(guān)系，確定與訂單提交賬戶綁定的賬戶，具體而言，是確定與“具有下單權(quán)限的賬戶”相綁定的“具有支付權(quán)限的賬戶”。

在本實(shí)施例中，訂單X的下單賬戶為ID_a，根據(jù)預(yù)存的綁定信息，可以確定與賬戶ID_a綁定的賬戶為賬戶ID_b。

S103，針對(duì)賬戶ID_a提交的訂單，向賬戶ID_a的綁定賬戶發(fā)起支付請(qǐng)求；

根據(jù)本申請(qǐng)方案，并不要求同一筆交易中的下單和支付必須由同一賬戶完成，在本實(shí)施例中，針對(duì)訂單X，由于賬戶ID_a不具有支付權(quán)限，因此后續(xù)的支付操作將轉(zhuǎn)交給與其綁定和賬戶ID_b來(lái)完成。

向綁定賬戶發(fā)起支付請(qǐng)求可以采用多種方式實(shí)現(xiàn)，例如通過(guò)交易系統(tǒng)內(nèi)部的消息系統(tǒng)向?qū)?yīng)賬戶發(fā)送通知消息，如果目標(biāo)賬戶關(guān)聯(lián)了其他的聯(lián)系方式，例如郵件、短信、即時(shí)通信等，也可以通過(guò)這些渠道向目標(biāo)賬戶發(fā)送通知消息，以便目標(biāo)賬戶對(duì)應(yīng)的真實(shí)用戶能夠盡快看到通知并完成支付。

為了方便支付用戶使用，可以在通知消息中進(jìn)一步提供用于確認(rèn)支付請(qǐng)求的快捷操作入口，例如在通知消息的消息體中加入能夠直接跳轉(zhuǎn)至訂單信息界面、支付確認(rèn)界面的鏈接、或者在通知消息的消息體中直接加入支付二維碼、等等。為了滿足支付用戶的審核訂單需求，也可以在通知消息的消息體中或者支付確認(rèn)界面中加入訂單的詳細(xì)信息或摘要信息。

可以理解的是，不同的真實(shí)用戶之間原本也可以不依賴交易系統(tǒng)所提供的功能來(lái)進(jìn)行溝通，因此“主動(dòng)通知”并不是交易系統(tǒng)所必須的功能。

S104～S105，賬戶ID_b確認(rèn)支付請(qǐng)求，交易系統(tǒng)確定訂單支付成功。

賬戶ID_b確認(rèn)訂單X完成相應(yīng)金額支付后，交易系統(tǒng)會(huì)接收到相關(guān)的確認(rèn)信息，進(jìn)而可以確定該訂單已經(jīng)支付成功，可以進(jìn)一步轉(zhuǎn)入后續(xù)發(fā)貨、配送等流程。

本申請(qǐng)方案與現(xiàn)有技術(shù)相比，一方面，允許針對(duì)不同的買方賬戶配置不同的操作權(quán)限，以便于將賬戶權(quán)限與現(xiàn)實(shí)中的人員職能相匹配，保證虛擬的賬戶與現(xiàn)實(shí)用戶的一一對(duì)應(yīng)關(guān)系；另一方面，通過(guò)建立不同賬戶的綁定關(guān)系，使得具有綁定關(guān)系的賬戶可以協(xié)同完成一筆交易操作。不同職能的用戶分別使用不同的賬戶，各司其職，可以有效避免操作沖突、反復(fù)登錄等各類問(wèn)題，提升整體的工作效率。對(duì)于系統(tǒng)側(cè)而言，也可以相應(yīng)減少如錯(cuò)誤提示、身份認(rèn)證等額外處理，減少處理資源的不必要消耗。

在上面的實(shí)施例中，僅以“1個(gè)下單賬戶與1個(gè)支付賬戶的綁定”對(duì)本申請(qǐng)的基本方案進(jìn)行示意性說(shuō)明，而在本申請(qǐng)的其他實(shí)施方式中，對(duì)于綁定關(guān)系還可以進(jìn)行更為靈活的配置，以滿足各種復(fù)雜的使用需求，下面將進(jìn)一步舉例說(shuō)明。

根據(jù)本申請(qǐng)方案，對(duì)于相互綁定的兩個(gè)賬戶，一方應(yīng)至少具有買方用戶的下單權(quán)限，另一方則至少具有買方用戶的支付權(quán)限。但這并不意味著只允許每個(gè)賬戶具有一種買方用戶權(quán)限，例如對(duì)于前述的賬戶ID_a和賬戶ID_b，可以配置令賬戶ID_a僅具有下單權(quán)限、賬戶ID_b同時(shí)具有下單權(quán)限和支付權(quán)限，這樣對(duì)應(yīng)的一種現(xiàn)實(shí)需求可以是：采購(gòu)員使用賬戶ID_a，只能下單不能支付，老板則使用賬戶ID_b，既可以審核并支付采購(gòu)員下的訂單，也可以自己下單。

相應(yīng)地，在前述步驟S102，交易系統(tǒng)在接收到一筆訂單、并且解析出該訂單的提交賬戶標(biāo)識(shí)后，可以先判斷該賬戶是否具有支付權(quán)限，如果不具有，再進(jìn)一步根據(jù)預(yù)存的綁定關(guān)系，確定與該賬戶綁定的賬戶；而如果訂單提交賬戶具有支付權(quán)限(例如上述的賬戶ID_b)，則可以按照傳統(tǒng)的正常交易流程進(jìn)行，即由同一賬戶完成下單與支付。

可以理解的是，在交易系統(tǒng)中，一個(gè)賬戶除了買方下單權(quán)限和買方支付權(quán)限，還可以包括其他各種權(quán)限，這些與本申請(qǐng)方案無(wú)關(guān)，不再做展開(kāi)說(shuō)明。

另外，根據(jù)本申請(qǐng)方案，每組綁定關(guān)系對(duì)應(yīng)的賬戶數(shù)量為2個(gè)，但是對(duì)于任意一個(gè)賬戶而言，允許存在多組綁定關(guān)系，即一個(gè)賬戶可以綁定多個(gè)其他賬戶，例如：

一個(gè)具有支付權(quán)限的賬戶綁定多個(gè)具有下單權(quán)限的賬戶：

這種綁定配置對(duì)應(yīng)的現(xiàn)實(shí)需求可以是：多個(gè)采購(gòu)員可以各自使用自己的專屬賬戶下訂單，統(tǒng)一交給負(fù)責(zé)人審核并支付。不難想象，如果采用現(xiàn)有技術(shù)的多人共用同一賬戶的方案，實(shí)際使用起來(lái)將會(huì)非常麻煩，而應(yīng)用本申請(qǐng)的方案，將一個(gè)具有支付權(quán)限的賬戶分別與多個(gè)具有下單權(quán)限的賬戶進(jìn)行綁定，則可以很方便地實(shí)現(xiàn)上述需求。

一種典型的配置方案是，設(shè)立主賬戶-子賬戶體系，一個(gè)主賬戶可以在其名下開(kāi)通多個(gè)子賬戶，子賬戶和主賬戶之間自動(dòng)建立綁定關(guān)系，主賬戶用戶可以增減子賬戶數(shù)量、修改子賬戶的權(quán)限，從而滿足現(xiàn)實(shí)使用中的管理需求。例如，主賬戶具有支付權(quán)限，可以供老板、財(cái)務(wù)負(fù)責(zé)人等使用，在該主賬戶名下，可以開(kāi)通多個(gè)具有下單權(quán)限的子賬戶，以供多位采購(gòu)員使用。在這種配置方式下，各采購(gòu)員可以分別以子賬戶進(jìn)行采購(gòu)，所下訂單信息都會(huì)匯總至主賬戶，由相關(guān)負(fù)責(zé)人對(duì)這些訂單進(jìn)行統(tǒng)一審核并支付。

一個(gè)具有下單權(quán)限的賬戶綁定多個(gè)具有支付權(quán)限的賬戶：

這種綁定配置對(duì)應(yīng)的現(xiàn)實(shí)需求可以是：一個(gè)采購(gòu)員為多個(gè)不同的部門進(jìn)行采購(gòu)，相應(yīng)需要不同的負(fù)責(zé)人審核訂單并確認(rèn)支付。

在這種綁定配置關(guān)系下，由于一筆訂單的支付賬戶不唯一，因此需要在提交的訂單中攜帶一個(gè)指定的具有支付權(quán)限賬戶的標(biāo)識(shí)，以供交易系統(tǒng)確定由哪個(gè)賬戶來(lái)完成當(dāng)前訂單的支付。當(dāng)然，對(duì)于訂單中攜帶的具有支付權(quán)限賬戶的標(biāo)識(shí)，交易系統(tǒng)可以進(jìn)一步核查訂單提交賬戶與其指定的支付賬戶是否具有綁定關(guān)系。另外，交易系統(tǒng)也可以在訂單提交之前，根據(jù)綁定關(guān)系，將與當(dāng)前下單賬戶綁定的多個(gè)支付賬戶的信息提供給當(dāng)前下單賬戶，以方便其直接選擇?？傊?，交易系統(tǒng)可以根據(jù)預(yù)存的綁定信息以及訂單中攜帶的賬戶標(biāo)識(shí)，共同確定向哪個(gè)賬戶發(fā)出當(dāng)前訂單的支付請(qǐng)求。

例如，具有下單權(quán)限的賬戶ID_a分別綁定了三個(gè)具有支付權(quán)限的賬戶：ID_b1、ID_b2、ID_b3，則在賬戶ID_a下單時(shí)，交易系統(tǒng)可以將ID_b1、ID_b2、ID_b3以列表形式顯示在訂單確認(rèn)界面中，并要求下單用戶選擇其中之一作為當(dāng)前訂單的支付賬戶，假設(shè)下單用戶選擇了ID_b2，則“ID_b2”將作為附加信息攜帶在訂單中，后續(xù)交易系統(tǒng)會(huì)直接將該筆訂單的支付請(qǐng)求發(fā)送至賬戶ID_b2。

根據(jù)本申請(qǐng)方案，賬戶之間的綁定關(guān)系可以在注冊(cè)賬戶階段指定，也可以在賬戶注冊(cè)完成后根據(jù)實(shí)際使用需求指定或修改。

另外，可以理解的是，本申請(qǐng)實(shí)例中所述的“交易系統(tǒng)”是指廣義上的用于完成網(wǎng)絡(luò)交易的軟件及硬件，并不應(yīng)理解為某個(gè)具體物理設(shè)備或電商平臺(tái)。例如，在使用第三方支付的交易體系下，“交易系統(tǒng)”實(shí)際可以從功能上劃分為電商平臺(tái)和支付平臺(tái)兩部分，其中電商平臺(tái)主要用于完成與“下單”相關(guān)的功能，支付平臺(tái)則主要用于完成與“支付”相關(guān)的功能。對(duì)應(yīng)于本申請(qǐng)方案的改進(jìn)流程如下：第一賬戶首先將訂單提交至電商平臺(tái)；電商平臺(tái)通過(guò)支付平臺(tái)向第二賬戶發(fā)起支付請(qǐng)求；第二賬戶在支付平臺(tái)完成支付后，支付平臺(tái)將支付成功信息反饋至電商平臺(tái)，電商平臺(tái)確定該比訂單支付完成，可以進(jìn)入后續(xù)的發(fā)貨、配送等流程。

這里需要說(shuō)明的是，電商平臺(tái)和支付平臺(tái)可能使用不同的賬戶系統(tǒng)，但是一個(gè)真實(shí)用戶在電商平臺(tái)的賬戶和在支付平臺(tái)的賬戶也應(yīng)該是具有跨平臺(tái)綁定(注意該“綁定”與本申請(qǐng)方案中的“綁定”含義不同)關(guān)系的。因此，本申請(qǐng)方案中兩個(gè)賬戶之間的綁定，可以是電商平臺(tái)內(nèi)部?jī)蓚€(gè)賬戶的綁定、支付平臺(tái)內(nèi)部?jī)蓚€(gè)賬戶的綁定、也可以是一個(gè)電商平臺(tái)賬戶與一個(gè)支付平臺(tái)賬戶的綁定；相應(yīng)地，綁定關(guān)系可以存儲(chǔ)在電商平臺(tái)內(nèi)部，也可以存儲(chǔ)在支付平臺(tái)內(nèi)部，或者以某種方式在兩個(gè)平臺(tái)之間交換、同步等，本領(lǐng)域技術(shù)人員可以根據(jù)實(shí)際需求靈活配置。

相應(yīng)于上述方法實(shí)施例，本申請(qǐng)還提供一種基于權(quán)限分離控制的網(wǎng)絡(luò)交易裝置，該裝置配置于交易系統(tǒng)側(cè)，參見(jiàn)圖2所示，該裝置可以包括：

綁定關(guān)系存儲(chǔ)模塊110，用于存儲(chǔ)預(yù)先建立的不同賬戶之間的綁定關(guān)系，任意兩個(gè)相互綁定賬戶的一方至少具有買方用戶下單權(quán)限，另一方至少具有買方用戶支付權(quán)限；

訂單接收模塊120，用于接收第一賬戶提交的訂單；

支付賬戶確定模塊130，用于根據(jù)預(yù)存的綁定關(guān)系，確定與第一賬戶綁定的第二賬戶；

支付請(qǐng)求發(fā)起模塊140，用于針對(duì)第一賬戶提交的訂單，向第二賬戶發(fā)起支付請(qǐng)求；

支付確定模塊150，用于等待第二賬戶確認(rèn)支付請(qǐng)求后，確定訂單支付成功。

在本申請(qǐng)的一種具體實(shí)施方式中，支付賬戶確定模塊130可以具體用于：

判斷第一賬戶是否具有支付權(quán)限，如果否，則進(jìn)一步根據(jù)預(yù)存的綁定關(guān)系，確定與第一賬戶綁定的第二賬戶。

在本申請(qǐng)的一種具體實(shí)施方式中，支付請(qǐng)求發(fā)起模塊140可以具體用于：

利用交易系統(tǒng)內(nèi)部消息，向第二賬戶發(fā)送支付請(qǐng)求通知消息；

或

利用第二賬戶的關(guān)聯(lián)聯(lián)系方式，向第二賬戶發(fā)送支付請(qǐng)求通知消息。

在本申請(qǐng)的一種具體實(shí)施方式中，可以在支付通知消息中，提供用于確認(rèn)支付請(qǐng)求的快捷操作入口。

在本申請(qǐng)的一種具體實(shí)施方式中，不同賬戶之間的綁定關(guān)系，可以包括：

一個(gè)具有支付權(quán)限的賬戶綁定多個(gè)具有下單權(quán)限的賬戶，

或

一個(gè)具有下單權(quán)限的賬戶綁定多個(gè)具有支付權(quán)限的賬戶。

在本申請(qǐng)的一種具體實(shí)施方式中，在一個(gè)具有下單權(quán)限的賬戶綁定多個(gè)具有支付權(quán)限的賬戶的情況下，第一賬戶提交的訂單中，可以攜帶指定的具有支付權(quán)限賬戶的標(biāo)識(shí)；

相應(yīng)地，支付賬戶確定模塊150可以具體用于：根據(jù)預(yù)存的綁定信息以及標(biāo)識(shí)，共同確定與第一賬戶綁定的第二賬戶。

通過(guò)以上的實(shí)施方式的描述可知，本領(lǐng)域的技術(shù)人員可以清楚地了解到本申請(qǐng)可借助軟件加必需的通用硬件平臺(tái)的方式來(lái)實(shí)現(xiàn)?；谶@樣的理解，本申請(qǐng)的技術(shù)方案本質(zhì)上或者說(shuō)對(duì)現(xiàn)有技術(shù)做出貢獻(xiàn)的部分可以以軟件產(chǎn)品的形式體現(xiàn)出來(lái)，該計(jì)算機(jī)軟件產(chǎn)品可以存儲(chǔ)在存儲(chǔ)介質(zhì)中，如ROM/RAM、磁碟、光盤等，包括若干指令用以使得一臺(tái)計(jì)算機(jī)設(shè)備(可以是個(gè)人計(jì)算機(jī)，服務(wù)器，或者網(wǎng)絡(luò)設(shè)備等)執(zhí)行本申請(qǐng)各個(gè)實(shí)施例或者實(shí)施例的某些部分所述的方法。

本說(shuō)明書(shū)中的各個(gè)實(shí)施例均采用遞進(jìn)的方式描述，各個(gè)實(shí)施例之間相同相似的部分互相參見(jiàn)即可，每個(gè)實(shí)施例重點(diǎn)說(shuō)明的都是與其他實(shí)施例的不同之處。尤其，對(duì)于裝置實(shí)施例而言，由于其基本相似于方法實(shí)施例，所以描述得比較簡(jiǎn)單，相關(guān)之處參見(jiàn)方法實(shí)施例的部分說(shuō)明即可。以上所描述的裝置實(shí)施例僅僅是示意性的，其中所述作為分離部件說(shuō)明的模塊可以是或者也可以不是物理上分開(kāi)的，在實(shí)施本申請(qǐng)方案時(shí)可以把各模塊的功能在同一個(gè)或多個(gè)軟件和/或硬件中實(shí)現(xiàn)。也可以根據(jù)實(shí)際的需要選擇其中的部分或者全部模塊來(lái)實(shí)現(xiàn)本實(shí)施例方案的目的。本領(lǐng)域普通技術(shù)人員在不付出創(chuàng)造性勞動(dòng)的情況下，即可以理解并實(shí)施。

以上所述僅是本申請(qǐng)的具體實(shí)施方式，應(yīng)當(dāng)指出，對(duì)于本技術(shù)領(lǐng)域的普通技術(shù)人員來(lái)說(shuō)，在不脫離本申請(qǐng)?jiān)淼那疤嵯?，還可以做出若干改進(jìn)和潤(rùn)飾，這些改進(jìn)和潤(rùn)飾也應(yīng)視為本申請(qǐng)的保護(hù)范圍。