本申請涉及計算機技術領域，尤其涉及一種業務處理方法及裝置。

背景技術：

隨著信息技術的發展，在互聯網技術的支持下，越來越多的傳統業務已逐漸實現網絡化，例如：線上到線下的商務模式(onlinetooffline，o2o)。換言之，用戶可以通過互聯網的方式獲取到各類線下業務，如：用戶通過互聯網進行在線訂餐。

目前，在傳統業務網絡化的基礎上，提供業務的用戶(也稱為：提供方用戶)需要將自身的業務發布在業務服務器(如：網站)中，以便于其他的用戶(也稱為：需求方用戶)通過業務服務器，順利的查找并獲取到該提供方用戶所提供的業務。

現有技術中，為了將提供方用戶的業務發布至業務服務器，并且保證發布至業務服務器上的業務能夠正常運行，提供方用戶往往通過獨立軟件開發商(independentsoftwarevendors，isv)將自身的業務進行網絡化。具體而言，isv使用提供方用戶的安全信息(如：私鑰)為提供方用戶提供網絡服務，也即，isv通過持有提供方用戶的安全信息，與業務服務器進行業務交互。

但是，正是由于isv持有了提供方用戶的安全信息，那么，便存在isv以提供方用戶的身份向業務服務器發起非法操作的隱患，一旦isv基于提供方用戶的安全信息發出非法操作，則將會對提供方用戶造成嚴重影響。例如：isv使用提供方用戶的私鑰，針對提供方用戶在某網站的賬戶，發起轉賬請求，對于網站而言，會對該轉賬請求進行校驗，但由于轉賬請求中攜帶提供方用戶的私鑰，導致網站無法確定出該轉賬請求是否由提供方用戶自身發出，從而執行 轉賬操作。顯然，這將給提供方用戶帶來損失。

技術實現要素：

本申請實施例提供一種業務處理方法及裝置，用以解決現有技術中提供方用戶通過isv實現與業務服務器進行業務交互的存在安全隱患的問題。

本申請實施例提供的一種業務處理方法，包括：

業務服務器接收第三方服務器發送的、針對提供方用戶所提供的業務的業務請求；

確定所述業務請求所攜帶的授權信息；其中，所述授權信息是根據提供方用戶預先與所述第三方服務器約定的授權關系及業務權限所生成的；

確定所述授權信息與預先保存的授權信息一致；

校驗所述業務請求是否與所述授權信息對應的業務權限相匹配；

當校驗通過時，調用與所述業務請求對應的業務功能處理該業務請求，生成業務結果。

本申請實施例還提供的一種業務處理方法，包括：

第三方服務器接收針對提供方用戶所提供的業務的業務操作指令；

根據所述業務操作指令，確定與該業務操作指令對應的授權信息，其中，所述授權信息是根據提供方用戶預先與所述第三方服務器約定的授權關系及業務權限所生成的；

根據所述授權信息和業務操作指令，生成業務請求，發送至業務服務器中，以使得所述業務服務器確定所述業務請求所攜帶的授權信息，確定所述授權信息與預先保存的授權信息一致，并校驗所述業務請求是否與所述授權信息對應的業務權限相匹配，在校驗通過后，調用與所述業務請求對應的業務功能處理該業務請求，生成業務結果。

本申請實施例還提供的一種業務處理方法，包括：

接收提供方用戶發送的授權請求；

確定所述授權請求中攜帶的用戶標識、第三方標識以及用戶設定的業務權限信息；

根據用戶標識以及第三方標識，建立提供方用戶與第三方服務器之間的授權關系；

根據建立的授權關系以及用戶設定的業務權限信息，生成授權信息并保存；

將所述授權信息發送至所述第三方標識所對應的第三方服務器。

本申請實施例還提供的一種業務處理裝置，包括：

接收模塊，用于接收第三方服務器發送的、針對提供方用戶所提供的業務的業務請求；

確定模塊，用于確定所述業務請求所攜帶的授權信息；

授權信息確定模塊，用于確定所述授權信息與預先保存的授權信息一致；

校驗模塊，用于校驗所述業務請求是否與所述授權信息對應的業務權限相匹配；

業務處理模塊，用于當校驗通過時，調用與所述業務請求對應的業務功能處理該業務請求，生成業務結果。

本申請實施例還提供的一種業務處理裝置，包括：

接收模塊，用于接收針對提供方用戶所提供的業務的業務操作指令；

確定模塊，用于根據所述業務操作指令，確定與該業務操作指令對應的授權信息；

業務請求模塊，用于根據所述授權信息和業務操作指令，生成業務請求，發送至業務服務器中，以使得所述業務服務器確定所述業務請求所攜帶的授權信息，確定所述授權信息與預先保存的授權信息一致，并校驗所述業務請求是否與所述授權信息對應的業務權限相匹配，在校驗通過后，調用與所述業務請求對應的業務功能處理該業務請求，生成業務結果。

本申請實施例還提供的一種業務處理裝置，包括：

接收模塊，用于接收提供方用戶發送的授權請求；

確定模塊，用于確定所述授權請求中攜帶的用戶標識、第三方標識以及用戶設定的業務權限信息；

授權關系模塊，用于根據用戶標識以及第三方標識，建立提供方用戶與第三方服務器之間的授權關系；

授權信息模塊，用于根據建立的授權關系以及用戶設定的業務權限信息，生成授權信息并保存；

發送模塊，用于將所述授權信息發送至所述第三方標識所對應的第三方服務器。

本申請實施例提供一種業務處理方法及裝置，通過本方法，通過上述步驟，當第三方服務器向業務服務器發出了針對提供方用戶所提供的業務的業務請求后，業務服務器會針對業務請求所攜帶的授權信息進行校驗，這里的授權信息，是提供方用戶與第三方服務器之間預先約定了授權關系和相應的業務權限而生成的，那么，業務服務器將校驗授權信息是否與預先保存的授權信息一致，即校驗攜帶的授權信息的合法性，進一步地，業務服務器會校驗授權信息中的業務權限是否與業務請求相匹配，只有在校驗通過后，業務服務器才會針對該業務請求進行處理，生成相應的處理結果。從上述內容中可見，采用授權信息的方式，保證了提供方用戶無需將自身的安全信息(如：秘鑰)提供給第三方服務器，而只需授權于第三方服務器，并約定相應的業務權限，這樣一來，如果第三方服務器向業務服務器發出相應的業務請求，業務服務器就可以根據授權信息來校驗業務請求是否與授權信息對應的業務權限相匹配，從而可以保證業務服務器不會對第三方服務器私自發出的非法操作進行處理，有效提升了業務處理的安全性。

附圖說明

此處所說明的附圖用來提供對本申請的進一步理解，構成本申請的一部 分，本申請的示意性實施例及其說明用于解釋本申請，并不構成對本申請的不當限定。在附圖中：

圖1為本申請實施例提供的基于業務服務器側的業務處理過程；

圖2a和2b為本申請實施例提供的業務架構示意圖；

圖3為本申請實施例提供的基于第三方服務器側的業務處理過程；

圖4為本申請實施例提供的基于授權設備側的業務處理過程；

圖5為本申請實施例提供的在實際應用場景下的業務處理過程；

圖6為本申請實施例提供的基于業務服務器側的業務處理裝置結構示意圖；

圖7為本申請實施例提供的基于第三方服務器側的業務處理裝置結構示意圖；

圖8為本申請實施例提供的基于授權設備側的業務處理裝置結構示意圖。

具體實施方式

為使本申請的目的、技術方案和優點更加清楚，下面將結合本申請具體實施例及相應的附圖對本申請技術方案進行清楚、完整地描述。顯然，所描述的實施例僅是本申請一部分實施例，而不是全部的實施例。基于本申請中的實施例，本領域普通技術人員在沒有做出創造性勞動前提下所獲得的所有其他實施例，都屬于本申請保護的范圍。

如前所述，正是由于isv持有提供方用戶的安全信息，那么，就存在isv使用提供方用戶的安全信息向業務平臺發起非法操作的可能，一旦isv發起了非法操作，業務平臺并不能有效地判斷出發出該操作的是提供方用戶還是isv，從而會給提供方用戶造成嚴重影響或損失。這就需要一種不使用提供方用戶的安全信息執行業務操作的方式。

基于此，在本申請實施例中，提供了一種業務處理方法，如圖1所示。該方法包括如下步驟：

s101：業務服務器接收第三方服務器發送的、針對提供方用戶所提供的業務的業務請求。

在本申請實施例中，業務服務器具體可以是能夠提供在線業務功能的服務器，如：網站后臺的服務器，其可提供的在線業務功能諸如：在線支付、在線轉賬等。所述的第三方服務器，具體可以是將提供方的線下業務進行網絡化的第三方服務商后臺的服務器，如：isv。可以認為，第三方服務器能夠代理提供方用戶處理相應的業務操作。所述的提供方用戶，具體可以是提供線下業務的提供方，在本申請的一些實施例中，可以認為提供方用戶指代提供方的終端，而在另一些實施例中，可以認為提供方用戶指代提供方服務器，這里并不構成對本申請的限定。

在實際應用場景下，經過第三方服務器進行網絡化之后，其他用戶便可以通過互聯網的方式，使用第三方服務器所發布的業務(這里的業務就是提供方用戶所提供的業務)，在此基礎上，第三方服務器便會向業務服務器發起業務請求，以便完成該業務。故，業務服務器將會接收到來自于第三方服務器的業務請求。

s102：確定所述業務請求所攜帶的授權信息。

其中，所述的授權信息，是提供方用戶與第三方服務器之間預先約定了授權關系、業務權限后生成的信息。換言之，業務請求攜帶著授權信息，就表明此次的業務請求是第三方服務器在提供方用戶的授權下所發出的業務請求。

在實際應用中，授權信息具體可以是授權令牌(token)，并且，授權信息可以由具有授權功能的設備生成，并發送給第三方服務器。在本申請的一些實施例中，業務服務器自身可具有授權功能單元，用以進行授權，并生成授權信息。在本申請的另一些實施例中，可由授權服務器進行授權，并生成授權信息。當然，上述內容并不構成對本申請的限定。

s103：確定所述授權信息與預先保存的授權信息一致。

為了盡可能減少或避免出現第三方服務器私自“冒充”提供方用戶的身份 發出業務請求的現象，業務服務器在獲得了攜帶在業務請求中的授權信息后，將首先校驗該授權信息的合法性。也即，校驗業務請求中攜帶的授權信息，是否與已保存的、第三方服務器和該提供方用戶之間的授權信息一致。若果一致，則可認為該業務請求是第三方服務器代理提供方用戶所發出的。

如果不一致，則極有可能是第三方用戶私自發出，或使用了非法(或過期)的授權信息，那么，作為本申請實施例中的一種方式，業務服務器將拒絕處理該業務請求。這里并不構成對本申請的限定。

s104：校驗所述授權信息對應的業務權限是否與所述業務請求相匹配。

如前所述，授權信息可以反映出提供方用戶與第三方服務器之間約定的業務權限，那么，也就可以根據授權信息來確定出第三方服務器本次發起的業務請求，是否符合授權信息中規定的業務權限，也即，業務服務器會進行校驗。

若校驗結果為不匹配(即，校驗不通過)，就表示第三方服務器所發出的業務請求不符合與提供方用戶之間所約定的業務權限，那么，極有可能是非法操作，從而，業務服務器會拒絕處理該業務請求。

若校驗結果為匹配(即，校驗通過)，則表示第三方服務器所發出的業務請求符合于提供方用戶之間所約定的業務權限，屬于安全的業務請求。

顯然，這樣的方式可以避免第三方服務器私自“冒充”提供方用戶發出某些非法操作。只有當校驗通過后，業務服務器才會執行后續的業務操作。

需要說明的是，對業務請求和授權信息進行校驗的過程而言，既可由業務服務器中的授權功能單元進行校驗，也可由與業務服務器相關聯、且具有授權功能的授權服務器進行校驗。這兩種方式均不構成對本申請的限定。

s105：當校驗通過時，調用與所述業務請求對應的業務功能處理該業務請求，生成業務結果。

校驗通過，則表明第三方服務器所發出的業務請求與授權信息所對應的業務權限相匹配，即，此次的業務請求所對應的業務，屬于第三方服務器與提供方用戶預先約定的業務，從而，業務服務器便會調用與該業務請求所對應的業 務功能，來處理該業務請求，生成相應的業務結果。

通過上述步驟，當第三方服務器向業務服務器發出了針對提供方用戶所提供的業務的業務請求后，業務服務器會針對業務請求所攜帶的授權信息進行校驗，這里的授權信息，是提供方用戶與第三方服務器之間預先約定了授權關系和相應的業務權限而生成的，那么，業務服務器便可以校驗授權信息的合法性，并進一步校驗授權信息的業務權限是否與業務請求相匹配，只有在校驗通過后，業務服務器才會針對該業務請求進行處理，生成相應的處理結果。從上述內容中可見，采用授權信息的方式，保證了提供方用戶無需將自身的安全信息(如：秘鑰)提供給第三方服務器，而只需授權于第三方服務器，并約定相應的業務權限，這樣一來，如果第三方服務器向業務服務器發出相應的業務請求，業務服務器就可以根據授權信息來校驗業務請求是否與授權信息對應的業務權限相匹配，從而可以保證業務服務器不會對第三方服務器私自發出的非法操作進行處理，有效提升了業務處理的安全性。

在實際應用場景中，對于第三方服務器“代理”提供方用戶執行業務操作的方式而言，由于發出業務請求的并非是提供方用戶，而是第三方服務器，那么，業務服務器為了防止第三方服務器發出將會給提供方用戶帶來嚴重安全隱患的業務請求，業務服務器會設置相應的禁用業務功能。所以，在本申請實施例中的一種方式，在確定所述業務請求所攜帶的授權信息之前，上述如圖1所示的方法中，還可以包括：確定所述業務請求所要調用的業務功能，若確定出所要調用的業務功能屬于預設的禁用業務功能，則向所述第三方服務器返回失敗通知。

上述預設的禁用功能，是業務服務器針對第三方服務器所設置的，如：批量轉賬業務、更改賬戶密碼業務等等。顯然，這些業務功能對于提供方用戶而言非常關鍵，通常應由提供方用戶直接進行操作。

可以認為，在上述方式的基礎上，如果第三方服務器所發出的業務請求所要調用的業務功能屬于業務服務器中的禁用功能，那么，可以確定本次業務請 求屬于非法的業務請求，則業務服務器將立即停止對該業務請求的處理，同時反饋給第三方服務器失敗通知。在本申請實施例的一種額外方式中，業務服務器還可以直接通知提供方用戶第三方服務器進行了非法操作。當然，這里并不構成對本申請的限定。

此外，第三方服務器所發出的業務請求中，通常會含有諸如訂單號、支付款項等業務參數，為了保證業務請求發送給業務服務器的過程中，業務參數不被篡改，故在本申請實施例中的一種方式中，業務請求中包含第三方服務器使用自身的秘鑰簽名后的業務參數，在此基礎上，在確定所述業務請求所攜帶的授權信息之前，如圖1所示的方法，還可以包括：所述業務服務器使用預先與所述第三方服務器約定的秘鑰，對簽名后的業務參數進行校驗，并通過校驗。

可以認為，第三方服務器使用自身的秘鑰對業務參數進行簽名，可以防止業務參數被篡改，同時，業務服務器使用預先與第三方服務器約定的秘鑰進行校驗，也可以驗證第三方服務器的合法性。當然，使用秘鑰對業務參數進行簽名，以及使用約定的秘鑰對簽名后的業務參數進行校驗等過程均不構成對本申請的限定，故在此不再過多贅述。

基于前述內容，第三方服務器與業務服務器之間的業務架構可以如圖2a或圖2b所示。其中，在圖2a中，業務服務器內部具有相應的授權功能單元，既可以對第三方服務器進行授權，也可以對授權信息進行校驗。具體來說，在圖2a所述的業務架構的基礎上，校驗所述授權信息對應的業務權限是否與所述業務請求相匹配，具體包括：業務服務器通過運行在該業務服務器中的授權功能單元，根據第三方服務器與提供方用戶之間的約定的業務權限，校驗所述授權信息對應的業務權限是否與所述業務請求相匹配。

而在圖2b中，具有授權功能的授權服務器將獨立于業務服務器，該情況下，由授權服務器對第三方服務器進行授權，校驗時，業務服務器會將授權信息發送給授權服務器進行校驗。具體來說，在圖2b所述的業務架構的基礎上，校驗所述授權信息對應的業務權限是否與所述業務請求相匹配，具體包括：業 務服務器將所述授權信息發送給與該業務服務器相關聯的授權服務器，以使得所述授權服務器根據第三方服務器與提供方用戶之間的約定的業務權限，校驗所述授權信息對應的業務權限是否與所述業務請求相匹配。

當然，上述的兩種方式均不構成對本申請的限定。

此外，需要說明的是，基于如圖1所示的上述方法，在實際應用場景中，業務服務器可以包括：支付服務器。第三方服務器可以包括：isv服務器。業務請求可以為：支付請求。提供方用戶可以為：商戶

在該場景下，商戶(如：超市、餐館等)可通過isv服務器將自身的業務發布在網絡上，從而可以使得其他用戶通過互聯網獲取到相應的業務，該過程中，isv服務器將“代理”商戶進行網絡化業務的相關操作，也就是說，其他用戶將直接與isv服務器進行交互。

例如：isv服務器將某餐館的業務發布至網絡中，形成相應的在線訂餐頁面，此時，其他用戶便可以訪問該在線訂餐頁面進行在線訂餐。當用戶訂餐后，便會向isv服務器發出支付操作，從而，isv服務器就會根據用戶的支付操作，生成支付請求發送給支付服務器。

因此，基于上述的場景，對于上述步驟s101而言，業務服務器接收第三方服務器發送的、針對提供方用戶所提供的業務的業務請求，具體包括：支付服務器接收isv服務器發送的、針對商戶所提供的業務的支付請求。

對于上述步驟s102而言，確定所述業務請求所攜帶的授權信息，具體包括：確定所述支付請求所攜帶的授權信息。

isv服務器在接收到了用戶發出的支付操作后，就會確定出該支付操作所對應的提供方用戶。正如上例，isv服務器會確定用戶的支付操作所對應的餐館(這是因為支付操作中通常會包含餐館的標識信息，這里不作具體限定)。進而，isv服務器會查找出與該餐館之間的授權信息。并攜帶在支付請求中。

對于上述步驟s103而言，校驗所述授權信息對應的業務權限是否與所述業務請求相匹配，具體包括：校驗所述授權信息對應的業務權限是否與支付請 求相匹配。

調用與所述業務請求對應的業務功能處理該業務請求，具體包括：調用與所述支付請求對應的支付業務功能處理該支付請求。

作為本申請示例中的一種方式，授權信息中可以包含商戶的標識信息。基于此，調用與所述支付請求對應的支付業務功能處理該支付請求，具體包括：將所述授權信息中包含的商戶的標識信息，確定為所述支付請求對應的標識信息，調用與所述支付請求對應的支付功能處理該支付請求，并將支付款項發送至具有所述標識信息的賬戶中。

當然，除了上述的支付場景之外，采用本申請實施例中的上述方法，業務服務器在對業務請求進行處理的過程中，均會將提供方用戶作為業務對象，也即，業務服務器將基于提供方用戶的標識信息進行業務處理，基于此，所生成的業務結果也將作為提供方用戶的業務結果(如：上例中將支付金額發送至提供方用戶的賬戶中)。這樣的方式保證了在第三方服務器代理提供方用戶發起業務請求的場景下，提供方用戶可以安全地獲得相應的業務結果。

與上述如圖1所示的方法相對應，對于第三方服務器而言，本申請實施例還提供一種業務處理方法，如圖3所示，具體包括以下步驟：

s301：第三方服務器接收針對提供方用戶所提供的業務的業務操作指令。

正如前述內容，當提供方用戶的業務經過第三方服務器進行網絡化之后，其他用戶(可以是需求方用戶)便可以通過互聯網的方式，使用第三方服務器所發布的業務(這里的業務便是由提供方用戶所提供的)，具體來說：第三方服務器可以將提供方用戶的業務以網頁的方式進行發布(如：在線訂餐網頁)，這樣一來，其他用戶便可以通過該網頁獲得相應的業務(如：進行在線訂餐)，即，在該示例中，用戶將在訂餐網頁中發出訂餐操作，以進行在線訂餐并支付。基于此，業務操作指令，就可以是使用上述業務的需求方用戶所發出的。

s302：根據所述業務操作指令，確定與該業務操作指令對應的授權信息。

其中，所述授權信息是根據提供方用戶預先與所述第三方服務器約定的授權關系及業務權限所生成的。

由于提供方用戶預先授權了第三方服務器處理相應的業務，所以，第三方服務器中會存儲有相應的授權信息。

在實際應用場景下，業務操作指令中通常會包含提供方用戶的標識信息，那么，根據所述業務操作指令，確定與該業務操作指令對應的授權信息，具體可以包括：根據所述標識信息，確定與所述標識信息相匹配的授權信息。

s303：根據所述授權信息和業務操作指令，生成業務請求，發送至業務服務器中，以使得所述業務服務器確定所述業務請求所攜帶的授權信息，并校驗所述業務請求是否與所述授權信息對應的業務權限相匹配，在校驗通過后，調用與所述業務請求對應的業務功能處理該業務請求，生成業務結果。

作為如圖3所示的上述方法的一種方式，在根據所述授權信息和業務操作指令，生成業務請求之前，所述方法還包括：確定所述業務操作指令對應的業務參數，使用預先與所述業務服務器約定的秘鑰對所述業務參數進行簽名。這樣一來，可以保證業務參數不會被篡改。

在此基礎上，根據所述授權信息和業務操作指令，生成業務請求，具體包括：根據所述授權信息、業務操作指令以及簽名后的業務參數，生成業務請求。

在本申請實施例中，提供方用戶可以通過授權服務，授權給相應的第三方服務器，以使得第三方服務器將用戶指定的業務線下網絡化，并“代理”提供方用戶處理相應的在線業務。在此基礎上，本申請實施例中，還提供一種業務處理方法，如圖4所示，具體包括以下步驟：

s401：接收提供方用戶發送的授權請求。

當提供方用戶想要將自身的線下業務進行網絡化時，便可以選擇相應的第三方服務器，并通過具有授權功能的設備對第三方服務器進行授權。也即，提供方用戶會向具有授權功能的設備發送授權請求。當然，授權請求中通常會包 含提供方用戶的用戶信息(如：用戶標識)，及第三方服務器的信息(如：第三方服務器的標識信息)等，這里不作具體限定。

s402：確定所述授權請求中攜帶的用戶標識、第三方標識以及用戶設定的業務權限信息。

在本申請實施例中，所述的用戶標識，可以是提供方用戶的用戶信息，所述的第三方標識，可以是第三方服務器的信息，而且，提供方用戶通常會設定相應的業務權限，用以規定第三方服務器在“代理”提供方執行業務操作時所具有的權限。

s403：根據用戶標識以及第三方標識，建立提供方用戶與第三方服務器之間的授權關系。

s404：根據建立的授權關系以及用戶設定的業務權限信息，生成授權信息并保存。

s405：將所述授權信息發送至所述第三方標識所對應的第三方服務器。

通過以上的授權過程，第三方服務器便可獲得授權信息，以便在實際的業務處理過程中，使用該授權信息“代理”提供方用戶執行相應的業務操作。

作為本申請實施例中的一種方式，上述的授權過程可以基于oauth授權協議實現，具體過程不在此贅述。

此外，提供方用戶還可以取消與第三方服務器之間的授權關系，也即，上述如圖4所示的方法還可以包括：接收所述提供方用戶發送的、針對所述第三方服務器的授權解除請求，根據所述授權解除請求，解除所述提供方用戶與該第三方服務器之間的授權關系，并撤銷所述授權信息。

通過上述的解除授權過程，第三方服務器便不能為提供方用戶“代理”業務。

當然，上述內容可由運行在業務服務器中的授權功能單元實現，或由具有授權功能的授權服務器實現，這里并不構成對本申請的限定。

結合上述如圖1、圖3及圖4所示的方法，為了清楚地說明上述內容，現以業務服務器為支付服務器、第三方服務器為isv服務器、業務請求為支付請求的場景進行詳細描述。

假設在該場景中，提供方用戶為餐館a，該餐館a通過isv，將該餐館a所提供的點餐服務網絡化，并授權給isv代理在線點餐服務。此時假設，消費者b(需求方用戶)通過isv進行在線點餐，并發出支付操作指令。基于此，具體的業務處理流程如圖5所示：

s501：消費者b向isv發出支付操作指令。

s502：isv根據支付操作指令，確定出餐館a的標識信息，并根據該標識信息，確定出預先與該餐館a之間的授權信息。

s503：isv根據支付操作指令和授權信息，生成支付請求，發送給支付服務器。

s504：支付服務器將支付請求中攜帶的授權信息發送給授權服務器進行校驗。

在此假設，餐館a已將支付請求的處理權限授權給了isv。那么，授權服務器便會通過校驗。

s505：授權服務器返回校驗通過結果。

s506：支付服務器將將授權信息中包含的餐館a的標識信息，確定為支付請求對應的標識信息，并調用支付功能處理該支付請求，將支付款項發送至餐館a。

s507：通知isv支付請求處理成功。

當然，上述示例僅是為了說明本方法中的業務處理流程，并不作為對本申請的限定。

以上為本申請實施例提供的業務處理方法，基于同樣的思路，本申請實施例還提供一種業務處理裝置，如圖6所示，所述裝置包括：

接收模塊601，用于接收第三方服務器發送的、針對提供方用戶所提供的業務的業務請求。

確定模塊602，用于確定所述業務請求所攜帶的授權信息。

授權信息確定模塊603，用于確定所述授權信息與預先保存的授權信息一致。

校驗模塊604，用于校驗所述業務請求是否與所述授權信息對應的業務權限相匹配。

業務處理模塊605，用于當校驗通過時，調用與所述業務請求對應的業務功能處理該業務請求，生成業務結果。

作為本申請實施例中的一種方式，所述裝置還包括：業務檢測模塊606，用于在所述確定模塊執行前，確定所述業務請求所要調用的業務功能，若確定出所要調用的業務功能屬于預設的禁用業務功能，則向所述第三方服務器返回失敗通知。

作為本申請實施例中的一種方式，所述裝置還包括：簽名認證模塊607，用于在所述確定模塊執行前，使用預先與所述第三方服務器約定的秘鑰，對簽名后的業務參數進行校驗，并通過校驗。其中，簽名后的業務參數是所述業務請求中攜帶的。

在本申請實施例中，所述授權信息中包含所述第三方服務器與提供方用戶之間約定的業務權限。基于此，校驗模塊604，具體用于根據第三方服務器與提供方用戶之間的約定的業務權限，校驗所述授權信息對應的業務權限是否與所述業務請求相匹配；或，將所述授權信息發送給與該業務服務器相關聯的授權服務器，以使得所述授權服務器根據第三方服務器與提供方用戶之間的約定的業務權限，校驗所述授權信息對應的業務權限是否與所述業務請求相匹配。

在一種實際應用場景中，第三方服務器包括isv服務器，業務請求為支付請求，提供方用戶為商戶，該場景下，

接收模塊601，具體用于接收isv服務器發送的、針對商戶所提供的業務 的支付請求。

確定模塊602，具體用于確定所述支付請求所攜帶的授權信息。

校驗模塊604，具體用于校驗所述授權信息對應的業務權限是否與支付請求相匹配。

業務處理模塊605，具體用于調用與所述支付請求對應的支付業務功能處理該支付請求。

進一步地，授權信息中包含商戶的標識信息，那么，進一步地，業務處理模塊605，具體用于將所述授權信息中包含的商戶的標識信息，確定為所述支付請求對應的標識信息，調用與所述支付請求對應的支付功能處理該支付請求，并將支付款項發送至具有所述標識信息的賬戶中。

如圖7所示，本申請實施例還提供一種業務處理裝置，所述裝置包括：

接收模塊701，用于接收針對提供方用戶所提供的業務的業務操作指令。

確定模塊702，用于根據所述業務操作指令，確定與該業務操作指令對應的授權信息。

業務請求模塊703，用于根據所述授權信息和業務操作指令，生成業務請求，發送至業務服務器中，以使得所述業務服務器確定所述業務請求所攜帶的授權信息，確定所述授權信息與預先保存的授權信息一致，并校驗所述業務請求是否與所述授權信息對應的業務權限相匹配，在校驗通過后，調用與所述業務請求對應的業務功能處理該業務請求，生成業務結果。

作為本實施例中的一種方式，業務操作指令中包含提供方用戶的標識信息，基于此，確定模塊702，具體用于根據所述標識信息，確定與所述標識信息相匹配的授權信息。

作為本實施例中的一種方式，所述裝置還包括：簽名模塊704，用于在所述確定模塊執行前，確定所述業務操作指令對應的業務參數，使用預先與所述業務服務器約定的秘鑰對所述業務參數進行簽名。

那么，進一步地，業務請求模塊703，具體用于根據所述授權信息、業務操作指令以及簽名后的業務參數，生成業務請求。

如圖8所示，本申請實施例還提供一種業務處理裝置，所述裝置包括：

接收模塊801，用于接收提供方用戶發送的授權請求。

確定模塊802，用于確定所述授權請求中攜帶的用戶標識、第三方標識以及用戶設定的業務權限信息。

授權關系模塊803，用于根據用戶標識以及第三方標識，建立提供方用戶與第三方服務器之間的授權關系。

授權信息模塊804，用于根據建立的授權關系以及用戶設定的業務權限信息，生成授權信息并保存。

發送模塊805，用于將所述授權信息發送至所述第三方標識所對應的第三方服務器。

作為本實施例中的一種方式，所述裝置還包括：解除模塊806，用于接收所述提供方用戶發送的、針對所述第三方服務器的授權解除請求，根據所述授權解除請求，解除所述提供方用戶與該第三方服務器之間的授權關系，并撤銷所述授權信息。

在一個典型的配置中，計算設備包括一個或多個處理器(cpu)、輸入/輸出接口、網絡接口和內存。

內存可能包括計算機可讀介質中的非永久性存儲器，隨機存取存儲器(ram)和/或非易失性內存等形式，如只讀存儲器(rom)或閃存(flashram)。內存是計算機可讀介質的示例。

計算機可讀介質包括永久性和非永久性、可移動和非可移動媒體可以由任何方法或技術來實現信息存儲。信息可以是計算機可讀指令、數據結構、程序的模塊或其他數據。計算機的存儲介質的例子包括，但不限于相變內存(pram)、靜態隨機存取存儲器(sram)、動態隨機存取存儲器(dram)、其 他類型的隨機存取存儲器(ram)、只讀存儲器(rom)、電可擦除可編程只讀存儲器(eeprom)、快閃記憶體或其他內存技術、只讀光盤只讀存儲器(cd-rom)、數字多功能光盤(dvd)或其他光學存儲、磁盒式磁帶，磁帶磁磁盤存儲或其他磁性存儲設備或任何其他非傳輸介質，可用于存儲可以被計算設備訪問的信息。按照本文中的界定，計算機可讀介質不包括暫存電腦可讀媒體(transitorymedia)，如調制的數據信號和載波。

還需要說明的是，術語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、商品或者設備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、商品或者設備所固有的要素。在沒有更多限制的情況下，由語句“包括一個……”限定的要素，并不排除在包括所述要素的過程、方法、商品或者設備中還存在另外的相同要素。

本領域技術人員應明白，本申請的實施例可提供為方法、系統或計算機程序產品。因此，本申請可采用完全硬件實施例、完全軟件實施例或結合軟件和硬件方面的實施例的形式。而且，本申請可采用在一個或多個其中包含有計算機可用程序代碼的計算機可用存儲介質(包括但不限于磁盤存儲器、cd-rom、光學存儲器等)上實施的計算機程序產品的形式。

以上所述僅為本申請的實施例而已，并不用于限制本申請。對于本領域技術人員來說，本申請可以有各種更改和變化。凡在本申請的精神和原理之內所作的任何修改、等同替換、改進等，均應包含在本申請的權利要求范圍之內。