CN108280645A - 付款码获取、支付请求响应方法、装置以及设备 - Google Patents

Abstract

本说明书实施例公开了付款码获取、支付请求响应方法、装置以及设备。方案包括：使用户能够自定义付款码的付款额度，付款额度可以是多次累计使用的，也可以限于单次使用，若超过付款额度，可以使付款失败，并引导用户重新指定或者重置付款额度。

Description

付款码获取、支付请求响应方法、装置以及设备

技术领域

本说明书涉及计算机软件技术领域，尤其涉及付款码获取、支付请求响应方法、装置以及设备。

背景技术

智能手机的使用普及给人们的生活带来了便利。通过使用智能手机上的各种应用，能够相应地进行各种业务，很多业务都涉及到支付。

在现有技术中，当用户在商户处消费后，可以向商户展示付款码，通过商户扫描付款码，支付服务端进行相应处理后，完成支付，若付款码泄露，则其关联的支付账户内的全部资金存在被利用该付款码盗用的风险。

基于现有技术，需要更为安全的付款方案。

发明内容

本说明书实施例提供付款码获取、支付请求响应方法、装置以及设备，用以解决如下技术问题：需要更为安全的付款方案。

为解决上述技术问题，本说明书实施例是这样实现的：

本说明书实施例提供的一种付款码获取方法，包括：

第一客户端接收付款码开启指令；

确定用户指定的授权额度；

根据所述授权额度获取付款码，以用于付款，其中，所述付款码的付款额度不超过所述授权额度。

本说明书实施例提供的一种支付请求响应方法，包括：

服务端接收第二客户端通过扫描付款码发送的支付请求，其中，所述付款码的付款额度不超过第一客户端的用户指定的授权额度；

校验所述支付请求对应的消费金额是否将导致所述付款额度用超；

根据校验结果响应所述支付请求。

本说明书实施例提供的一种付款码获取装置，第一客户端位于所述装置，所述装置包括：

接收模块，接收付款码开启指令；

确定模块，确定用户指定的授权额度；

获取模块，根据所述授权额度获取付款码，以用于付款，其中，所述付款码的付款额度不超过所述授权额度。

本说明书实施例提供的一种支付请求响应装置，服务端位于所述装置，所述装置包括：

接收模块，接收第二客户端通过扫描付款码发送的支付请求，其中，所述付款码的付款额度不超过第一客户端的用户指定的授权额度；

校验模块，校验所述支付请求对应的消费金额是否将导致所述付款额度用超；

响应模块，根据校验结果响应所述支付请求。

本说明书实施例提供的一种付款码获取设备，第一客户端位于所述设备，所述设备包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够：

接收付款码开启指令；

确定用户指定的授权额度；

根据所述授权额度获取付款码，以用于付款，其中，所述付款码的付款额度不超过所述授权额度。

本说明书实施例提供的一种支付请求响应设备，服务端位于所述设备，所述设备包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够：

接收第二客户端通过扫描付款码发送的支付请求，其中，所述付款码的付款额度不超过第一客户端的用户指定的授权额度；

校验所述支付请求对应的消费金额是否将导致所述付款额度用超；

根据校验结果响应所述支付请求。

本说明书实施例采用的上述至少一个技术方案能够达到以下有益效果：使用户能够根据自己的使用场景自定义付款码的付款额度，如此能够防范付款码泄露后付款额度之外的资金被盗用的风险，有助于提高利用付款码付款的安全性。

附图说明

为了更清楚地说明本说明书实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本说明书的方案在一种实际应用场景下涉及的一种整体架构示意图；

图2为本说明书实施例提供的一种付款码获取方法的流程示意图；

图3为本说明书实施例提供的一种支付请求响应方法的流程示意图；

图4为本说明书实施例提供的一种实际应用场景下，基于用户自定义付款额度的付款码的支付流程示意图；

图5为本说明书实施例提供的对应于图2的一种付款码获取装置的结构示意图；

图6为本说明书实施例提供的对应于图3的一种支付请求响应装置的结构示意图。

具体实施方式

本说明书实施例提供付款码获取、支付请求响应方法、装置以及设备。

为了使本技术领域的人员更好地理解本说明书中的技术方案，下面将结合本说明书实施例中的附图，对本说明书实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本说明书实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

图1为本说明书的方案在一种实际应用场景下涉及的一种整体架构示意图。该整体架构中，主要涉及三方：作为付款者的用户方(用户及其使用的第一客户端)、作为收款者的商户方(商户及其使用的第二客户端)和支付服务方(服务端)。当然，除了商户方以外，其他用户方也可以作为收款者。

用户方预先自定义付款码的付款额度，然后利用付款码在商户方消费；商户方通过扫描付款码请求支付服务方进行支付处理；支付服务方对付款码进行校验，若将超出付款额度，则可以使支付不成功。

在本说明书实施例中，付款码主要指用于付款的二维码，当然，付款码也可以采用二维码以外的其他数字对象唯一标识符(Digital Object Identifier，DOI)形式，比如，条形码、字符码等。

下面主要基于图1中的架构，对说明书的方案详细说明。

图2为本说明书实施例提供的一种付款码获取方法的流程示意图，执行主体为上述的第一客户端，比如，用户的手机上的支付应用客户端。图2中的流程可以包括以下步骤：

S202：第一客户端接收付款码开启指令。

在本说明书实施例中，付款码开启指令可以用于请求开启付款码功能。付款码功能开启后，可以多次获取付款码(不同次获取的付款码可能相同，也可能不相同)，为了提高安全性，每次获取的付款码可以具有时效性，比如，1分钟内有效等，付款码时效性过期后，需要重新获取付款码。另外，每次开启付款码功能后，付款码功能本身也可以具有时效性，比如，一周内有效等，付款码功能时效性过期后需要重新开启付款码功能。将本段的场景称为第一场景。

在本说明书实施例中，付款码开启指令也可以用于单次地请求获取付款码。在这种情况下，每次获取付款码均需要下达一次付款码开启指令。将本段的场景称为第二场景。

为了便于描述，以下各实施例主要基于第一场景。

S204：确定用户指定的授权额度。

在本说明书实施例中，授权额度可以是用户预先指定的，也可以是每次开启付款码功能时用户实时指定的。

S206：根据所述授权额度获取付款码，以用于付款，其中，所述付款码的付款额度不超过所述授权额度。

在本说明书实施例中，授权额度用于限制付款码的付款额度，若付款码的已付金额将超过付款额度，则可以使支付不成功。

一般地，付款码的付款额度等于授权额度。当然，也可以将授权额度视为用户的心理上限，若支付服务方的安全策略有需要，可以低于授权额度来设定付款码的付款额度。

这里所述的“付款码的付款额度”可以指在每次开启付款码功能后，能够多次获取的付款码的总的付款额度(该多次获取的付款码累计的已付金额不能超过该总的付款额度)；或者，也可以指单次获取的付款码的付款额度(该单次获取的付款码的已付金额不能超过该付款额度)。可以根据实际应用场景，确定“付款码的付款额度”的含义。为了便于描述，以下各实施例主要基于本段中的第一种含义。

目前，用户无法自定义付款额度，若付款码泄露，则其关联的支付账户内的全部资金存在被利用该付款码盗用的风险。而通过图2的方法，使用户能够根据自己的使用场景自定义付款码的付款额度，如此能够防范付款码泄露后付款额度之外的资金被盗用的风险，有助于提高利用付款码付款的安全性。

在本说明书实施例中，付款码可以基于第一客户端与服务端之间的交互，由服务端或者第一客户端生成；付款码也可以由第一客户端不依赖于服务端而在本地直接生成。

基于图2的方法，本说明书实施例还提供了该方法的一些具体实施方案，以及扩展方案，下面进行说明。

在本说明书实施例中，假定用户尚未指定授权额度，则对于步骤S204，所述确定用户指定的授权额度，具体可以包括：展示用户输入界面；获取用户通过所述用户输入界面输入的身份认证信息和作为所述授权额度的金额；对所述身份认证信息和所述金额验证通过，对金额的验证比如包括验证字段格式和取值范围是否正确等。身份认证信息、作为授权额度的金额可以在同一个界面输入，也可以在不同界面输入，输入先后顺序本申请不做限定。

上一段中的具体实施方式并非唯一。比如，身份认证也可以预先进行，而未必要在指定授权额度时进行；再比如，未必以金额作为授权额度，也可以以可付款笔数作为授权额度，每笔的金额限额可以由服务端或者用户预先设定，若可付款笔数较少，比如为1笔，则也可以不对每笔的金额进行限制，因为一般会被用户即时用掉，被盗用的风险较小。

在本说明书实施例中，对于步骤S206，所述根据所述授权额度获取付款码，具体可以包括：接收服务端根据所述授权额度生成并返回的付款码，或者，根据所述授权额度在本地生成所述付款码。

对于上一段中的第一种方式，比如，第一客户端可以将授权额度发送给服务端，以请求获取付款码，服务端根据诸如授权额度、用户的账户标识、当前时间等参数生成付款码，并返回给第一客户端；另外，服务端也可以只是生成并返回付款码应包含的信息，由第一客户端将该信息转换得到付款码。对于上一段中的第二种方式，比如，第一客户端可以在本地根据诸如授权额度、用户的账户标识、当前时间等参数生成付款码，当然，第一客户端在生成付款码后，可以将一些必要信息(比如，付款码本身或者其标识信息等)发送给服务端，以便于服务端后续针对付款码进行支付处理。

另外，前面已经提到，付款码可以具有时效性。第一客户端可以将前次获取的付款码保存在本地，下一次获取时若尚未超出付款码时限，则直接获取本地保存的付款码即可，而无需重新生成，也可以不与服务端进行相应的交互，从而可以节省系统资源。

在本说明书实施例中，当用户需要向商户付款时，可以将第一客户端获取的付款码向商户展示，商户扫描付款码，通过第二客户端向服务端发送相应的支付请求(请求从用户方扣款并付给商户方)，服务端校验对应的消费金额是否将导致付款额度用超，若是，则当前无法支付成功，服务端可以向第一客户端发送指令，以便于引导用户重新指定或者重置付款额度。比如，在第一场景下，具体可以由服务端或者第一客户端引导用户重新开启付款码，以实现授权额度的重新指定或者重置。

上面从第一客户端的角度进行了说明，下面再从服务端的角度进行说明。本说明书实施例还提供了一种支付请求响应方法的流程示意图，如图3所示，执行主体为上述的服务端，比如，上述支付应用客户端对应的支付应用服务端。图3中的流程可以包括以下步骤：

S302：服务端接收第二客户端通过扫描付款码发送的支付请求，其中，所述付款码的付款额度不超过第一客户端的用户指定的授权额度。

S304：校验所述支付请求对应的消费金额是否将导致所述付款额度用超。

S306：根据校验结果响应所述支付请求。

在本说明书实施例中，对于步骤S306，所述根据校验结果响应所述支付请求，具体可以包括：若校验结果为否，则根据所述支付请求，通过所述用户的账户对所述消费金额进行支付，并向所述第二客户端返回支付结果(当然，还可以向第一客户端也返回支付结果)；若校验结果为是，则向所述第二客户端返回相应的提示信息，提示信息比如提示商户支付失败、当前扫描的付款码的付款额度不足等。

在本说明书实施例中，若校验结果为是，还可以提醒用户进行相应操作，消除导致当前支付失败的因素，以便于重新尝试支付。比如，可以向第一客户端发送指令，以便于引导用户重新指定或者重置付款额度等。

根据上面的说明，本说明书实施例还提供了一种实际应用场景下，基于用户指定付款额度的付款码的支付流程示意图，如图4所示。该支付流程也是示例性的，上述方法并不限于这一种具体实施流程。

图4中的流程主要包括以下步骤：

用户在第一客户端点击相应的控件，以开启付款码功能；

第一客户端展示用户输入界面，以便于用户输入作为身份认证信息的支付密码和本次作为授权额度的金额；

第一客户端向服务端请求获取付款额度不超过授权额度的付款码；

服务端生成付款码并返回给第一客户端；

当用户在商户处消费，可以向商户展示付款码，以为消费进行付款；

商户扫描付款码，并通过第二客户端指定消费金额，以及向服务端发起支付请求；

服务端校验本次消费是否将导致付款码的付款额度用超；

若付款额度不将用超，则可以执行支付流程，进而向第一客户端和第二客户端返回支付结果；

若付款额度将用超，则可以向第二客户端返回支付失败，以及引导用户重新开启付款码功能，以实现付款额度的重新指定或者重置。

需要说明的是，在图4的例子中，付款额度是付款码功能开启后的有效期内各付款码的累计额度。比如，假定某次开启付款码功能时，指定的付款额度为1000元，之后，第一次用付款码支付了500元，第二次用付款码支付了400元，则此时付款额度已经用掉了900元(这两次使用的付款码可以相同，也可以不同)，若第三次想用付款码再支付200元，则付款额度将会用超(1100元)，因此，第三次支付会失败。

基于同样的思路，本说明书实施例还提供了上述各方法对应的装置，如图5、图6所示。

图5为本说明书实施例提供的对应于图2的一种付款码获取装置的结构示意图，虚线方框表示可选的模块，第一客户端位于所述装置，所述装置包括：

接收模块501，接收付款码开启指令；

确定模块502，确定用户指定的授权额度；

获取模块503，根据所述授权额度获取付款码，以用于付款，其中，所述付款码的付款额度不超过所述授权额度。

可选地，若所述用户尚未指定所述授权额度，所述确定模块502确定用户指定的授权额度，具体包括：

所述确定模块502展示用户输入界面；

获取用户通过所述用户输入界面输入的身份认证信息和作为所述授权额度的金额；

对所述身份认证信息和所述金额验证通过。

可选地，所述获取模块503根据所述授权额度获取付款码，具体包括：

所述获取模块503接收服务端根据所述授权额度生成并返回的付款码，或者，根据所述授权额度在本地生成所述付款码。

可选地，所述装置还包括：

引导模块504，在所述获取模块503根据所述授权额度获取付款码后，若确定针对所述付款码的支付请求对应的消费金额将导致所述付款额度用超，则引导所述用户重新指定或者重置付款额度。

图6为本说明书实施例提供的对应于图3的一种支付请求响应装置的结构示意图，服务端位于所述装置，所述装置包括：

接收模块601，接收第二客户端通过扫描付款码发送的支付请求，其中，所述付款码的付款额度不超过第一客户端的用户指定的授权额度；

校验模块602，校验所述支付请求对应的消费金额是否将导致所述付款额度用超；

响应模块603，根据校验结果响应所述支付请求。

可选地，所述响应模块603根据校验结果响应所述支付请求，具体包括：

所述响应模块603若校验结果为否，则根据所述支付请求，通过所述用户的账户对所述消费金额进行支付，并向所述第二客户端返回支付结果；

若校验结果为是，则向所述第二客户端返回相应的提示信息。

可选地，若校验结果为是，所述响应模块603还执行：

向所述第一客户端发送指令，以便于引导所述用户重新指定或者重置付款额度。

基于同样的思路，本说明书实施例还提供了对应于图2的一种付款码获取设备，第一客户端位于所述设备，所述设备包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够：

接收付款码开启指令；

确定用户指定的授权额度；

根据所述授权额度获取付款码，以用于付款，其中，所述付款码的付款额度不超过所述授权额度。

基于同样的思路，本说明书实施例还提供了对应于图3的一种支付请求响应设备，服务端位于所述设备，所述设备包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够：

接收第二客户端通过扫描付款码发送的支付请求，其中，所述付款码的付款额度不超过第一客户端的用户指定的授权额度；

校验所述支付请求对应的消费金额是否将导致所述付款额度用超；

根据校验结果响应所述支付请求。

基于同样的思路，本说明书实施例还提供了对应于图2的一种非易失性计算机存储介质，存储有计算机可执行指令，所述计算机可执行指令设置为：

接收付款码开启指令；

确定用户指定的授权额度；

根据所述授权额度获取付款码，以用于付款，其中，所述付款码的付款额度不超过所述授权额度。

基于同样的思路，本说明书实施例还提供了对应于图3的一种非易失性计算机存储介质，存储有计算机可执行指令，所述计算机可执行指令设置为：

接收第二客户端通过扫描付款码发送的支付请求，其中，所述付款码的付款额度不超过第一客户端的用户指定的授权额度；

校验所述支付请求对应的消费金额是否将导致所述付款额度用超；

根据校验结果响应所述支付请求。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于装置、设备、非易失性计算机存储介质实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本说明书实施例提供的装置、设备、非易失性计算机存储介质与方法是对应的，因此，装置、设备、非易失性计算机存储介质也具有与对应方法类似的有益技术效果，由于上面已经对方法的有益技术效果进行了详细说明，因此，这里不再赘述对应装置、设备、非易失性计算机存储介质的有益技术效果。

在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable GateArray，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如ABEL(Advanced Boolean Expression Language)、AHDL(Altera Hardware DescriptionLanguage)、Confluence、CUPL(Cornell University Programming Language)、HDCal、JHDL(Java Hardware Description Language)、Lava、Lola、MyHDL、PALASM、RHDL(RubyHardware Description Language)等，目前最普遍使用的是VHDL(Very-High-SpeedIntegrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。

控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本说明书时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

本领域内的技术人员应明白，本说明书实施例可提供为方法、系统、或计算机程序产品。因此，本说明书实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本说明书实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本说明书是参照根据本说明书实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本说明书实施例可提供为方法、系统或计算机程序产品。因此，本说明书可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本说明书可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本说明书可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

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

Claims (16)

1.一种付款码获取方法，包括：

第一客户端接收付款码开启指令；

确定用户指定的授权额度；

根据所述授权额度获取付款码，以用于付款，其中，所述付款码的付款额度不超过所述授权额度。

2.如权利要求1所述的方法，若所述用户尚未指定所述授权额度，所述确定用户指定的授权额度，具体包括：

展示用户输入界面；

获取用户通过所述用户输入界面输入的身份认证信息和作为所述授权额度的金额；

对所述身份认证信息和所述金额验证通过。

3.如权利要求1所述的方法，所述根据所述授权额度获取付款码，具体包括：

接收服务端根据所述授权额度生成并返回的付款码，或者，根据所述授权额度在本地生成所述付款码。

4.如权利要求1所述的方法，所述根据所述授权额度获取付款码后，所述方法还包括：

若确定针对所述付款码的支付请求对应的消费金额将导致所述付款额度用超，则引导所述用户重新指定或者重置付款额度。

5.一种支付请求响应方法，包括：

服务端接收第二客户端通过扫描付款码发送的支付请求，其中，所述付款码的付款额度不超过第一客户端的用户指定的授权额度；

校验所述支付请求对应的消费金额是否将导致所述付款额度用超；

根据校验结果响应所述支付请求。

6.如权利要求5所述的方法，所述根据校验结果响应所述支付请求，具体包括：

若校验结果为否，则根据所述支付请求，通过所述用户的账户对所述消费金额进行支付，并向所述第二客户端返回支付结果；

若校验结果为是，则向所述第二客户端返回相应的提示信息。

7.如权利要求6所述的方法，若校验结果为是，所述方法还包括：

向所述第一客户端发送指令，以便于引导所述用户重新指定或者重置付款额度。

8.一种付款码获取装置，第一客户端位于所述装置，所述装置包括：

接收模块，接收付款码开启指令；

确定模块，确定用户指定的授权额度；

获取模块，根据所述授权额度获取付款码，以用于付款，其中，所述付款码的付款额度不超过所述授权额度。

9.如权利要求8所述的装置，若所述用户尚未指定所述授权额度，所述确定模块确定用户指定的授权额度，具体包括：

所述确定模块展示用户输入界面；

获取用户通过所述用户输入界面输入的身份认证信息和作为所述授权额度的金额；

对所述身份认证信息和所述金额验证通过。

10.如权利要求8所述的装置，所述获取模块根据所述授权额度获取付款码，具体包括：

所述获取模块接收服务端根据所述授权额度生成并返回的付款码，或者，根据所述授权额度在本地生成所述付款码。

11.如权利要求8所述的装置，所述装置还包括：

引导模块，在所述获取模块根据所述授权额度获取付款码后，若确定针对所述付款码的支付请求对应的消费金额将导致所述付款额度用超，则引导所述用户重新指定或者重置付款额度。

12.一种支付请求响应装置，服务端位于所述装置，所述装置包括：

接收模块，接收第二客户端通过扫描付款码发送的支付请求，其中，所述付款码的付款额度不超过第一客户端的用户指定的授权额度；

校验模块，校验所述支付请求对应的消费金额是否将导致所述付款额度用超；

响应模块，根据校验结果响应所述支付请求。

13.如权利要求12所述的装置，所述响应模块根据校验结果响应所述支付请求，具体包括：

所述响应模块若校验结果为否，则根据所述支付请求，通过所述用户的账户对所述消费金额进行支付，并向所述第二客户端返回支付结果；

若校验结果为是，则向所述第二客户端返回相应的提示信息。

14.如权利要求13所述的装置，若校验结果为是，所述响应模块还执行：

向所述第一客户端发送指令，以便于引导所述用户重新指定或者重置付款额度。

15.一种付款码获取设备，第一客户端位于所述设备，所述设备包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够：

接收付款码开启指令；

确定用户指定的授权额度；

根据所述授权额度获取付款码，以用于付款，其中，所述付款码的付款额度不超过所述授权额度。

16.一种支付请求响应设备，服务端位于所述设备，所述设备包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够：

接收第二客户端通过扫描付款码发送的支付请求，其中，所述付款码的付款额度不超过第一客户端的用户指定的授权额度；

校验所述支付请求对应的消费金额是否将导致所述付款额度用超；

根据校验结果响应所述支付请求。