WO2019137357A1

WO2019137357A1 - Payment code acquisition and payment request response method, apparatus and device

Info

Publication number: WO2019137357A1
Application number: PCT/CN2019/070795
Authority: WO
Inventors: 胡宗旺
Original assignee: 阿里巴巴集团控股有限公司
Priority date: 2018-01-12
Filing date: 2019-01-08
Publication date: 2019-07-18
Also published as: TW201931244A; CN108280645A

Abstract

Provided are a payment code acquisition and payment request response method, apparatus and device. By means of the method, apparatus and device, a user can customize a payment limit for a payment code; the payment limit can be used accumulatively multiple times, and can also be limited to a single use; and if the payment limit is exceeded, payment can be caused to fail, and a user can be guided to re-appoint or reset the payment limit.

Description

Payment code acquisition, payment request response method, device and device

Technical field

The present specification relates to the field of computer software technologies, and in particular, to a payment code acquisition method, a payment request response method, a device, and a device.

Background technique

The popularity of smartphones has brought convenience to people's lives. By using various applications on the smartphone, various services can be performed correspondingly, and many businesses involve payment.

In the prior art, after the user consumes at the merchant, the payment code can be displayed to the merchant, and the payment code is scanned by the merchant, and the payment server performs corresponding processing to complete the payment. If the payment code is leaked, the associated payment account is The entire funds are at risk of being stolen by the payment code.

Based on the prior art, a more secure payment scheme is needed.

Summary of the invention

The embodiment of the present specification provides a payment code acquisition, a payment request response method, a device, and a device, to solve the following technical problem: a more secure payment scheme is needed.

In order to solve the above technical problem, the embodiment of the present specification is implemented as follows:

A method for obtaining a payment code provided by an embodiment of the present disclosure includes:

The first client receives the payment code opening instruction;

Determine the authorization amount specified by the user;

Obtaining a payment code according to the authorization amount for payment, wherein the payment amount of the payment code does not exceed the authorization amount.

A payment request response method provided by an embodiment of the present disclosure includes:

The server receives the payment request sent by the second client by scanning the payment code, where the payment amount of the payment code does not exceed the authorization amount specified by the user of the first client;

Verifying whether the amount of consumption corresponding to the payment request will cause the payment amount to be exceeded;

Responding to the payment request based on the verification result.

The payment code obtaining device provided by the embodiment of the present specification, the first client is located in the device, and the device includes:

Receiving module, receiving a payment code opening instruction;

Determining a module to determine a user-specified authorization amount;

The obtaining module obtains a payment code according to the authorization amount for payment, wherein the payment amount of the payment code does not exceed the authorization amount.

A payment request response device is provided in the embodiment of the present specification, where the server is located in the device, and the device includes:

The receiving module receives a payment request sent by the second client by scanning the payment code, where the payment amount of the payment code does not exceed the authorization amount specified by the user of the first client;

a verification module, verifying whether the amount of consumption corresponding to the payment request will cause the payment amount to be exceeded;

The response module responds to the payment request according to the verification result.

A payment code acquiring device is provided in the embodiment of the present specification, where the first client is located in the device, and the device includes:

At least one processor; and,

a memory communicatively coupled to the at least one processor; wherein

The memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to:

Receiving a payment code opening instruction;

Determine the authorization amount specified by the user;

A payment request response device is provided in the embodiment of the present disclosure, where the server is located in the device, and the device includes:

At least one processor; and,

a memory communicatively coupled to the at least one processor; wherein

Receiving, by the second client, a payment request sent by scanning a payment code, where the payment amount of the payment code does not exceed a user-specified authorization amount of the first client;

Responding to the payment request based on the verification result.

The at least one technical solution adopted by the embodiment of the present specification can achieve the following beneficial effects: enabling the user to customize the payment amount of the payment code according to the usage scenario, so as to prevent the risk of misappropriation of funds other than the payment amount after the payment code is leaked. To help improve the security of payment by payment code.

DRAWINGS

In order to more clearly illustrate the embodiments of the present specification or the technical solutions in the prior art, the drawings to be used in the embodiments or the description of the prior art will be briefly described below. Obviously, the drawings in the following description are only It is a few embodiments described in the present specification, and other drawings can be obtained from those skilled in the art without any inventive labor.

FIG. 1 is a schematic diagram of an overall architecture involved in an implementation scenario of the present specification;

2 is a schematic flowchart of a method for acquiring a payment code according to an embodiment of the present disclosure;

FIG. 3 is a schematic flowchart of a method for responding to a payment request according to an embodiment of the present disclosure;

4 is a schematic diagram of a payment process of a payment code based on a user-defined payment amount in an actual application scenario according to an embodiment of the present disclosure;

FIG. 5 is a schematic structural diagram of a payment code acquiring apparatus corresponding to FIG. 2 according to an embodiment of the present disclosure;

FIG. 6 is a schematic structural diagram of a payment request response apparatus corresponding to FIG. 3 according to an embodiment of the present disclosure.

Detailed ways

Embodiments of the present specification provide a payment code acquisition, a payment request response method, apparatus, and device.

In order to make those skilled in the art better understand the technical solutions in the present specification, the technical solutions in the embodiments of the present specification will be clearly and completely described in the following with reference to the accompanying drawings in the embodiments of the specification. The embodiments are only a part of the embodiments of the present application, and not all of them. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments of the present specification without departing from the inventive scope shall fall within the scope of the application.

FIG. 1 is a schematic diagram of an overall architecture involved in an implementation scenario of the present specification. In the overall architecture, there are mainly three parties: the user side as the payer (the user and the first client used by the user), the merchant party as the payee (the merchant and the second client used by the merchant), and the payment service party ( Server). Of course, in addition to the merchant side, other users can also act as payees.

The user side pre-customizes the payment amount of the payment code, and then uses the payment code to consume on the merchant side; the merchant side requests the payment service party to perform payment processing by scanning the payment code; the payment service party checks the payment code, and if the payment amount is exceeded, Then the payment can be made unsuccessful.

In the embodiment of the present specification, the payment code mainly refers to a two-dimensional code for payment. Of course, the payment code may also be in the form of a Digital Object Identifier (DOI) other than the two-dimensional code, for example, a barcode, Character code, etc.

The following is a detailed description of the scheme of the specification based on the architecture in FIG.

FIG. 2 is a schematic flowchart of a method for obtaining a payment code according to an embodiment of the present disclosure. The execution entity is the first client, for example, a payment application client on a user's mobile phone. The process in Figure 2 can include the following steps:

S202: The first client receives the payment code opening instruction.

In the embodiment of the present specification, the payment code opening instruction may be used to request to open the payment code function. After the payment code function is enabled, the payment code can be obtained multiple times (the payment codes obtained in different times may be the same or different). In order to improve security, the payment code obtained each time can be time-sensitive, for example, valid within 1 minute. After the time limit of the payment code expires, you need to re-acquire the payment code. In addition, each time the payment code function is turned on, the payment code function itself can also be time-sensitive. For example, it is valid within one week, and the payment code function needs to be re-opened after the time limit of the payment code function expires. The scene in this paragraph is called the first scene.

In the embodiment of the present specification, the payment code opening instruction may also be used to request the payment code in a single request. In this case, each time you get a payment code, you need to issue a payment code open command. The scene in this paragraph is called the second scene.

For ease of description, the following embodiments are mainly based on the first scenario.

S204: Determine a user-specified authorization amount.

In the embodiment of the present specification, the authorization amount may be pre-specified by the user, or may be specified by the user in real time each time the payment code function is turned on.

S206: Obtain a payment code according to the authorization amount for payment, wherein the payment amount of the payment code does not exceed the authorization amount.

In the embodiment of the present specification, the authorization amount is used to limit the payment amount of the payment code, and if the payment amount of the payment code will exceed the payment amount, the payment may be unsuccessful.

In general, the payment amount of the payment code is equal to the authorization amount. Of course, the authorization amount can also be regarded as the psychological upper limit of the user. If the payment security policy of the service party is required, the payment amount of the payment code can be set below the authorization amount.

The "payment amount of the payment code" described herein may refer to the total payment amount of the payment code that can be acquired multiple times after the payment code function is turned on (the accumulated payment amount of the multiple acquired payment code cannot exceed the amount) The total payment amount); or, may also refer to the payment amount of the payment code obtained in a single time (the paid amount of the single-acquisition payment code cannot exceed the payment amount). The meaning of the "payment amount of the payment code" can be determined according to the actual application scenario. For ease of description, the following embodiments are primarily based on the first meaning in this paragraph.

At present, the user cannot customize the payment amount. If the payment code is leaked, all the funds in the associated payment account are at risk of being stolen by the payment code. Through the method of FIG. 2, the user can customize the payment amount of the payment code according to the usage scenario, so that the risk of the funds other than the payment amount after the payment code is leaked can be prevented, and the payment by the payment code can be improved. safety.

In the embodiment of the present specification, the payment code may be generated by the server or the first client based on the interaction between the first client and the server; the payment code may also be localized by the first client without depending on the server. Generated directly.

Based on the method of FIG. 2, the embodiments of the present specification further provide some specific implementations of the method, and an extended solution, which will be described below.

In the embodiment of the present specification, it is assumed that the user has not specified the authorization quota, and the determining the authorization quota specified by the user may specifically include: displaying a user input interface; and acquiring identity authentication information input by the user through the user input interface. And as the amount of the authorization amount; verifying the identity authentication information and the amount, and verifying the amount includes, for example, whether the verification field format and the value range are correct. The identity authentication information and the amount of the authorization amount can be input in the same interface, or can be input in different interfaces. The input sequence is not limited in this application.

The specific implementation in the previous paragraph is not unique. For example, the identity authentication can also be carried out in advance, and it is not necessary to specify the authorization amount; for example, the amount may not be used as the authorization amount, or the number of payment can be used as the authorization amount, and the amount of each amount may be determined by the server or The user pre-sets, if the number of payables is small, for example, one pen, it is also possible not to limit the amount of each pen, because it is generally used by the user immediately, and the risk of being stolen is small.

In the embodiment of the present specification, for the step S206, the obtaining the payment code according to the authorization amount may include: receiving a payment code generated and returned by the server according to the authorization quota, or locally according to the authorization quota. Generate the payment code.

For the first mode in the previous paragraph, for example, the first client may send the authorization quota to the server to request the payment code, and the server generates the payment code according to parameters such as the authorization quota, the user's account identifier, and the current time. And returning to the first client; in addition, the server may only generate and return the information that the payment code should contain, and the first client converts the information to obtain the payment code. For the second mode in the previous paragraph, for example, the first client may locally generate a payment code according to parameters such as an authorization amount, a user's account identifier, and a current time. Of course, the first client may generate a payment code. Send some necessary information (for example, the payment code itself or its identification information, etc.) to the server, so that the server can subsequently perform payment processing for the payment code.

In addition, as already mentioned, the payment code can be time-sensitive. The first client can save the previously obtained payment code locally, and if the payment code time limit has not been exceeded in the next acquisition, the locally saved payment code can be directly obtained without re-generation or not with the server. Corresponding interactions can save system resources.

In the embodiment of the present specification, when the user needs to pay the merchant, the payment code obtained by the first client may be displayed to the merchant, the merchant scans the payment code, and sends a corresponding payment request to the server through the second client (request from The user side deducts the payment and pays the merchant party. The server verifies that the corresponding consumption amount will cause the payment amount to be super. If yes, the current payment cannot be successful, and the server can send an instruction to the first client to guide the user. Reassign or reset the payment amount. For example, in the first scenario, the server or the first client may be used to guide the user to re-open the payment code to implement re-assignment or resetting of the authorization amount.

The above is explained from the perspective of the first client, and the following is explained from the perspective of the server. The embodiment of the present specification further provides a schematic diagram of a payment request response method. As shown in FIG. 3, the execution entity is the above-mentioned server, for example, the payment application server corresponding to the payment application client. The process in Figure 3 can include the following steps:

S302: The server receives the payment request sent by the second client by scanning the payment code, where the payment amount of the payment code does not exceed the authorization amount specified by the user of the first client.

S304: Check whether the consumption amount corresponding to the payment request will cause the payment amount to be exceeded.

S306: Respond to the payment request according to the verification result.

In the embodiment of the present disclosure, the step of responding to the payment request according to the verification result may include: if the verification result is no, according to the payment request, the account is Paying the amount of payment, and returning the payment result to the second client (of course, the payment result may also be returned to the first client); if the verification result is yes, returning the corresponding to the second client The prompt information, such as prompting the merchant to pay the payment, the payment amount of the currently scanned payment code is insufficient.

In the embodiment of the present specification, if the verification result is yes, the user may be reminded to perform corresponding operations, and the factors causing the current payment failure are eliminated, so as to retry the payment. For example, an instruction can be sent to the first client to guide the user to re-specify or reset the payment amount and the like.

According to the above description, the embodiment of the present specification further provides a payment flow diagram of a payment code based on a user-specified payment amount in an actual application scenario, as shown in FIG. 4 . The payment process is also exemplary, and the above method is not limited to this specific implementation flow.

The flow in Figure 4 mainly includes the following steps:

The user clicks the corresponding control on the first client to open the payment code function;

The first client displays a user input interface, so that the user inputs the payment password as the identity authentication information and the amount of the authorization amount as the authorization amount;

The first client requests the server to obtain a payment code whose payment amount does not exceed the authorized amount;

The server generates a payment code and returns it to the first client;

When the user consumes at the merchant, the payment code can be displayed to the merchant to pay for the purchase;

The merchant scans the payment code, specifies the consumption amount through the second client, and initiates a payment request to the server;

The server verifies whether this consumption will result in the payment amount of the payment code exceeding;

If the payment amount is not to be used, the payment process may be executed to return the payment result to the first client and the second client;

If the payment amount will be used excessively, the payment failure may be returned to the second client, and the user may be redirected to re-designate the payment code to re-designate or reset the payment amount.

It should be noted that, in the example of FIG. 4, the payment amount is the cumulative amount of each payment code within the validity period after the payment code function is turned on. For example, suppose that when the payment code function is enabled for a certain time, the specified payment amount is 1000 yuan. After that, the first payment is 500 yuan, and the second payment is 400 yuan. Then the payment amount has been used. Lost 900 yuan (the two payment codes can be the same or different). If you want to use the payment code to pay 200 yuan for the third time, the payment amount will be over (1100 yuan), so the third time Payment will fail.

Based on the same idea, the embodiment of the present specification further provides a device corresponding to each method, as shown in FIG. 5 and FIG. 6.

FIG. 5 is a schematic structural diagram of a payment code acquiring apparatus corresponding to FIG. 2 according to an embodiment of the present disclosure, where a dotted box indicates an optional module, and the first client is located in the apparatus, and the apparatus includes:

The receiving module 501 receives a payment code opening instruction;

Determining module 502, determining a user-specified authorization amount;

The obtaining module 503 is configured to obtain a payment code according to the authorization amount for payment, wherein the payment amount of the payment code does not exceed the authorization amount.

Optionally, if the user has not specified the authorization quota, the determining module 502 determines the authorization quota specified by the user, and specifically includes:

The determining module 502 displays a user input interface;

Obtaining identity authentication information input by the user through the user input interface and an amount of the authorization amount;

The identity authentication information and the amount verification are passed.

Optionally, the obtaining module 503 is configured to obtain a payment code according to the authorization quota, and specifically includes:

The obtaining module 503 receives a payment code generated and returned by the server according to the authorization quota, or generates the payment code locally according to the authorization quota.

Optionally, the device further includes:

The guiding module 504, after the obtaining module 503 obtains the payment code according to the authorization amount, if the payment amount corresponding to the payment request for the payment code is determined to cause the payment amount to be super, the user is redirected. Or reset the payment amount.

FIG. 6 is a schematic structural diagram of a payment request response apparatus corresponding to FIG. 3 according to an embodiment of the present disclosure, where a server is located in the apparatus, and the apparatus includes:

The receiving module 601 is configured to receive a payment request sent by the second client by scanning the payment code, where the payment amount of the payment code does not exceed the authorization amount specified by the user of the first client;

The verification module 602, verifying whether the consumption amount corresponding to the payment request will cause the payment amount to be excessive;

The response module 603 responds to the payment request according to the verification result.

Optionally, the response module 603 responds to the payment request according to the verification result, and specifically includes:

If the verification result is no, the response module 603, according to the payment request, pays the consumption amount through the account of the user, and returns a payment result to the second client;

If the verification result is yes, the corresponding prompt information is returned to the second client.

Optionally, if the verification result is yes, the response module 603 further performs:

An instruction is sent to the first client to facilitate directing the user to reassign or reset the payment amount.

Based on the same idea, the embodiment of the present specification further provides a payment code acquiring device corresponding to FIG. 2, where the first client is located in the device, and the device includes:

At least one processor; and,

a memory communicatively coupled to the at least one processor; wherein

Receiving a payment code opening instruction;

Determine the authorization amount specified by the user;

Based on the same idea, the embodiment of the present specification further provides a payment request response device corresponding to FIG. 3, where the server is located in the device, and the device includes:

At least one processor; and,

a memory communicatively coupled to the at least one processor; wherein

Responding to the payment request based on the verification result.

Based on the same idea, the embodiment of the present specification further provides a non-volatile computer storage medium corresponding to FIG. 2, which stores computer executable instructions, and the computer executable instructions are set as:

Receiving a payment code opening instruction;

Determine the authorization amount specified by the user;

Based on the same idea, the embodiment of the present specification further provides a non-volatile computer storage medium corresponding to FIG. 3, which stores computer executable instructions, and the computer executable instructions are set as:

Responding to the payment request based on the verification result.

The foregoing description of the specific embodiments of the specification has been described. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in a different order than the embodiments and still achieve the desired results. In addition, the processes depicted in the figures are not necessarily in a particular order or in a sequential order to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

The various embodiments in the specification are described in a progressive manner, and the same or similar parts between the various embodiments may be referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for a device, device, non-volatile computer storage medium embodiment, since it is substantially similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiment.

The device, the device, the non-volatile computer storage medium and the method provided by the embodiments of the present specification are corresponding. Therefore, the device, the device, and the non-volatile computer storage medium also have similar beneficial technical effects as the corresponding method, since The beneficial technical effects of the method are described in detail, and therefore, the beneficial technical effects of the corresponding device, device, and non-volatile computer storage medium are not described herein.

In the 1990s, improvements to a technology could clearly distinguish between hardware improvements (eg, improvements to circuit structures such as diodes, transistors, switches, etc.) or software improvements (for process flow improvements). However, as technology advances, many of today's method flow improvements can be seen as direct improvements in hardware circuit architecture. Designers almost always get the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that the improvement of a method flow cannot be implemented by hardware entity modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is an integrated circuit whose logic function is determined by the user programming the device. Designers program themselves to "integrate" a digital system on a single PLD without having to ask the chip manufacturer to design and fabricate a dedicated integrated circuit chip. Moreover, today, instead of manually making integrated circuit chips, this programming is mostly implemented using "logic compiler" software, which is similar to the software compiler used in programming development, but before compiling The original code has to be written in a specific programming language. This is called the Hardware Description Language (HDL). HDL is not the only one, but there are many kinds, such as ABEL (Advanced Boolean Expression Language). AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc., are currently the most commonly used VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. It should also be apparent to those skilled in the art that the hardware flow for implementing the logic method flow can be easily obtained by simply programming the method flow into the integrated circuit with a few hardware description languages.

The controller can be implemented in any suitable manner, for example, the controller can take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code (eg, software or firmware) executable by the (micro)processor. In the form of logic gates, switches, application specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers, examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, The Microchip PIC18F26K20 and the Silicone Labs C8051F320, the memory controller can also be implemented as part of the memory's control logic. Those skilled in the art will also appreciate that in addition to implementing the controller in purely computer readable program code, the controller can be logically programmed by means of logic gates, switches, ASICs, programmable logic controllers, and embedding. The form of a microcontroller or the like to achieve the same function. Such a controller can therefore be considered a hardware component, and the means for implementing various functions included therein can also be considered as a structure within the hardware component. Or even a device for implementing various functions can be considered as a software module that can be both a method of implementation and a structure within a hardware component.

The system, device, module or unit illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product having a certain function. A typical implementation device is a computer. Specifically, the computer can be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or A combination of any of these devices.

For the convenience of description, the above devices are described separately by function into various units. Of course, the functions of the various units may be implemented in one or more software and/or hardware in the implementation of the present specification.

Those skilled in the art will appreciate that embodiments of the specification can be provided as a method, system, or computer program product. Thus, embodiments of the present specification can take the form of an entirely hardware embodiment, an entirely software embodiment, or a combination of software and hardware. Moreover, embodiments of the present specification can take the form of a computer program product embodied on one or more computer usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) including computer usable program code.

The present description is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present specification. It will be understood that each flow and/or block of the flowchart illustrations and/or FIG. These computer program instructions can be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing device to produce a machine for the execution of instructions for execution by a processor of a computer or other programmable data processing device. Means for implementing the functions specified in one or more of the flow or in a block or blocks of the flow chart.

The computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture comprising the instruction device. The apparatus implements the functions specified in one or more blocks of a flow or a flow and/or block diagram of the flowchart.

These computer program instructions can also be loaded onto a computer or other programmable data processing device such that a series of operational steps are performed on a computer or other programmable device to produce computer-implemented processing for execution on a computer or other programmable device. The instructions provide steps for implementing the functions specified in one or more of the flow or in a block or blocks of a flow diagram.

In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include non-persistent memory, random access memory (RAM), and/or non-volatile memory in a computer readable medium, such as read only memory (ROM) or flash memory. Memory is an example of a computer readable medium.

Computer readable media includes both permanent and non-persistent, removable and non-removable media. Information storage can be implemented by any method or technology. The information can be computer readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory. (ROM), electrically erasable programmable read only memory (EEPROM), flash memory or other memory technology, compact disk read only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, Magnetic tape cartridges, magnetic tape storage or other magnetic storage devices or any other non-transportable media can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary storage of computer readable media, such as modulated data signals and carrier waves.

It is also to be understood that the terms "comprises" or "comprising" or "comprising" or any other variations are intended to encompass a non-exclusive inclusion, such that a process, method, article, Other elements not explicitly listed, or elements that are inherent to such a process, method, commodity, or equipment. An element defined by the phrase "comprising a ..." does not exclude the presence of additional equivalent elements in the process, method, item, or device including the element.

Those skilled in the art will appreciate that embodiments of the present description can be provided as a method, system, or computer program product. Accordingly, the present description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment in combination of software and hardware. Moreover, the description may take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) including computer usable program code.

This description can be described in the general context of computer-executable instructions executed by a computer, such as a program module. Generally, program modules include routines, programs, objects, components, data structures, and the like that perform particular tasks or implement particular abstract data types. The present specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are connected through a communication network. In a distributed computing environment, program modules can be located in both local and remote computer storage media including storage devices.

The various embodiments in the specification are described in a progressive manner, and the same or similar parts between the various embodiments may be referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiment.

The above description is only for the embodiments of the present specification, and is not intended to limit the application. Various changes and modifications can be made to the present application by those skilled in the art. Any modifications, equivalents, improvements, etc. made within the spirit and scope of the present application are intended to be included within the scope of the appended claims.

Claims

A payment code acquisition method includes:

The first client receives the payment code opening instruction;

Determine the authorization amount specified by the user;

Obtaining a payment code according to the authorization amount for payment, wherein the payment amount of the payment code does not exceed the authorization amount.
The method of claim 1, wherein if the user has not specified the authorization amount, the determining the authorization amount specified by the user includes:

Display user input interface;

Obtaining identity authentication information input by the user through the user input interface and an amount of the authorization amount;

The identity authentication information and the amount verification are passed.
The method of claim 1, wherein the obtaining the payment code according to the authorization amount comprises:

Receiving, by the server, a payment code generated and returned according to the authorization quota, or generating the payment code locally according to the authorization quota.
The method of claim 1, after the obtaining the payment code according to the authorization amount, the method further comprises:

If it is determined that the amount of consumption corresponding to the payment request for the payment code will cause the payment amount to be exceeded, the user is directed to re-designate or reset the payment amount.
A payment request response method includes:

The server receives the payment request sent by the second client by scanning the payment code, where the payment amount of the payment code does not exceed the authorization amount specified by the user of the first client;

Verifying whether the amount of consumption corresponding to the payment request will cause the payment amount to be exceeded;

Responding to the payment request based on the verification result.
The method of claim 5, wherein the responding to the payment request according to the verification result comprises:

If the verification result is no, the payment amount is paid by the user's account according to the payment request, and the payment result is returned to the second client;

If the verification result is yes, the corresponding prompt information is returned to the second client.
The method of claim 6, if the verification result is yes, the method further comprises:

An instruction is sent to the first client to facilitate directing the user to reassign or reset the payment amount.
A payment code acquisition device, the first client is located in the device, and the device includes:

Receiving module, receiving a payment code opening instruction;

Determining a module to determine a user-specified authorization amount;

The obtaining module obtains a payment code according to the authorization amount for payment, wherein the payment amount of the payment code does not exceed the authorization amount.
The apparatus according to claim 8, wherein the determining module determines the authorization amount specified by the user, if the user has not specified the authorization quota, and specifically includes:

The determining module displays a user input interface;

Obtaining identity authentication information input by the user through the user input interface and an amount of the authorization amount;

The identity authentication information and the amount verification are passed.
The device of claim 8, wherein the obtaining module obtains the payment code according to the authorization amount, which specifically includes:

The obtaining module receives a payment code generated and returned by the server according to the authorization quota, or generates the payment code locally according to the authorization quota.
The device of claim 8 further comprising:

The guiding module, after the obtaining module obtains the payment code according to the authorization quota, if it is determined that the consumption amount corresponding to the payment request for the payment code will cause the payment amount to be excessive, the user is redirected or re-directed Set the payment amount.
A payment request response device, the server is located in the device, and the device includes:

The receiving module receives a payment request sent by the second client by scanning the payment code, where the payment amount of the payment code does not exceed the authorization amount specified by the user of the first client;

a verification module, verifying whether the amount of consumption corresponding to the payment request will cause the payment amount to be exceeded;

The response module responds to the payment request according to the verification result.
The apparatus according to claim 12, wherein the response module responds to the payment request according to the verification result, and specifically includes:

If the verification result is no, the response module performs payment on the consumption amount through the account of the user according to the payment request, and returns a payment result to the second client;

If the verification result is yes, the corresponding prompt information is returned to the second client.
The apparatus according to claim 13, wherein if the verification result is yes, the response module further performs:

An instruction is sent to the first client to facilitate directing the user to reassign or reset the payment amount.
A payment code acquisition device, where the first client is located, the device includes:

At least one processor; and,

a memory communicatively coupled to the at least one processor; wherein

The memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to:

Receiving a payment code opening instruction;

Determine the authorization amount specified by the user;

Obtaining a payment code according to the authorization amount for payment, wherein the payment amount of the payment code does not exceed the authorization amount.
A payment request response device, where the server is located, the device includes:

At least one processor; and,

a memory communicatively coupled to the at least one processor; wherein

The memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to:

Receiving, by the second client, a payment request sent by scanning a payment code, where the payment amount of the payment code does not exceed a user-specified authorization amount of the first client;

Verifying whether the amount of consumption corresponding to the payment request will cause the payment amount to be exceeded;

Responding to the payment request based on the verification result.