CN110009335B

CN110009335B - Payment code generation method, payment code generation device, mobile payment method, mobile payment device and equipment

Info

Publication number: CN110009335B
Application number: CN201811476736.0A
Authority: CN
Inventors: 周孝佳
Original assignee: Advanced New Technologies Co Ltd
Current assignee: Advanced New Technologies Co Ltd; Advantageous New Technologies Co Ltd
Priority date: 2018-12-05
Filing date: 2018-12-05
Publication date: 2021-01-26
Anticipated expiration: 2038-12-05
Also published as: TW202022733A; CN112785309A; WO2020114113A1; CN110009335A

Abstract

The embodiment of the specification discloses a payment code generation method, a mobile payment method, a payment code generation device, a mobile payment device and equipment. The scheme comprises the following steps: acquiring account information sent by a first terminal; the first terminal is different from the binding equipment of the account information; acquiring first identity authentication information sent by the first terminal; verifying the first identity verification information to obtain a first verification result; when the first verification result shows that the first identity verification information is verified successfully, generating a payment code corresponding to the account information; and sending the payment code to the first terminal.

Description

Payment code generation method, payment code generation device, mobile payment method, mobile payment device and equipment

Technical Field

The application relates to the technical field of computers, in particular to a payment code generation method, a payment code mobile payment device and payment equipment.

Background

In the prior art, rapid popularization of mobile payment brings great convenience to life of people, and compared with a traditional cash payment mode, the mobile payment is safer, the payment process is faster, and the mobile payment is more convenient to carry. But mobile payments are also accompanied by a problem: dependence on mobile terminals. Under the scene that the user forgets to carry the mobile phone or the electric quantity of the mobile phone is exhausted, the user cannot select the mobile phone to complete payment. This results in a large degree of user egress still requiring the carrying of a portion of the cash on the person for use as and when necessary.

Disclosure of Invention

In view of this, embodiments of the present application provide a payment code generation method, a payment code generation device, a mobile payment method, a mobile payment device, and a mobile payment device, which are used to improve convenience of mobile payment.

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

the payment code generation method provided by the embodiment of the specification comprises the following steps:

acquiring account information sent by a first terminal, wherein the first terminal is different from a binding device of the account information;

acquiring first identity authentication information sent by the first terminal;

verifying the first identity verification information to obtain a first verification result;

when the first verification result shows that the first identity verification information is verified successfully, generating a payment code corresponding to the account information;

and sending the payment code to the first terminal.

An embodiment of the present specification provides a mobile payment method, including:

acquiring a deduction request aiming at the payment code;

determining transaction information corresponding to the deduction request;

determining a payment limit condition of the payment code;

judging whether the transaction information meets the payment limiting condition;

if yes, carrying out deduction operation according to the deduction request.

a first terminal acquires account information, wherein the first terminal is different from binding equipment of the account information;

acquiring first identity verification information;

sending the account information and the first identity verification information to a server;

when the server determines that the first identity verification information is verified successfully, receiving a payment code of the account information sent by the server;

printing the payment code.

An embodiment of this specification provides a payment code generation device, includes:

the account information acquisition module is used for acquiring account information sent by the first terminal; the first terminal is different from the binding equipment of the account information;

the first identity authentication information acquisition module is used for acquiring first identity authentication information sent by the first terminal;

the first verification module is used for verifying the first identity verification information to obtain a first verification result;

the payment code generation module is used for generating a payment code corresponding to the account information when the first verification result shows that the first identity verification information is verified successfully;

and the payment code sending module is used for sending the payment code to the first terminal.

An embodiment of this specification provides a mobile payment device, includes:

the deduction request acquisition module is used for acquiring a deduction request aiming at the payment code;

the transaction information determining module is used for determining the transaction information corresponding to the deduction request;

the payment limiting condition determining module is used for determining the payment limiting condition of the payment code;

the judging module is used for judging whether the transaction information meets the payment limiting condition;

and the deduction operation module is used for carrying out deduction operation according to the deduction request when the transaction information meets the payment limiting condition.

the account information acquisition module is used for acquiring account information by a first terminal, and the first terminal is different from the binding equipment of the account information;

the first identity authentication information acquisition module is used for acquiring first identity authentication information;

the first sending module is used for sending the account information and the first identity verification information to a server;

the first receiving module is used for receiving the payment code of the account information sent by the server when the server determines that the first identity verification information is verified successfully;

and the payment code printing module is used for printing the payment code.

An embodiment of this specification provides a payment code generating device, including:

at least one processor; and the number of the first and second groups,

a memory communicatively coupled to the at least one processor; wherein the content of the first and second substances,

the memory stores instructions executable by the at least one processor to enable the at least one processor to:

acquiring first identity authentication information sent by the first terminal;

and sending the payment code to the first terminal.

at least one processor; and the number of the first and second groups,

acquiring first identity verification information;

printing the payment code.

An embodiment of the present specification provides a mobile payment device, including:

at least one processor; and the number of the first and second groups,

acquiring a deduction request aiming at the payment code;

determining transaction information corresponding to the deduction request;

determining a payment limit condition of the payment code;

if yes, carrying out deduction operation according to the deduction request.

The embodiment of the specification adopts at least one technical scheme which can achieve the following beneficial effects:

the account and the identity information input by the user on the terminal of the non-account binding device are verified to generate the authorized payment code of the account, so that the mobile payment problem of the user when the mobile phone is not at hand or cannot be used is solved, and the convenience of mobile payment is improved.

Drawings

The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the application and together with the description serve to explain the application and not to limit the application. In the drawings:

fig. 1 is a schematic flowchart of a payment code generation method provided in embodiment 1 of the present specification;

fig. 2 is a schematic flow chart of a payment code generation method provided in embodiment 2 of the present specification;

fig. 3 is a schematic flow chart of a mobile payment method provided in embodiment 3 of the present specification;

fig. 4 is a schematic structural diagram of a payment code generation apparatus corresponding to fig. 1 provided in an embodiment of the present disclosure;

fig. 5 is a schematic structural diagram of a payment code generation apparatus corresponding to fig. 2 provided in an embodiment of the present disclosure;

fig. 6 is a schematic structural diagram of a mobile payment device corresponding to fig. 3 provided in an embodiment of the present specification;

fig. 7 is a schematic structural diagram of a payment code generation apparatus corresponding to fig. 1 provided in an embodiment of the present specification;

fig. 8 is a schematic structural diagram of a payment code generation apparatus corresponding to fig. 2 provided in an embodiment of the present specification;

fig. 9 is a schematic structural diagram of a mobile payment device corresponding to fig. 3 provided in an embodiment of the present specification.

Detailed Description

In order to make the objects, technical solutions and advantages of the present application more apparent, the technical solutions of the present application will be described in detail and completely with reference to the following specific embodiments of the present application and the accompanying drawings. It should be apparent that the described embodiments are only some of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

The technical solutions provided by the embodiments of the present application are described in detail below with reference to the accompanying drawings.

Fig. 1 is a schematic flow chart of a payment code generation method provided in embodiment 1 of the present specification. From the viewpoint of a program, the execution subject of the flow may be a program installed in an application server or an application client.

As shown in fig. 1, the process may include the following steps:

s101: the method comprises the steps of obtaining account information sent by a first terminal, wherein the first terminal is different from a binding device of the account information.

In the embodiment of the present specification, the first terminal device may be a computer arranged by a service provider at a place such as a shopping mall, a restaurant, a station, or the like, or may be a mobile intelligent terminal, a tablet computer, a notebook computer, or the like owned by another person. When a user cannot use his/her mobile phone (i.e. the binding device for account information) to perform mobile payment, the user can log in on the first terminal device, for example, input his/her user name, mobile phone number for account binding, mailbox, etc., and then the server obtains the account information sent by the first terminal.

When acquiring account information, the account information may include an account identifier and a sending device of the account information, and the server first needs to determine whether the sending device is the same as a binding device of the account information.

In the embodiments of the present specification, the terms "first" and "second" are used only for distinguishing users, and have no practical meaning in order to prevent confusion of concepts.

S102: and acquiring first identity authentication information sent by the first terminal.

In order to verify the account information, the server needs to obtain authentication information corresponding to the account, which may be password login information or biometric information, such as fingerprint features or facial features.

S103: and verifying the first identity verification information to obtain a first verification result.

After receiving the first identity authentication information, the server compares the authentication information with registration information stored by the user during registration, and if the authentication information is matched with the registration information, the server can judge that the authentication is passed, otherwise, the server cannot pass the authentication.

During verification, the server can also adopt a wind control measure, for example, the user login equipment is found to be changed, the user name, the password verification and the biological characteristic verification can be combined, for example, the user name and the password are compared firstly, the biological characteristic is compared after the user name and the password pass, and the verification is confirmed to pass through after the user name and the password pass. Of course, other wind control measures may be adopted, for example, if the user inputs a user name and the number of wrong passwords reaches an upper limit, the account of the user is locked. The specific wind control measures can be set according to specific application requirements.

S104: and when the first verification result shows that the first identity verification information is verified successfully, generating a payment code corresponding to the account information.

After the verification is successful, the server generates a payment code of the account according to the basic information of the account and the payment habit information of the user, wherein the payment code can also be authorization information, and the authorization information can include a payment amount upper limit, a payment time upper limit, an effective time range and the like. In an embodiment of the present specification, the basic information includes: a user name; the payment habit information of the user comprises: frequency of use, cumulative payment amount, average amount of single payment, and historical daily average payment amount of the account.

In addition, the server can also let the user select or input own authorization information through the provided authorization page; generally, the authorization information may include the time of validation of the payment code. And the server determines the limiting condition of the payment code for the offline payment according to the authorization information input by the user and the information of the account. If the authorization information input by the user does not accord with the self information of the account, secondary identity authentication or other wind control measures can be carried out. For example, the server may randomly generate a 6-digit password corresponding to the generated payment code. When the payment code is used for payment every time, the user is required to input a 6-digit digital password, and the payment can be successfully carried out only if the user successfully inputs the password. Normally, a 6-digit password can be reserved by the user himself.

S105: and sending the payment code to the first terminal.

The server sends the payment code with the account authorization information to the first terminal, and the first terminal can display the payment code as a bar code and/or a two-dimensional code according to the encoding rule of the bar code, so as to be used for offline payment or other operations, such as adding friends or groups. In embodiments of the present description, the payment code may include an identification of the user account, such as an account name.

Optionally, under the condition that the first terminal supports the printing function, the payment code may be printed out to perform offline payment in a way of a flat printed matter, and the payment code may be transmitted in a way of capturing a picture of the screen of the first terminal, so as to implement a function of performing mobile payment on other terminal devices (different from the binding device of the account information).

In the method in fig. 1, the account and the identity information input by the user on the terminal of the non-account binding device are verified to generate the authorized payment code of the account, so that the problem of mobile payment when the mobile phone of the user is not nearby or cannot be used is solved, and the convenience of mobile payment is improved.

Based on the method of fig. 1, the embodiments of the present specification also provide some specific implementations of the method, which are described below.

In an embodiment of the present specification, before the generating the payment code of the account information, the method further includes:

determining a payment limit condition, wherein the payment limit condition is used for restricting off-line payment of the payment code.

In the embodiment of the specification, in order to increase the security of the offline payment of the payment code, the offline payment of the payment code can be limited by adding a payment limiting condition, and the effective time of the payment code, the payment amount and the like can be limited. Of course, the payment limiting conditions may be generated according to the operation habit of the user, or according to the information filled in by the user on the authorization page of the first terminal, or may be generated by combining the two situations.

Optionally, the determining the payment limiting condition specifically includes:

determining a payment limit threshold;

and/or, determining a payment threshold;

and/or, determining an effective time range;

the payment amount threshold is used for limiting the upper limit of the payment amount of the payment code, the payment number threshold is used for limiting the payment number of the payment code in an effective time range, and the payment code is effective in the effective time range.

In the embodiment of the specification, the payment amount limit can be a single payment amount threshold upper limit, and can also be a payment total amount upper limit. For example, when a user goes out to shopping, some small things are bought, the amount is small, but a plurality of small things are bought, and the total payment amount can be set to 200 yuan without limiting the single payment amount. When the user determines the things to buy, the user often only needs to pay once, and then the payment limit can pay the total limit, such as 500 yuan and 1000 yuan.

In this embodiment of the present specification, the payment number threshold may be set according to an actual scene of the user, and may be set once or multiple times, and may have a relationship with the payment amount threshold.

In the embodiment of the present specification, the time range of the payment code may be determined according to the actual situation of the user, and may be 3 hours, 5 hours, generally within 24 hours, of course, 2 days, or longer for security.

In the embodiment of the present specification, the payment amount threshold, the payment number threshold, and the validity time range may be individually set, or may be set in plural numbers at the same time. In order to enhance the security, there may be other payment restriction conditions, such as payment effective range (which may be limited to a certain city or region), or payment effective category (which may be clothing, supermarket, transportation, dining, etc.).

The method provided by the embodiment of the specification can be used in a scenario that, for example, change money given to a child can be replaced by the payment code provided by the method, the maximum amount paid each time and the number of times of payment are limited, so that the loss caused by the fact that the child loses money or the trouble caused by the fact that no change gives the child is avoided.

Optionally, the determining the payment amount threshold specifically includes:

acquiring a first payment limit threshold value sent by the first terminal;

determining a second payment limit threshold according to the account information;

judging whether the first payment limit threshold value is smaller than the second payment limit threshold value;

if yes, determining the first payment limit threshold as the payment limit threshold.

In the embodiment of the specification, the payment is often determined according to the basic information of the account, but in an actual application scenario, a situation often occurs, and a user often needs to pay a large amount of money, for example, 1500 yuan is needed for purchasing gold and silver jewelry. In order to complete the payment, the payment limit input by the user is often more than the amount paid by using the account at ordinary times, in this case, the amount of money that the user needs to authorize the payment is more than the payment limit (for example, 500 yuan) generated by the account, and at this time, if the second payment limit threshold (500 yuan) is still determined according to the account information as the payment limit, the user cannot complete a large-amount payment request (1500 yuan jewelry). Therefore, the first payment value unit threshold value input by the user, such as the user, is required to be used as the payment value unit limit.

Optionally, after determining whether the first payment value unit threshold is smaller than the second payment value unit threshold, the method further includes:

if not, acquiring second identity authentication information sent by the first terminal;

verifying the second identity verification information to obtain a second verification result;

and when the second verification result shows that the second identity verification information is verified successfully, determining the first payment limit threshold as the payment limit threshold.

In an actual application scenario, because the first payment limit threshold value input by the user is greater than the second payment threshold value (preset payment threshold value) generated according to the account information, if the first payment limit threshold value is taken as the payment limit threshold value, the safety factor of the payment code will be reduced, in order to avoid this situation, secondary identity authentication needs to be performed, and the payment limit threshold value is determined according to the secondary authentication result.

The second authentication information is mainly used for further verifying whether the user is an account and is authorized, and generally, the second authentication information may be more detailed or strict than the first authentication information, face information or palm print information may be adopted, a certificate number for performing real-name authentication on the account may be input, and further, several consumption items may be provided to allow the user to confirm which kind or kinds are generated by the account. If the second authentication information is successfully verified, the payment code is granted with a larger payment amount authority, namely the first payment amount threshold requested by the user. And when the second identity authentication information fails to be authenticated, refusing to perform the authorization service.

Optionally, after the determining the payment limiting condition, the method further includes:

determining a pre-deduction according to the payment limiting condition, wherein the pre-deduction is used for off-line payment of the payment code;

determining a deduction channel;

and freezing the amount corresponding to the pre-deduction from the appointed account according to the deduction channel.

In the embodiment of the present specification, in order to smoothly complete the offline payment of the payment code, a deduction channel of the payment amount needs to be determined in advance, that is, how much money is deducted from what account to pay, that is, a pre-deduction needs to be determined in advance. The deduction channel of the account is similar to the payment channel, and the server can deduct money by adopting the default payment channel of the account and can also deduct money according to the payment mode selected by the user, such as balance, balance treasure, ant bei, bank card and the like.

If the account is default or the account balance corresponding to the payment channel selected by the user is 600 yuan which is larger than the amount of the pre-deduction (500 yuan), 500 yuan can be directly frozen from the corresponding account, if the account balance is 200 yuan which is smaller than 500 yuan, the amount of money needs to be frozen from other accounts, the account can be a second default account, or the user can select again until the corresponding account has enough balance to freeze the amount of the pre-deduction.

If the deduction channel is an internal payment tool, such as a balance bank, the amount is frozen from the inside of the user account, and the frozen amount can only pay the deduction request initiated by the payment code and is not used for other purposes.

Optionally, deducting the amount corresponding to the pre-deduction from the designated account according to the deduction channel specifically includes:

judging whether the deduction channel is a third party payment channel or not;

if so, calling a third party payment tool corresponding to the deduction channel;

determining a payment account corresponding to the deduction channel;

and utilizing the third party payment tool to freeze the amount corresponding to the pre-deduction from the payment account.

When the server judges that the deduction channel is a third-party payment channel, a third-party payment tool, such as a program of a bank system or other APP programs, needs to be called. And then, the amount corresponding to the pre-deduction is frozen from the payment account by using a third party payment tool, and the frozen amount can only pay the deduction request initiated by the payment code and is not used for other purposes.

Optionally, the determining a pre-deduction according to the payment limiting condition specifically includes:

and determining the product of the payment limit threshold and the payment time threshold as the sum of the pre-deduction, wherein the payment limit threshold is a single payment limit threshold.

In this embodiment of the present specification, the amount of the pre-deduction is a total payment amount threshold, and if the payment amount threshold is a single payment amount threshold, the total payment amount threshold needs to be determined together with the payment time threshold, that is, the amount of the pre-deduction may be determined according to a product of the single payment threshold and the payment time threshold, where if the single payment threshold is 100 yuan and the payment time threshold is 3 times, the amount of the pre-deduction is 100 × 3 — 300 yuan.

and determining the payment limit threshold as the amount of the pre-deduction, wherein the payment limit threshold is a total payment limit threshold.

If the obtained payment limit threshold is the total payment limit threshold, the amount of the pre-deduction is the payment limit threshold, for example, the payment limit threshold is 500 yuan, and the amount of the multi-payment is not more than 500 yuan no matter how many times the payment is made, so the amount of the pre-deduction is 500 yuan.

The above-described embodiment explains the payment code generation method of the present specification from the perspective of the server, and the embodiment of the present specification explains the payment code generation method of the present specification from the perspective of the first terminal.

Fig. 2 is a schematic flow chart of a payment code generation method provided in embodiment 2 of this specification. From a program perspective, the execution subject of the flow is the first terminal.

As shown in fig. 2, the process may include the following steps:

s201: the method comprises the steps that a first terminal obtains account information; the first terminal is different from the binding device of the account information.

In the embodiment of the present specification, the first terminal may be a computer disposed by a service provider at a place such as a shopping mall, a restaurant, a station, or the like, or may be a mobile intelligent terminal, a tablet computer, a notebook computer, or the like owned by another person. When the user can not use the own mobile phone (namely the binding device of the account information) to carry out mobile payment, the user can log in on the first terminal device, for example, the user name of the user, the mobile phone number bound to the account, the mailbox and the like are input.

The first terminal may present to the user a login interface in the authorization interface, and it may be understood that the login interface here is different from the login interface of the user on the binding device of the account information in a normal state. If the first terminal is a computer arranged by a service provider at a position of a market, a restaurant, a station and the like, is a device terminal only having a specific function, and is different from a binding device (a mobile intelligent terminal, a tablet computer or a notebook computer) of account information, namely, the first terminal can only be used for performing authorization service of offline payment, and does not have other functions of the mobile payment terminal, only one login interface is provided, and the login interface can be different from a login interface of a user on the binding device of account information. If the first terminal is a mobile intelligent terminal, a tablet computer, a notebook computer and the like owned by other people and is the same as the binding equipment of the account information, an authorization interface can be independently made, and a login interface only having an authorization function is selected during login.

S202: first authentication information is obtained.

The first authentication information is acquired from a login interface of an authorization interface of the first terminal, and can be password login information, or biological characteristic information, such as fingerprint characteristics or facial characteristics, or multiple authentications of a user name, a password and biological characteristics can be combined, so that the security is improved. For example, the user name and password are compared first, and then the biometric features are compared.

S203: and sending the account information and the first identity verification information to a server.

In this embodiment of the present specification, the account information and the first authentication information may be sent to the server at the same time, or may be sent at different times, that is, the account information is sent first, and then the first authentication information is sent. Moreover, the first identity authentication information may be one or two pieces, and may or may not be in sequence. For example, the first identity authentication information includes an account password and a biometric feature, and the first terminal may send the acquired account password and biometric feature to the server for authentication; or the account password can be firstly sent to the server for primary verification, and then the biological characteristics are sent to the server for secondary verification.

S204: and when the server determines that the first identity verification information is verified successfully, receiving a payment code of the account information sent by the server.

In this embodiment, after the server determines that the first authentication information is successfully verified, the first terminal receives a payment code carrying the authorization information for offline payment. The payment code may be a two-dimensional code or a bar code, the payment code containing the identification of the user.

S205: printing the payment code.

In the embodiment of the present specification, the first terminal may be a device terminal with a printing function, and may directly print the payment code; or by making a wireless or wireless connection with the printer and then printing.

When the payment code is used for payment, identity authentication can be performed, for example, when online payment is performed, a payment password or a bound mobile phone number of an account or biometric information of a user needs to be provided, and the payment can be successful only after the authentication is passed.

In the embodiment of the specification, the payment code is printed out, and the carrying is convenient. The user can throw away electronic equipment such as cell-phone, and the more convenient enjoyment or the benefit that brings of using the payment code. Has a further promoting effect on the popularization of currency electronization.

Based on the method of fig. 2, the embodiments of the present specification also provide some specific implementations of the method, which are described below.

In the embodiment of the present specification, in order to improve the security of the payment code, the payment environment or the payment condition of the payment code needs to be limited.

Optionally, before the receiving the payment code of the account information sent by the server, the method further includes: and acquiring a payment limiting condition input by a user, wherein the payment limiting condition is used for restricting the off-line payment of the payment code.

In an actual application scenario, a payment limiting condition may be added to limit offline payment of the payment code, and the validation time of the payment code, the payment amount, and the like may be limited. After the server determines that the first authentication information is successfully verified, or returns an interface of a payment limiting condition of the first terminal to be presented to the user, the user can select corresponding checking or input on the interface according to the actual situation of the user, and the first terminal returns the information input by the user to the server after acquiring the information input by the user.

Optionally, the obtaining of the payment limiting condition input by the user specifically includes:

acquiring a payment limit threshold;

and/or, obtaining a payment number threshold;

and/or, obtaining an effective time range;

In the embodiment of the present specification, the first terminal may present various limitations to the user, such as a payment amount threshold, a payment number threshold, and an effective time range. The user can select the corresponding category as desired. The user's selection may be one of them or may be plural.

In a specific application scenario, the payment limit threshold includes two types, one type is a single payment limit threshold, and the other type is a total payment limit threshold, if the user needs to pay a plurality of small-amount items, the single payment limit threshold may be selected to be 50 yuan, the payment number threshold is 10, if the user needs to pay a large-amount item, the total payment limit threshold may be selected to be 500 yuan, and the payment number threshold is 1 word.

The validity time range is critical for the payment code, which will be valid for a long period of time if the validity time range of the payment code is not limited. When the user accidentally drops the payment code, anyone who picks up the payment code can use the payment code to make a payment. In order to prevent such a problem, in the embodiments of the present specification, the effective time range is limited, and may be 2 hours, 3 hours, 8 hours, and usually not more than 24 hours. Other situations, such as 7 days, are of course not excluded.

In a specific application scenario, the effective area of the payment code may be limited, for example, only limited to a certain city, such as beijing, hangzhou, and guangzhou, and the payment field of the payment code may also be limited, for example, only limited to buying clothes, supermarkets, or train stations.

Optionally, after the obtaining of the payment limiting condition input by the user, the method further includes:

acquiring a deduction channel input by a user, wherein the deduction channel represents a deduction channel of the amount of the payment code for payment;

and sending the deduction channel to a server.

In the embodiment of the present specification, after the payment limiting condition of the payment code is obtained, a deduction channel of the payment code needs to be obtained, that is, a source of the amount of the payment code for payment is determined. The deduction channel can be used for presenting the deduction mode in the account information to the first terminal by the server for the customer to select. The deduction channel can be an internal payment tool, such as balance, a change purse and the like, and can also be an external payment tool, namely, a server is required to call a third party payment tool, such as a bank card, and a corresponding bank system is required to be called to carry out deduction operation.

Optionally, the obtaining of the payment amount threshold specifically includes:

acquiring first payment limit information;

after the obtaining of the payment amount threshold, the method further comprises the following steps:

receiving a security verification instruction returned by the server; the safety verification instruction is generated after the server determines that the first payment limit information is larger than the preset payment limit of the account;

displaying a verification information input interface;

acquiring second identity authentication information input based on the authentication information input interface;

and sending the second authentication information to the server.

In the embodiment of the present specification, the determination of the payment amount threshold may be jointly decided according to the account information of the user and the input information of the user. If the first payment limit threshold value which the user wants to obtain is larger than the preset payment limit generated according to the account information, the identity of the user needs to be further determined, and second identity authentication information can be obtained. The second authentication information is mainly used for further verifying whether the user is an account and is authorized, and generally, the second authentication information may be more detailed or strict than the first authentication information, face information or palm print information may be adopted, a certificate number for performing real-name authentication on the account may be input, and further, several consumption items may be provided to allow the user to confirm which kind or kinds are generated by the account. If the second authentication information is successfully verified, the payment code is granted with a larger payment amount authority, namely the first payment amount threshold requested by the user.

The embodiment of the specification also provides a mobile payment method of the payment code aiming at the payment code generated by the method.

Fig. 3 is a schematic flowchart of a mobile payment method for a payment code provided in embodiment 3 of this specification. From the viewpoint of a program, the execution subject of the flow may be a program installed in an application server or an application client.

As shown in fig. 3, the process may include the following steps:

s301: and acquiring a deduction request aiming at the payment code.

In the embodiment of the present specification, the method for using the payment code is similar to other dynamic payment codes presented at the mobile terminal, when the payment code is used for payment, the payment code is scanned by using a payment request end to generate a deduction request, and the deduction request may include an initiating end of the deduction request, scanned payment code information, and a deduction amount. The payment request terminal can be a scanning gun or a fixed scanning device.

S302: and determining the transaction information corresponding to the deduction request.

In the embodiment of the present specification, the deduction request includes many information, and after the server obtains the deduction request, only some important information needs to be extracted, such as: the initiating end of the deduction request, the initiating time of the deduction request, the payment account number, the deduction amount and the like. The transaction information for a debit request may be expressed as: "dining x hotpot x cate city 46 yuan".

S303: determining a payment limit condition for the payment code.

In the embodiment of the description, since the condition of performing payment by using the payment code is different from the condition of performing payment by using the binding device of the account information corresponding to the payment code, the server calls a payment program corresponding to the payment code according to the deduction request, and determines the payment limiting condition of the payment code. The payment limiting condition is that the server is stored for a long time and can be directly called.

In practical application scenarios, since the payment limit condition is preset in advance, generally, the transaction information of the deduction request to be determined is often related to the payment limit condition. For example, if the payment restriction includes a valid time range, the transaction information needs to include the time of initiating the deduction request, i.e., "restaurant x hotpot x cate city 46 yuan 2018, 12 month, 12 day, 14 hour, 35 minutes"

S304: and judging whether the transaction information meets the payment limiting condition.

In the embodiment of the present specification, it is determined whether the transaction information corresponding to the deduction request meets the payment limiting conditions of the payment code, the payment limiting conditions need to be determined one by one, and it is only indicated that the transaction information meets the payment limiting conditions of the payment code if all the conditions are met.

S305: if yes, carrying out deduction operation according to the deduction request.

When the transaction condition meets all payment limits, the user who is the account corresponding to the payment code can be determined to be in off-line transaction, and after the user confirms that no mistake is found, the deduction request can be completed. Generally, for safety, risk control can be performed, that is, when it is confirmed that the transaction condition satisfies all payment restrictions, the user is still required to input a mobile phone number bound by an account corresponding to a payment code, and if the deduction channel is a bank card, the user can be required to input a password of the bank card.

Based on the method of fig. 3, the embodiments of the present specification also provide some specific implementations of the method, which are described below.

Optionally, the payment limiting condition comprises a payment amount threshold,

judging whether the transaction information meets the payment limiting condition, specifically comprising:

determining the deduction amount of the transaction information;

and judging whether the deduction amount is smaller than the payment amount threshold value.

In the embodiment of the present specification, the payment limiting condition limits the payment amount threshold, and it needs to determine whether the deduction amount of the transaction information meets the payment amount threshold. If the single payment limit threshold value is limited, if the deduction amount is smaller than the single payment limit threshold value, the transaction information meets the payment limiting condition. Assuming that the single payment limit threshold is set to 50 yuan, and the transaction information of the deduction request of 46 yuan, namely "restaurant xx spicy soup x cate city 46 yuan 2018, 12 month, 12 day and 14 hour 35 min", is 46 yuan, the transaction information meets the payment limiting condition. If the single payment threshold is set to 40 dollars, then the transaction information does not meet the payment limit.

If the total payment limit threshold is limited, and the total amount of the deduction amount cannot exceed the total payment limit threshold, the transaction information meets the payment limiting condition. Assuming that the total payment limit threshold is set to 500 yuan, for a deduction request of "food and drink x spicy dip x cate city 46 yuan 2018, 12 month, 12 day, 14 day, 35 minutes", the deduction amount is 46, the amount paid by the acquired payment code is 412 yuan, the transaction information of the current deduction amount is 458 yuan, and is less than 500 yuan, and the transaction information meets the payment limiting condition.

Optionally, the payment restriction condition includes an effective time range,

and judging whether the initiation time of the transaction information belongs to the valid time range.

In the embodiment of the present specification, the payment limitation condition limits the valid time range, and it needs to be determined whether the initiation time of the transaction information meets the valid time range. Assuming that the set limited time range is 12/2018/12/18/2018/12/2018, the transaction information with the deduction request of "restaurant x spicy dip x gourmet city 46 yuan, 35/14/12/14/2018/12/35/2018" is 35/14/12/14/2018/12/14/35/2018/12/18, and the transaction information meets the payment limit condition.

Optionally, the payment limiting condition comprises a payment threshold,

acquiring the payment times of the payment code;

judging whether the payment times are smaller than the payment time threshold value or not;

after the deduction operation is carried out according to the deduction request, the method further comprises the following steps:

and adding one to the payment times of the payment code.

In the embodiment of the present specification, the payment limiting condition limits the number of times of payment, and the number of times of payment is formed at the payment code end, and the number of times of payment is zero at the beginning of payment, and is increased by one after the payment code completes a deduction request. When judging whether the payment times of the current deduction request meet the payment time threshold value, firstly, obtaining the times of the deduction request which is already paid by adopting the payment code. Assuming that the payment threshold is set to 5 times, if the current payment is 5 times, the transaction number of the current deduction request is 5 times, and the payment limit condition defined by the payment threshold is not met.

In the embodiment of the present specification, the payment restriction condition may be one or more. For example, the payment limit condition may be set as: the threshold value of the single payment amount is 100 yuan, the threshold value of the payment times is 3 times, the effective time range is 12 months and 15 days in 2018, the obtained deduction request is 'dress x short-sleeve x square 186 yuan 2018, 12 minutes in 12 months and 16 days in 16 months and 10 minutes in 16 months in 2018', the payment times of the payment code is 1 time, and then the corresponding transaction information is as follows: 160 yuan, 1 time, 12 minutes in 12 months, 16 days and 10 days in 2018, and through judgment, the payment time meets the payment time threshold, the initiation time of the deduction request is also within the effective time range of the payment code, but the deduction amount does not meet the single payment limit threshold, the transaction information can be determined not to meet the payment limiting condition, and therefore the current deduction request cannot be completed.

In the embodiment of the present specification, the payment restriction condition is not limited to only the set recited in the embodiment of the present specification, and may include: total payment threshold, regional limit, and payment domain limit. The regional restrictions may be limited to a city such as Beijing, Hangzhou and Guangzhou, and the payment area restrictions may be limited to buying clothes, supermarkets or train stations, etc.

Optionally, the deducting operation according to the deduction request specifically includes:

and deducting the deduction amount corresponding to the transaction information from the frozen amount determined in the generation process of the payment code.

In the embodiment of the present specification, when a deduction request is made, the amount of money corresponding to the deduction request is deducted. The payment amount of the payment code is reserved in advance and is the amount frozen from a payment account (such as balance, bank card). When the deduction is to be completed, the corresponding amount is deducted from the frozen amount, and the frozen amount needs to be updated to determine the remaining amount.

Optionally, after the deduction operation is performed according to the deduction request, the method further includes:

and when the valid time range of the payment code is determined to be exceeded, returning the rest part of the frozen amount to an account corresponding to the deduction channel.

In the embodiment of the specification, when the valid time range of the payment code is exceeded, the payment code is invalid, the transaction paid by using the payment code cannot be completed, the frozen amount is no longer useful, the server automatically judges whether the frozen amount is zero, and if the frozen amount is not zero, the frozen amount is returned to the account corresponding to the deduction channel.

Based on the same idea, the embodiment of the present specification further provides a device corresponding to the above method. Fig. 4 is a schematic structural diagram of a payment code generation apparatus corresponding to fig. 1 provided in an embodiment of the present disclosure. As shown in fig. 4, the apparatus may include:

an account information obtaining module 401, configured to obtain account information sent by a first terminal, where the first terminal is different from a binding device of the account information;

a first authentication information obtaining module 402, configured to obtain first authentication information sent by the first terminal;

a first verification module 403, configured to verify the first identity verification information to obtain a first verification result;

a payment code generating module 404, configured to generate a payment code corresponding to the account information when the first verification result indicates that the first authentication information is successfully verified;

a payment code sending module 405, configured to send the payment code to the first terminal.

Optionally, the apparatus further comprises:

and the payment condition determining module is used for determining a payment limiting condition before the generation of the payment code of the account information, wherein the payment limiting condition is used for restricting the off-line payment of the payment code.

Optionally, the payment condition determining module specifically includes:

the payment limit threshold value determining unit is used for determining a payment limit threshold value;

a payment number threshold determination unit for determining a payment number threshold;

an effective time range determination unit for determining an effective time range;

Optionally, the payment amount threshold determining unit specifically includes:

a first payment limit threshold acquisition subunit, configured to acquire a first payment limit threshold sent by the first terminal;

the second payment limit threshold determining subunit is used for determining a second payment limit threshold according to the account information;

a judgment subunit, configured to judge whether the first payment limit threshold is smaller than the second payment limit threshold;

and the first payment limit threshold determining subunit is used for determining that the first payment limit threshold is the payment limit threshold when the first payment limit threshold is smaller than the second payment limit threshold.

Optionally, the payment amount threshold determining unit further includes:

a second authentication information obtaining subunit, configured to obtain second authentication information sent by the first terminal when the first payment limit threshold is greater than or equal to the second payment limit threshold;

the second verification subunit is used for verifying the second identity verification information to obtain a second verification result;

and the second payment limit threshold determining subunit is used for determining that the first payment limit threshold is the payment limit threshold when the second verification result shows that the second identity verification information is verified successfully.

Optionally, the first authentication information obtaining module 402 is specifically configured to obtain password login information or biometric information.

Optionally, the apparatus further comprises:

the pre-deduction determining module is used for determining pre-deduction according to the payment limiting condition after the payment limiting condition is determined, and the pre-deduction is used for off-line payment of the payment code;

the deduction channel determining module is used for determining a deduction channel;

and the amount freezing module is used for freezing the amount corresponding to the pre-deduction from the appointed account according to the deduction channel.

Optionally, the money freezing module specifically includes:

the judging unit is used for judging whether the deduction channel is a third party payment channel;

the third-party payment tool calling unit is used for calling a third-party payment tool corresponding to the deduction channel when the deduction channel is a third-party payment channel;

the payment account determining unit is used for determining a payment account corresponding to the deduction channel;

and the amount freezing unit is used for freezing the amount corresponding to the pre-deduction from the payment account by using the third party payment tool.

Optionally, the withholding determining module is specifically configured to determine the product of the payment amount threshold and the payment time threshold as the amount of the withholding, where the payment amount threshold is a single payment amount threshold.

Optionally, the withholding determining module is specifically configured to determine the payment amount threshold as the amount of the withholding, where the payment amount threshold is a total payment amount threshold.

Based on the same idea, the embodiment of the present specification further provides a device corresponding to the above method. Fig. 5 is a schematic structural diagram of a payment code generation apparatus corresponding to fig. 2 provided in an embodiment of the present disclosure. As shown in fig. 5, the apparatus may include:

an account information obtaining module 501, configured to obtain account information by a first terminal; the first terminal is different from the binding equipment of the account information;

a first authentication information obtaining module 502, configured to obtain first authentication information;

a first sending module 503, configured to send the account information and the first identity verification information to a server;

a first receiving module 504, configured to receive a payment code of the account information sent by the server when the server determines that the first authentication information is successfully verified;

a payment code printing module 505, configured to print the payment code.

Optionally, the apparatus further comprises:

and the payment limiting condition acquisition module is used for acquiring a payment limiting condition input by a user before receiving the payment code of the account information sent by the server, wherein the payment limiting condition is used for restricting the off-line payment of the payment code.

Optionally, the payment limitation condition obtaining module specifically includes:

the payment limit threshold acquisition unit is used for acquiring a payment limit threshold;

a payment number threshold acquisition unit for acquiring a payment number threshold;

an effective time range acquisition unit for acquiring an effective time range;

Optionally, the apparatus further comprises:

the deduction channel acquisition module is used for acquiring a deduction channel input by a user after the payment limiting condition input by the user is acquired, wherein the deduction channel represents a deduction channel of the amount of the payment code for payment;

and the deduction channel sending module is used for sending the deduction channel to a server.

Optionally, the first authentication information obtaining module 502 is specifically configured to obtain password login information or biometric information.

Optionally, the payment amount threshold obtaining unit specifically includes:

the first payment amount information acquisition subunit is used for acquiring first payment amount information;

the device, still include:

the safety verification instruction receiving module is used for receiving a safety verification instruction returned by the server; the safety verification instruction is generated after the server determines that the first payment limit information is larger than the preset payment limit of the account;

the display module is used for displaying the verification information input interface;

the second identity authentication information acquisition module is used for acquiring second identity authentication information input based on the authentication information input interface;

and the second sending module is used for sending the second identity authentication information to the server.

Based on the same idea, the embodiment of the present specification further provides a device corresponding to the above method. Fig. 6 is a schematic structural diagram of a mobile payment device corresponding to fig. 3 provided in an embodiment of the present specification. As shown in fig. 6, the apparatus may include:

a deduction request obtaining module 601, configured to obtain a deduction request for the payment code;

a transaction information determining module 602, configured to determine transaction information corresponding to the deduction request;

a payment restriction condition determining module 603, configured to determine a payment restriction condition of the payment code;

a determining module 604, configured to determine whether the transaction information meets the payment limiting condition;

and a deduction operation module 605, configured to, when the transaction information meets the payment limiting condition, perform a deduction operation according to the deduction request.

Optionally, the payment limitation condition determining module 603 is specifically configured to determine a payment amount threshold;

the determining module 604 specifically includes:

the deduction amount determining unit is used for determining the deduction amount of the transaction information;

and the first judgment unit is used for judging whether the deduction amount is smaller than the payment amount threshold value or not.

Optionally, the payment limitation condition determining module 603 is specifically configured to determine a payment number threshold,

the determining module 604 specifically includes:

a payment number obtaining unit for obtaining the payment number of the payment code;

a second judging unit, configured to judge whether the payment time is smaller than the payment time threshold;

the device, still include:

and the payment number adding module is used for adding one to the payment number of the payment code after the deduction operation is carried out according to the deduction request.

Optionally, the payment limitation condition determining module 603 is specifically configured to determine an effective time range,

the determining module 604 specifically includes:

and the third judging unit is used for judging whether the initiating time of the transaction information belongs to the valid time range.

Optionally, the deduction operation module 605 is specifically configured to deduct a deduction amount corresponding to the transaction information from the frozen amount determined in the generation process of the payment code.

Optionally, the apparatus further includes:

and the frozen amount judgment module is used for returning the rest of the frozen amount to an account corresponding to the deduction channel when the valid time range of the payment code is determined to be exceeded after the deduction operation is carried out according to the deduction request.

Based on the same idea, the embodiment of the present specification further provides a device corresponding to the above method.

Fig. 7 is a schematic structural diagram of a payment code generation apparatus corresponding to fig. 1 provided in an embodiment of this specification. As shown in fig. 7, the apparatus 700 may include:

at least one processor 710; and the number of the first and second groups,

a memory 730 communicatively coupled to the at least one processor; wherein the content of the first and second substances,

the memory 730 stores instructions 720 executable by the at least one processor 710 to enable the at least one processor 710 to:

acquiring first identity authentication information sent by the first terminal;

and sending the payment code to the first terminal.

Fig. 8 is a schematic structural diagram of a payment code generation apparatus corresponding to fig. 2 provided in an embodiment of the present specification. As shown in fig. 8, the apparatus 800 may include:

at least one processor 810; and the number of the first and second groups,

a memory 830 communicatively coupled to the at least one processor; wherein the content of the first and second substances,

the memory 830 stores instructions 820 executable by the at least one processor 810 to enable the at least one processor 810 to:

the method comprises the steps that a first terminal obtains account information; the first terminal is different from the binding equipment of the account information;

acquiring first identity verification information;

printing the payment code.

Fig. 9 is a schematic structural diagram of a mobile payment device corresponding to fig. 3 provided in an embodiment of the present specification. As shown in fig. 9, the apparatus 900 may include:

at least one processor 910; and the number of the first and second groups,

a memory 930 communicatively coupled to the at least one processor; wherein the content of the first and second substances,

the memory 930 stores instructions 920 executable by the at least one processor 910 to enable the at least one processor 910 to:

acquiring a deduction request aiming at the payment code;

determining transaction information corresponding to the deduction request;

determining a payment limit condition of the payment code;

if yes, carrying out deduction operation according to the deduction request.

In the 90 s of the 20 th century, improvements in a technology could clearly distinguish between improvements in hardware (e.g., improvements in circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements in process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain the corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose Logic functions are determined by programming the Device by a user. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Furthermore, nowadays, instead of manually making an Integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development and writing, but the original code before compiling is also written by a specific Programming Language, which is called Hardware Description Language (HDL), and HDL is not only one but many, such as abel (advanced Boolean Expression Language), ahdl (alternate Hardware Description Language), traffic, pl (core universal Programming Language), HDCal (jhdware Description Language), lang, Lola, HDL, laspam, hardward Description Language (vhr Description Language), vhal (Hardware Description Language), and vhigh-Language, which are currently used in most common. It will also be apparent to those skilled in the art that hardware circuitry that implements the logical method flows can be readily obtained by merely slightly programming the method flows into an integrated circuit using the hardware description languages described above.

The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, and an embedded microcontroller, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, AtmelAT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic for the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller as pure computer readable program code, the same functionality can be implemented by logically programming method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Such a controller may thus be considered a hardware component, and the means included therein for performing the various functions may also be considered as a structure within the hardware component. Or even means for performing the functions may be regarded as being both a software module for performing the method and a structure within a hardware component.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smartphone, 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 convenience of description, the above devices are described as being divided into various units by function, and are described separately. Of course, the functionality of the units may be implemented in one or more software and/or hardware when implementing the present application.

As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention 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, and the like) having computer-usable program code embodied therein.

The present invention is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

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

The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, 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 disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

The application may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The application may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.

The above description is only an example of the present application and is not intended to limit the present application. Various modifications and changes may occur to those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

Claims

1. A payment code generation method, comprising:

acquiring first identity authentication information sent by the first terminal;

when the first verification result shows that the first identity verification information is verified successfully, generating a payment code corresponding to the account information according to the basic information of the account information and the payment habit information of the user; the payment code also comprises authorization information, and the authorization information comprises a payment amount upper limit, a payment time upper limit and an effective time range;

sending the payment code to the first terminal;

the payment habit information of the user comprises: the use frequency, the accumulated payment amount, the average amount of single payment and the historical daily average payment amount of the account;

before the generating the payment code of the account information, the method further includes: determining a payment condition, wherein the payment condition is used for restricting off-line payment of the payment code;

after the determining the payment limiting condition, the method further comprises:

determining a deduction channel;

2. The method according to claim 1, wherein the determining of the payment limiting condition specifically comprises:

determining a payment limit threshold;

and/or, determining a payment threshold;

and/or, determining an effective time range;

3. The method of claim 2, wherein the determining the payment amount threshold specifically comprises:

acquiring a first payment limit threshold value sent by the first terminal;

4. The method of claim 3, after determining whether the first payment value unit threshold is less than the second payment value unit threshold, further comprising:

5. The method of claim 1, wherein the obtaining the first authentication information specifically comprises:

password login information or biometric information is obtained.

6. The method according to claim 1, wherein the freezing of the amount of money corresponding to the pre-deduction from the designated account according to the deduction channel specifically comprises:

judging whether the deduction channel is a third party payment channel or not;

determining a payment account corresponding to the deduction channel;

7. The method according to claim 2, wherein the determining of the pre-deduction according to the payment limiting condition specifically includes:

8. The method according to claim 1, wherein the determining of the pre-deduction according to the payment limiting condition specifically includes:

9. A mobile payment method based on a payment code generated using the payment code generation method of claim 1, comprising:

acquiring a deduction request aiming at the payment code;

determining transaction information corresponding to the deduction request;

determining a payment limit condition of the payment code;

if yes, carrying out deduction operation according to the deduction request.

10. The method of claim 9, the payment limit condition comprising a payment amount threshold,

determining the deduction amount of the transaction information;

11. The method of claim 9, the payment limit condition comprising a payment number threshold,

acquiring the payment times of the payment code;

and adding one to the payment times of the payment code.

12. The method of claim 9, the payment limit condition comprising a validity time range,

13. The method according to claim 9, wherein the deduction operation according to the deduction request specifically includes:

14. The method of claim 13, further comprising, after said deduction operation according to said deduction request:

15. A payment code generation method, comprising:

acquiring first identity authentication information on a login interface of an authorization interface; the login interface of the authorization interface is different from the login interface of the user on the account information binding device;

when the server determines that the first identity verification information is verified successfully, receiving a payment code of the account information sent by the server; the server generates a payment code corresponding to the account information according to the basic information of the account information and the payment habit information of the user; the payment habit information of the user comprises: the use frequency, the accumulated payment amount, the average amount of single payment and the historical daily average payment amount of the account;

before the receiving the payment code of the account information sent by the server, the method further includes:

acquiring a payment limiting condition input by a user, wherein the payment limiting condition is used for restricting off-line payment of the payment code;

sending the payment limiting condition to a server; determining a pre-deduction according to the payment limiting condition, wherein the pre-deduction is used for off-line payment of the payment code;

determining a deduction channel;

freezing the amount corresponding to the pre-deduction from an appointed account according to the deduction channel;

printing the payment code.

16. The method according to claim 15, wherein the acquiring of the payment limiting condition input by the user specifically includes:

acquiring a payment limit threshold;

and/or, obtaining a payment number threshold;

and/or, obtaining an effective time range;

17. The method of claim 15, after said obtaining user-entered payment limit conditions, further comprising:

and sending the deduction channel to a server.

18. The method of claim 15, wherein the obtaining the first authentication information comprises:

password login information or biometric information is obtained.

19. The method of claim 15, wherein the obtaining of the payment amount threshold specifically comprises:

acquiring first payment limit information;

displaying a verification information input interface;

and sending the second authentication information to the server.

20. A payment code generation apparatus comprising:

the account information acquisition module is used for acquiring account information sent by a first terminal, and the first terminal is different from the binding equipment of the account information;

the payment code generation module is used for generating a payment code corresponding to the account information according to the basic information of the account information and the payment habit information of the user to generate the payment code corresponding to the account information when the first verification result shows that the first identity verification information is verified successfully; the payment code also comprises authorization information, and the authorization information comprises a payment amount upper limit, a payment time upper limit and an effective time range; the payment habit information of the user comprises: the use frequency, the accumulated payment amount, the average amount of single payment and the historical daily average payment amount of the account;

a payment condition determining module, configured to determine a payment condition before the generation of the payment code of the account information, where the payment condition is used to restrict offline payment of the payment code;

the pre-deduction freezing module is used for determining pre-deduction according to the payment limiting condition after the payment limiting condition is determined, and the pre-deduction is used for off-line payment of the payment code; determining a deduction channel; freezing the amount corresponding to the pre-deduction from an appointed account according to the deduction channel;

21. A mobile payment device, the payment code based on which is generated using the payment code generation method of claim 1, comprising:

22. A payment code generation apparatus comprising:

the first identity authentication information acquisition module is used for acquiring first identity authentication information on a login interface of the authorization interface; the login interface of the authorization interface is different from the login interface of the user on the account information binding device;

the first receiving module is used for receiving the payment code of the account information sent by the server when the server determines that the first identity verification information is verified successfully; the server generates a payment code corresponding to the account information according to the basic information of the account information and the payment habit information of the user; the payment habit information of the user comprises: the use frequency, the accumulated payment amount, the average amount of single payment and the historical daily average payment amount of the account;

and the payment code printing module is used for printing the payment code.

23. A payment code generation apparatus comprising:

at least one processor; and the number of the first and second groups,

acquiring first identity authentication information sent by the first terminal;

when the first verification result shows that the first identity verification information is verified successfully, generating a payment code corresponding to the account information according to the basic information of the account information and the payment habit information of the user; generating a payment code corresponding to the account information; the payment code also comprises authorization information, and the authorization information comprises a payment amount upper limit, a payment time upper limit and an effective time range; the payment habit information of the user comprises: the use frequency, the accumulated payment amount, the average amount of single payment and the historical daily average payment amount of the account;

sending the payment code to the first terminal;

before the generating the payment code of the account information, further comprising: determining a payment condition, wherein the payment condition is used for restricting off-line payment of the payment code;

after the determining the payment limiting condition, further comprising: determining a pre-deduction according to the payment limiting condition, wherein the pre-deduction is used for off-line payment of the payment code; determining a deduction channel; and freezing the amount corresponding to the pre-deduction from the appointed account according to the deduction channel.

24. A payment code generation apparatus comprising:

at least one processor; and the number of the first and second groups,

printing the payment code;

25. A mobile payment device comprising:

at least one processor; and the number of the first and second groups,

acquiring account information, wherein the mobile payment equipment is different from the binding equipment of the account information;

determining a deduction channel;

printing the payment code.