一种业务处理方法及装置与流程

本申请涉及计算机技术领域，尤其涉及一种业务处理方法及装置。

背景技术：

随着信息技术的发展，在互联网技术的支持下，越来越多的传统业务已逐渐实现网络化，例如：线上到线下的商务模式(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、光学存储器等)上实施的计算机程序产品的形式。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。