WO2020114113A1 - 支付码生成、移动支付方法、装置及设备 - Google Patents

支付码生成、移动支付方法、装置及设备 Download PDF

Info

Publication number
WO2020114113A1
WO2020114113A1 PCT/CN2019/112170 CN2019112170W WO2020114113A1 WO 2020114113 A1 WO2020114113 A1 WO 2020114113A1 CN 2019112170 W CN2019112170 W CN 2019112170W WO 2020114113 A1 WO2020114113 A1 WO 2020114113A1
Authority
WO
WIPO (PCT)
Prior art keywords
payment
information
threshold
amount
deduction
Prior art date
Application number
PCT/CN2019/112170
Other languages
English (en)
French (fr)
Inventor
周孝佳
Original Assignee
阿里巴巴集团控股有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 阿里巴巴集团控股有限公司 filed Critical 阿里巴巴集团控股有限公司
Publication of WO2020114113A1 publication Critical patent/WO2020114113A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4014—Identity check for transactions

Definitions

  • the present application relates to the field of computer technology, and in particular, to a payment code generation, mobile payment method, device, and equipment.
  • embodiments of the present application provide a payment code generation, mobile payment method, device, and device, which are used to improve the convenience of mobile payment.
  • the first terminal obtains account information, and the first terminal is different from the account information binding device;
  • An account information obtaining module configured to obtain account information sent by a first terminal; the first terminal is different from the account information binding device;
  • a first identity verification information acquiring module configured to acquire the first identity verification information sent by the first terminal
  • a first verification module configured to verify the first identity verification information to obtain a first verification result
  • a payment code generation module configured to generate a payment code corresponding to the account information when the first verification result indicates that the verification of the first identity verification information is successful
  • the payment code sending module is configured to send the payment code to the first terminal.
  • a deduction request acquisition module used to obtain a deduction request for the payment code
  • the transaction information determination module is used to determine the transaction information corresponding to the deduction request
  • a payment restriction condition determination module used to determine the payment restriction condition of the payment code
  • the judgment module is used to judge whether the transaction information meets the payment restriction condition
  • the deduction operation module is used to perform a deduction operation according to the deduction request when the transaction information meets the payment restriction condition.
  • An account information acquisition module used for acquiring account information by a first terminal, where the first terminal is different from the account information binding device;
  • a first identity verification information acquisition module used to acquire the first identity verification information
  • a first sending module configured to send the account information and the first identity verification information to a server
  • a first receiving module configured to receive the payment code of the account information sent by the server when the server determines that the verification of the first identity verification information is successful
  • the payment code printing module is used to print the payment code.
  • At least one processor and,
  • a memory communicatively connected to the at least one processor; wherein,
  • the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to:
  • At least one processor and,
  • a memory communicatively connected to the at least one processor; wherein,
  • the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to:
  • the first terminal obtains account information, and the first terminal is different from the account information binding device;
  • At least one processor and,
  • a memory communicatively connected to the at least one processor; wherein,
  • the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to:
  • an authorized payment code for the account is generated to solve the mobile payment problem when the user's mobile phone is not around or unavailable, which improves the mobile payment Convenience.
  • FIG. 1 is a schematic flowchart of a method for generating a payment code according to Embodiment 1 of the present specification
  • FIG. 2 is a schematic flowchart of a method for generating a payment code according to Embodiment 2 of the present specification
  • FIG. 3 is a schematic flowchart of a mobile payment method according to Embodiment 3 of this specification.
  • FIG. 4 is a schematic structural diagram of a payment code generation device corresponding to FIG. 1 provided by an embodiment of the present specification
  • FIG. 5 is a schematic structural diagram of a payment code generation device corresponding to FIG. 2 provided by an embodiment of the present specification
  • FIG. 6 is a schematic structural diagram of a mobile payment device corresponding to FIG. 3 provided by an embodiment of the present specification
  • FIG. 7 is a schematic structural diagram of a payment code generation device corresponding to FIG. 1 provided by an embodiment of the present specification
  • FIG. 8 is a schematic structural diagram of a payment code generation device corresponding to FIG. 2 provided by an embodiment of the present specification
  • FIG. 9 is a schematic structural diagram of a mobile payment device corresponding to FIG. 3 provided by an embodiment of the present specification.
  • FIG. 1 is a schematic flowchart of a payment code generation method according to Embodiment 1 of the present specification.
  • the execution subject of the process may be a program or an application client mounted on the application server.
  • the process can include the following steps:
  • S101 Acquire account information sent by a first terminal, where the first terminal is different from the account information binding device.
  • the first terminal device may be a computer arranged by a service provider at a mall, restaurant, station, etc., or may be a mobile smart terminal, tablet computer, notebook computer, etc. owned by another person.
  • the user cannot use his own mobile phone (that is, the account information binding device) for mobile payment, he can log in on the first terminal device, for example, enter his own user name, account bound mobile phone number, email, etc., and then the server Obtain account information sent by the first terminal.
  • the account information may include the account identifier and the account information sending device.
  • the server first needs to determine whether the sending device and the account information binding device are the same, because the method provided in the embodiments of this specification is for Solve the problem of mobile payment when the user's mobile phone is not around or cannot be used, so only when they are different are the methods defined in the embodiments of the present specification.
  • the server In order to verify the account information, the server also needs to obtain the identity verification information corresponding to the account, which can be password login information or biometric information, such as fingerprint characteristics or facial characteristics.
  • the server After receiving the first identity verification information, the server compares the verification information with the registration information saved by the user during registration. If the two match, it can be determined that the verification is passed, otherwise the verification is not passed.
  • the server can also adopt risk control measures, such as discovering that the device logged in by the user has changed, and can combine user name, password verification and biometric verification, such as comparing the user name and password first, and then comparing the biometrics after passing , Both are verified to be verified.
  • risk control measures such as discovering that the device logged in by the user has changed, and can combine user name, password verification and biometric verification, such as comparing the user name and password first, and then comparing the biometrics after passing , Both are verified to be verified.
  • risk control measures can also be adopted, for example, if the user enters a user name and the number of incorrect passwords reaches the upper limit, the user's account is locked.
  • Specific risk control measures can be set according to specific application needs.
  • the server will generate the payment code of the account based on the basic information of the account and the payment habits of the user.
  • the payment code may also authorize the information.
  • the authorization information may include the upper limit of the payment amount, the upper limit of the number of payments and the validity Time range, etc.
  • the basic information includes: a user name; the payment habits information of the user includes: frequency of use, cumulative payment amount, average amount of a single payment, and historical daily average payment amount of the account.
  • the server can also allow users to select or enter their own authorization information through the provided authorization page; generally speaking, the authorization information can include the effective time of the payment code.
  • the server determines the restriction conditions of the payment code used for offline payment based on the authorization information input by the user and the information of the account itself. If the authorization information entered by the user does not match the account's own information, secondary identity verification or other risk control measures can also be performed.
  • the server can also randomly generate a 6-digit password, which corresponds to the payment code generated this time. Every time the payment code is used for payment, the user is required to enter a 6-digit password, and only after successful input can payment be successful. Normally, the 6-digit password can also be reserved by the user himself.
  • S105 Send the payment code to the first terminal.
  • the server sends the payment code with the authorization information of the account to the first terminal, and the first terminal can display the payment code as a barcode and/or a two-dimensional code according to the coding rule of the barcode, for offline payment, or other operations , Such as adding friends or groups.
  • the payment code may include an identifier of a user account, such as an account name.
  • the payment code can also be printed out to make offline payment in the form of a flat printed matter, and the payment code can be transferred by taking a screenshot of the latter to take pictures in order to achieve The function of mobile payment on the terminal device (unlike the binding device of account information).
  • the method in Figure 1 generates an authorized payment code for the account by verifying the account and identity information entered by the user on the terminal of the non-account binding device, which is used to solve the mobile payment problem when the user's mobile phone is not around or unavailable , Improve the convenience of mobile payment.
  • the method before generating the payment code of the account information, the method further includes:
  • a payment restriction condition is determined, and the payment restriction condition is used to restrict offline payment of the payment code.
  • payment restriction conditions may be added to limit the offline payment of the payment code, and the effective time of the payment code, the payment amount, etc. may be limited.
  • these payment restriction conditions can be generated according to the user's operating habits, or based on the information filled in by the user on the authorization page of the first terminal, or can be generated by combining the above two situations.
  • the determination of the payment restriction condition specifically includes:
  • the payment amount threshold is used to define the upper limit of the payment amount of the payment code
  • the payment number threshold is used to limit the number of payments of the payment code within the effective time range, and the payment code is within the effective time range Valid within.
  • the payment limit may be the upper limit of the single payment limit or the upper limit of the total payment limit.
  • the payment limit can pay the upper limit of the total amount, such as 500 yuan or 1,000 yuan.
  • the threshold of the number of payment times may be set according to the actual scenario of the user, and may be one time or multiple times, which may be related to the threshold of the payment amount.
  • the time range of the payment code can be determined according to the actual situation of the user. For security reasons, it can be 3 hours, 5 hours, generally within 24 hours, or of course, 2 days , Or longer.
  • the threshold for the payment amount, the threshold for the number of times of payment, and the effective time range may be set individually, or may be set simultaneously.
  • the method provided in the embodiment of this specification can also be used in the following scenarios. For example, you can replace the pocket money for the child with the payment code provided by the above method, limit the maximum amount of each payment, and the number of payments, thereby avoiding the loss of the child The loss caused by money, or the trouble caused by the lack of change.
  • the determination of the payment amount threshold specifically includes:
  • the first payment quota threshold is the payment quota threshold.
  • the limit of the payment limit entered by the user is often more than the amount he usually uses to pay in the account.
  • the user needs to authorize the payment to exceed the limit of the payment limit generated by the account (such as 500 yuan )
  • the second payment threshold 500 yuan
  • the second payment threshold 500 yuan
  • the user will not be able to use the payment code to complete a large payment request (1500 yuan for gold and silver jewelry). Therefore, it is necessary to use the first payment amount threshold input by a user such as the user as the payment amount limit.
  • the method further includes:
  • the first payment limit threshold is the payment limit threshold.
  • the first payment threshold entered by the user is greater than the second payment threshold (preset payment threshold) generated based on the account information, if the first payment threshold is used as the payment threshold, the security of the payment code The coefficient will be reduced. In order to avoid this situation, it is necessary to perform secondary identity verification and determine the payment threshold based on the secondary verification results.
  • the second identity verification information is mainly to further verify whether the user of the account is performing the authorization operation.
  • the second identity verification information can be more detailed or stricter than the first identity verification information, and can adopt face information or palm print information.
  • the method further includes:
  • the withholding amount is used for offline payment of the payment code
  • the amount corresponding to the withholding amount is frozen from the designated account according to the deduction channel.
  • the deduction channel of the payment amount in advance, that is, how much money is deducted from what account to pay, that is, the deduction must be determined in advance.
  • the deduction channel of the account is similar to the payment channel.
  • the server can use the default payment channel of the account for deduction, or deduct the payment according to the payment mode selected by the user, such as balance, balance treasure, ant flower chant, bank card, etc.
  • the account default or the account balance corresponding to the payment channel selected by the user is 600 yuan, which is greater than the amount of the withholding amount (500 yuan), then it is sufficient to directly freeze 500 yuan from the corresponding account. If the account balance is 200 yuan, less than 500 Yuan, you need to freeze the amount from other accounts, which can be the second default account, or you can let the user choose again until the corresponding account has enough balance to freeze the amount of the withholding amount.
  • the deduction channel is an internal payment tool, such as balance and balance treasure
  • the amount will be frozen from within the user account, and the frozen amount will only be able to pay the deduction request initiated by the payment code, and will no longer be used for other purposes.
  • the deduction of the amount corresponding to the withholding amount from the designated account according to the deduction channel specifically includes:
  • the server determines that the debit channel is a third-party payment channel, it needs to call a third-party payment tool, such as a program in a banking system or a program in another APP. Then, the third party payment tool is used to freeze the amount corresponding to the withholding amount from the payment account, and the frozen amount will only be able to pay the deduction request initiated by the payment code, and is no longer used for other purposes.
  • a third-party payment tool such as a program in a banking system or a program in another APP.
  • the determining the withholding amount according to the payment restriction condition specifically includes:
  • the product of the payment amount threshold and the payment number threshold is determined as the amount of the withholding amount, wherein the payment amount threshold is a single payment amount threshold.
  • the determining the withholding amount according to the payment restriction condition specifically includes:
  • the payment amount threshold is determined to be the amount of the withholding amount, wherein the payment amount threshold is the total payment amount threshold.
  • the amount of withholding is the payment threshold, for example, the payment threshold is 500 yuan, then no matter how many times the payment is made, the amount of multiple payments will not exceed 500 yuan, then the prepayment The deduction amount is 500 yuan.
  • FIG. 2 is a schematic flowchart of a payment code generation method according to Embodiment 2 of the present specification. From the perspective of the program, the execution subject of the process is the first terminal.
  • the process may include the following steps:
  • S201 The first terminal obtains account information; the first terminal is different from the account information binding device.
  • the first terminal may be a computer arranged by a service provider at a mall, restaurant, station, etc., or may be a mobile smart terminal, tablet computer, notebook computer, etc. owned by another person.
  • the user cannot use his own mobile phone (that is, the device bound to the account information) for mobile payment, he can log in on the first terminal device, for example, enter his user name, mobile phone number bound to the account, mailbox, and so on.
  • the first terminal presents to the user a login interface in an authorization interface. It can be understood that the login interface here is different from the user's login interface on the account information binding device in a normal state.
  • the first terminal is a computer arranged by a service provider in a mall, restaurant, station, etc., it is a device terminal with only specific functions, which is different from the account information binding device (mobile smart terminal, tablet or laptop) , That is, it can only be used as an authorization service for offline payment, and does not have other functions of mobile payment terminals, so there is only one login interface, and this login interface can be made into a login interface on the device bound to the user’s account information different.
  • the first terminal is a mobile smart terminal, tablet, laptop, etc. owned by another person, which is the same as the device that binds the account information, you can make a separate authorization interface, and choose a login interface that only has the authorization function when logging in .
  • Obtain the first identity verification information in the login interface of the authorization interface of the first terminal which can be password login information or biometric information, such as fingerprint characteristics or facial characteristics, and can also combine user name, password and biometric multiple verification To improve safety. For example, compare the user name and password first, and then compare the biometrics after passing.
  • S203 Send the account information and the first identity verification information to the server.
  • the account information and the first identity verification information may be sent to the server at the same time, or may not be at the same time, that is, the account information is sent first, and then the first identity verification information is sent.
  • the first identity verification information may be one piece or two pieces, and may be in a sequential order or may not be in a sequential order.
  • the first identity verification information includes the account password and biometrics. The first terminal can simultaneously send the acquired account password and biometrics to the server for verification; it can also send the account password to the server for verification once, and then send the biometric The feature is sent to the server for secondary verification.
  • the server when the server determines that the first identity verification information is successfully verified, the first terminal will receive a payment code carrying authorization information for offline payment.
  • the payment code may be a two-dimensional code or a barcode, and the payment code contains the user's identification.
  • the first terminal may be a device terminal with its own printing function, and the payment code may be printed directly; or it may be wirelessly or wirelessly connected to the printer, and then printed.
  • identity verification can also be performed. For example, when paying offline, you need to provide the payment password of the account or the bound mobile phone number, or the user's biometric information, etc., only after passing the verification, the payment To succeed.
  • the payment code is printed out, which is convenient for carrying. Users can set aside mobile phones and other electronic devices to more conveniently enjoy or use the benefits of payment codes. It has further promoted the popularization of electronic currency.
  • the method before receiving the payment code of the account information sent by the server, the method further includes: obtaining a payment restriction condition input by a user, where the payment restriction condition is used to restrict offline payment of the payment code.
  • payment restriction conditions can be added to limit the offline payment of the payment code, the effective time of the payment code, the payment amount, etc. can be limited.
  • the server determines that the first identity verification information is successfully verified, or returns to the first terminal a payment restriction condition interface to be presented to the user, the user can select a corresponding check or input on the interface according to his actual situation, the first terminal After obtaining the information entered by the user, it is returned to the server.
  • the acquiring the payment restriction condition input by the user specifically includes:
  • the payment amount threshold is used to define the upper limit of the payment amount of the payment code
  • the payment number threshold is used to limit the number of payments of the payment code within the effective time range, and the payment code is within the effective time range Valid within.
  • the first terminal may present various restriction conditions to the user, for example, a payment amount threshold, a payment number threshold, and a valid time range.
  • the user can select the corresponding category as needed. The user's choice can be one of them, or multiple.
  • the single payment threshold there are two types of payment thresholds, one is the single payment threshold, and the other is the total payment threshold. If the user needs to pay for multiple small amounts of items, you can choose a single payment The payment threshold is 50 yuan, and the payment threshold is 10. If the user needs to pay a large amount of items, then the total payment threshold is 500 yuan, and the payment threshold is 1 time.
  • the effective time range is very important for the payment code. If the effective time range of the payment code is not limited, the payment code will be valid for a long time. 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 the occurrence of such problems, in the embodiment of the present specification, the effective time range is limited, which may be 2 hours, 3 hours, 8 hours, usually not more than 24 hours. Of course, there is no exclusion, such as 7 days.
  • the effective area of the payment code can also be limited, for example, only to a certain city, such as Beijing, Hangzhou, and Guangzhou, and the payment field of the payment code can also be limited, for example, only limited to Buy clothes, supermarkets or train stations.
  • the method further includes:
  • the deduction channel represents a deduction channel for the amount paid by the payment code
  • the deduction channel may be that the server presents the deduction method in the account information to the first terminal for the customer to choose.
  • the deduction channel can be an internal payment tool, such as balance, coin purse, etc., or an external payment tool, that is, the server needs to call a third-party payment tool, such as a bank card, and needs to call the corresponding bank system for the deduction operation.
  • the obtaining the payment amount threshold specifically includes:
  • the method further includes:
  • the security verification instruction is generated after the server determines that the first payment amount information is greater than the preset payment amount of the account
  • the determination of the threshold for the payment amount may be jointly determined based on the user's account information and the user's input information. If the threshold value of the first payment amount that the user wants to obtain is greater than the preset payment amount generated according to the account information, the identity of the user needs to be further determined, and the second identity verification information can be obtained.
  • the second identity verification information is mainly to further verify whether the user of the account is performing the authorization operation. Generally, the second identity verification information can be more detailed or stricter than the first identity verification information, and can adopt face information or palm print information. , You can also enter the ID number of the account for real-name authentication. Further, you can also provide several consumption items to let the user confirm which one or which is generated by the account. If the verification of the second identity verification information is successful, a payment amount permission with a relatively large payment code, that is, a first payment amount threshold requested by the user, may be granted.
  • the embodiments of the present specification also provide a mobile payment method of a payment code for the payment code generated by the above method.
  • FIG. 3 is a schematic flowchart of a mobile payment method for a payment code provided in Embodiment 3 of the present specification. From the perspective of the program, the execution subject of the process may be a program or an application client mounted on the application server.
  • the process may include the following steps:
  • the payment code is used in the same way as other dynamic payment codes presented on the mobile terminal.
  • the payment terminal is requested to scan the payment code to generate a deduction request
  • the deduction request may include the originator of the deduction request, the scanned payment code information, and the deduction amount.
  • the request payment terminal can be a scanning gun or a fixed scanning device.
  • the deduction request contains a lot of information. After the server obtains the deduction request, only some important information needs to be extracted, for example: the originating end of the deduction request, the initiation time of the deduction request, the payment account number, Deduction amount, etc.
  • the transaction information of a charge-back request can be expressed as: "F&B ⁇ Spicy Hot ⁇ Food City 46 Yuan”.
  • the server since the case of using this payment code to make a payment is different from the case where the binding device of the account information corresponding to the payment code makes a payment, the server calls the payment program corresponding to the payment code according to the deduction request, Determine the payment restriction conditions of the payment code.
  • the payment restriction here is already stored by the server, and it can be called directly.
  • the transaction information that needs to be determined for the deduction request is often related to the payment restriction conditions. For example, if the payment restriction conditions include a valid time range, then the transaction information needs to include the time when the deduction request was initiated, that is, “catering ⁇ 46 ⁇ 14:35 on December 12, 2018”
  • a pair of payment restriction conditions are required to be judged, and only when all the conditions are met, it indicates that the transaction information meets the payment code.
  • the payment restriction condition includes a payment amount threshold
  • the payment restriction condition limits the payment amount threshold, then it is necessary to determine whether the deduction amount of the transaction information meets the payment amount threshold. If the limit is a single payment threshold, if the deduction amount is less than the single payment threshold, it means that the transaction information meets the payment limit. Assuming that the threshold for the single payment limit is set to 50 yuan, and the debit request is "F&B ⁇ Spicy ⁇ Gourmet City 46 yuan, the transaction information at 14:35 on December 12, 2018” is 46 yuan, then the transaction information is satisfied Payment restrictions. If the single payment threshold is set to 40 yuan, then the transaction information does not meet the payment limit.
  • the limit is the total payment threshold, and the total amount of the deduction cannot exceed the total payment threshold, it means that the transaction information meets the payment limit.
  • the deduction amount is 46 for the "Food and Beverage XL Spicy Food 46 yuan at 14:35 on December 12, 2018", and the payment code has been paid
  • the amount is 412 yuan, then the transaction information of the current deduction amount is 458 yuan, less than 500 yuan, then the transaction information meets the payment restriction conditions.
  • the payment restriction condition includes a valid time range
  • the payment restriction condition limits the effective time range, then it is necessary to determine whether the initiation time of the transaction information conforms to the effective time range. Assuming that the set limited time range is from 12:00 on December 12th, 2018 to 18:00 on December 12th, 2018, the deduction request is "Dining ⁇ ⁇ Spicy Hot ⁇ ⁇ Food City 46 yuan 14:35 on December 12, 2018 The transaction information of "point” is within the range of 14:35 on December 12, 2018, and the time from 14:35 on December 12, 2018 is between 12:30 on December 12, 2018 and 18:00 on December 12, 2018. Within, then the transaction information meets the payment restriction conditions.
  • the payment restriction condition includes a threshold of payment times
  • the method further includes:
  • the payment restriction condition limits the number of payments, and the number of payments is formed at the end of the payment code. At the beginning of payment, the number of payments is zero. After the payment code completes a deduction request, the payment Add one to the number of payments. When determining whether the number of payment times of the current deduction request meets the threshold of the number of payment times, first of all, the number of times the payment deduction request has been paid using the payment code must be obtained. Assuming that the threshold of the number of payment times is set to 5, if the current number of payment times is 5, the current number of transactions for the deduction request is 5 times, which does not meet the payment restriction conditions defined by the threshold of the number of payment times.
  • the payment restriction condition may be one kind or multiple kinds.
  • the payment limit can be set as follows: the threshold for a single payment amount is 100 yuan, the threshold for the number of payment times is 3, the valid time range is December 15, 2018, and the deduction request obtained is "Clothing ⁇ Plaza 186 yuan at 10:12 on December 16, 2018", the payment code is paid once, then the corresponding transaction information is: 160 yuan, once, at 10:12 on December 16, 2018, after Judging, it can be concluded that the number of payment times meets the threshold of the number of payment times, and 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 threshold of the single payment amount, then it can be determined that the transaction information does not meet the payment limit Conditions, therefore, the current charge request cannot be completed.
  • the payment restriction condition is not limited to the concentration listed in the embodiment of the present specification, but may also include: a total payment amount threshold, a regional limit, and a payment field limit.
  • Regional restrictions can be limited to certain cities, such as Beijing, Hangzhou, and Guangzhou, and payment field restrictions can be limited to buying clothes, supermarkets, or train stations.
  • the deduction operation according to the deduction request specifically includes:
  • the deduction amount corresponding to the transaction information is deducted from the frozen amount determined during the generation of the payment code.
  • the amount 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).
  • a payment account such as balance, bank card.
  • the method further includes:
  • the remaining part of the frozen amount is returned to the account corresponding to the deduction channel.
  • the effective time range of the payment code when the effective time range of the payment code is exceeded, it means that the payment code has expired, and the transaction using the payment code will no longer be completed. At this time, the frozen amount is no longer useful, and the server will automatically determine Whether the frozen amount is zero, if not, return the frozen amount to the account corresponding to the debit channel.
  • FIG. 4 is a schematic structural diagram of a payment code generation device corresponding to FIG. 1 provided by an embodiment of the present specification. As shown in FIG. 4, the device may include:
  • the account information obtaining module 401 is used to obtain account information sent by a first terminal, and the first terminal is different from the account information binding device;
  • a first identity verification information acquiring module 402 configured to acquire first identity verification information sent by the first terminal
  • the first verification module 403 is used to verify the first identity verification information to obtain a first verification result
  • the payment code generation module 404 is configured to generate a payment code corresponding to the account information when the first verification result indicates that the verification of the first identity verification information is successful;
  • the payment code sending module 405 is configured to send the payment code to the first terminal.
  • the device further includes:
  • the payment condition determination module is configured to determine a payment restriction condition before the payment code that generates the account information, and the payment restriction condition is used to restrict offline payment of the payment code.
  • the payment condition determination module specifically includes:
  • the payment amount threshold determination unit is used to determine the payment amount threshold
  • a threshold for determining the number of times of payment which is used to determine the threshold of the number of times of payment
  • Effective time range determination unit used to determine the effective time range
  • the payment amount threshold is used to define the upper limit of the payment amount of the payment code
  • the payment number threshold is used to limit the number of payments of the payment code within the effective time range, and the payment code is within the effective time range Valid within.
  • the payment amount threshold determination unit specifically includes:
  • a first payment quota threshold acquisition subunit configured to acquire a first payment quota threshold sent by the first terminal
  • a second payment quota threshold determination subunit configured to determine a second payment quota threshold based on the account information
  • a judgment subunit used to judge whether the first payment quota threshold is smaller than the second payment quota threshold
  • the first payment quota threshold determination subunit is configured to determine that the first payment quota threshold is the payment quota threshold when the first payment quota threshold is less than the second payment quota threshold.
  • the payment amount threshold determination unit further includes:
  • a second identity verification information acquisition subunit configured to acquire second identity verification information sent by the first terminal when the first payment quota threshold is greater than or equal to the second payment quota threshold;
  • a second verification subunit configured to verify the second identity verification information to obtain a second verification result
  • the second payment quota threshold determination subunit is configured to determine that the first payment quota threshold is the payment quota threshold when the second verification result indicates that the second identity verification information is successfully verified.
  • the first identity verification information acquisition module 402 is specifically used to acquire password login information or biometric information.
  • the device further includes:
  • a withholding payment determination module configured to determine withholding payment according to the payment limiting condition after the determination of the payment limitation condition, the withholding payment is used for offline payment of the payment code;
  • Deduction channel determination module used to determine the deduction channel
  • the amount freezing module is used to freeze the amount corresponding to the withholding amount from the specified account according to the deduction channel.
  • the amount freezing module specifically includes:
  • the judgment unit is used to judge whether the deduction channel is a third-party payment channel
  • a third-party payment tool calling unit used to call a third-party payment tool corresponding to the deduction channel when the deduction channel is a third-party payment channel;
  • a payment account determination unit used to determine a payment account corresponding to the deduction channel
  • the amount freezing unit is used to freeze the amount corresponding to the withholding amount from the payment account using the third-party payment tool.
  • the withholding amount determination module is specifically configured to determine the product of the payment amount threshold and the payment number threshold as the amount of the withholding amount, wherein the payment amount threshold is a single payment Quota threshold.
  • the withholding amount determination module is specifically configured to determine the payment amount threshold as the amount of the withholding amount, wherein the payment amount threshold is the total payment amount threshold.
  • FIG. 5 is a schematic structural diagram of a payment code generation device corresponding to FIG. 2 provided by an embodiment of the present specification. As shown in FIG. 5, the device may include:
  • the account information obtaining module 501 is used for the first terminal to obtain account information; the first terminal is different from the account information binding device;
  • the first identity verification information acquisition module 502 is used to acquire the first identity verification information
  • a first sending module 503, configured to send the account information and the first identity verification information to a server
  • the first receiving module 504 is configured to receive the payment code of the account information sent by the server when the server determines that the verification of the first identity verification information is successful;
  • the payment code printing module 505 is used to print the payment code.
  • the device further includes:
  • a payment restriction condition acquisition module configured to obtain a payment restriction condition input by a user before the payment code for receiving the account information sent by the server is received, and the payment restriction condition is used to restrict offline payment of the payment code .
  • the payment restriction condition acquisition module specifically includes:
  • a payment quota threshold acquisition unit used to acquire a payment quota threshold
  • a payment frequency threshold acquisition unit which is used to acquire a payment frequency threshold
  • Effective time range acquisition unit used to acquire effective time range
  • the payment amount threshold is used to define the upper limit of the payment amount of the payment code
  • the payment number threshold is used to limit the number of payments of the payment code within the effective time range, and the payment code is within the effective time range Valid within.
  • the device further includes:
  • a deduction channel obtaining module configured to obtain a deduction channel input by the user after obtaining the payment restriction condition input by the user, and the deduction channel represents a deduction channel for the amount paid by the payment code;
  • the deduction channel sending module is used to send the deduction channel to the server.
  • the first identity verification information acquisition module 502 is specifically used to acquire password login information or biometric information.
  • the payment quota threshold acquisition unit specifically includes:
  • a first payment quota information acquisition subunit used to acquire first payment quota information
  • the device also includes:
  • a security verification instruction receiving module configured to receive the security verification instruction returned by the server; the security verification instruction is generated after the server determines that the first payment amount information is greater than the preset payment amount of the account;
  • Display module used to display the verification information input interface
  • a second identity verification information acquiring module configured to acquire second identity verification information input based on the verification information input interface
  • the second sending module is configured to send the second identity verification information to the server.
  • FIG. 6 is a schematic structural diagram of a mobile payment device corresponding to FIG. 3 provided by an embodiment of the present specification. As shown in FIG. 6, the device may include:
  • the deduction request obtaining module 601 is used to obtain a deduction request for the payment code
  • the transaction information determination module 602 is used to determine the transaction information corresponding to the deduction request
  • the payment restriction condition determination module 603 is used to determine the payment restriction condition of the payment code
  • the judgment module 604 is used to judge whether the transaction information meets the payment restriction condition
  • the deduction operation module 605 is configured to perform a deduction operation according to the deduction request when the transaction information meets the payment restriction condition.
  • the payment restriction condition determination module 603 is specifically used to determine a payment amount threshold
  • the judgment module 604 specifically includes:
  • the deduction amount determination unit is used to determine the deduction amount of the transaction information
  • the first determining unit is used to determine whether the deduction amount is less than the payment amount threshold.
  • the payment restriction condition determination module 603 is specifically used to determine a threshold of payment times
  • the judgment module 604 specifically includes:
  • a payment times acquisition unit used to acquire the payment times of the payment code
  • a second judgment unit configured to judge whether the number of payment times is less than the threshold of the number of payment times
  • the device also includes:
  • the payment frequency plus one module is used to increase the payment frequency of the payment code by one after the deduction operation is performed according to the deduction request.
  • the payment restriction condition determination module 603 is specifically used to determine the effective time range
  • the judgment module 604 specifically includes:
  • the third judgment unit is used to judge whether the initiation time of the transaction information belongs to the valid time range.
  • the deduction operation module 605 is specifically configured to deduct the deduction amount corresponding to the transaction information from the frozen amount determined during the generation of the payment code.
  • the device further includes:
  • the frozen amount judgment module is used to return the remaining part of the frozen amount to the corresponding channel of the deduction amount when it is determined that the payment code exceeds the valid time range of the payment code after the deduction operation is performed according to the deduction request Account.
  • the embodiments of this specification also provide devices corresponding to the above methods.
  • the device 700 may include:
  • At least one processor 710 and,
  • a memory 730 in communication connection with the at least one processor; wherein,
  • the memory 730 stores instructions 720 executable by the at least one processor 710, and the instructions are executed by the at least one processor 710 to enable the at least one processor 710 to:
  • the embodiments of this specification also provide devices corresponding to the above methods.
  • FIG. 8 is a schematic structural diagram of a payment code generation device corresponding to FIG. 2 provided by an embodiment of the present specification. As shown in FIG. 8, the device 800 may include:
  • At least one processor 810 and,
  • a memory 830 communicatively connected to the at least one processor; wherein,
  • the memory 830 stores instructions 820 executable by the at least one processor 810, and the instructions are executed by the at least one processor 810 to enable the at least one processor 810 to:
  • the first terminal acquires account information; the first terminal is different from the account information binding device;
  • the embodiments of this specification also provide devices corresponding to the above methods.
  • FIG. 9 is a schematic structural diagram of a mobile payment device corresponding to FIG. 3 provided by an embodiment of the present specification. As shown in FIG. 9, the device 900 may include:
  • At least one processor 910 and,
  • a memory 930 in communication connection with the at least one processor; wherein,
  • the memory 930 stores instructions 920 executable by the at least one processor 910, and the instructions are executed by the at least one processor 910 to enable the at least one processor 910 to:
  • the improvement of a technology can be clearly distinguished from the improvement of hardware (for example, the improvement of the circuit structure of diodes, transistors, switches, etc.) or the improvement of software (the improvement of the process flow).
  • hardware for example, the improvement of the circuit structure of diodes, transistors, switches, etc.
  • software the improvement of the process flow.
  • the improvement of many methods and processes can be regarded as a direct improvement of the hardware circuit structure.
  • Designers almost 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 realized by hardware physical modules.
  • a programmable logic device (Programmable Logic Device, PLD) (such as a field programmable gate array (Field Programmable Gate Array, FPGA)) is such an integrated circuit, and its logic function is determined by the user programming the device.
  • PLD Programmable Logic Device
  • FPGA Field Programmable Gate Array
  • HDL Hardware Description Language
  • ABEL Advanced Boolean Expression
  • AHDL AlteraHardwareDescriptionLanguage
  • Confluence CUPL
  • CornellUniversityProgrammingLanguage HDCal
  • JHDL JavaHardwareDescriptionLanguage
  • Lava Lava
  • Lola MyHDL
  • PALASM RHDL
  • VHDL Very-High-Speed Integrated Circuit Hardware Description
  • the controller may be implemented in any suitable manner, for example, the controller may take a microprocessor or processor and a computer-readable medium storing computer-readable program code (such as software or firmware) executable by the (micro)processor , Logic gates, switches, application specific integrated circuits (Application Specific Integrated Circuit, ASIC), programmable logic controllers and embedded microcontrollers.
  • Examples of controllers include but are not limited to the following microcontrollers: ARC625D, Atmel AT91SAM, Microchip PIC18F26K20 and Silicon Labs C8051F320, the memory controller can also be implemented as part of the control logic of the memory.
  • controller in addition to implementing the controller in the form of pure computer-readable program code, it is entirely possible to logically program method steps to make the controller use logic gates, switches, application specific integrated circuits, programmable logic controllers and embedded The same function is realized in the form of a microcontroller or the like. Therefore, such a controller can be regarded as a hardware component, and the device for implementing various functions included therein can also be regarded as a structure within the hardware component. Or even, the means for realizing various functions can be regarded as both a software module of an implementation method and a structure within a hardware component.
  • the system, device, module or unit explained in the above embodiments may be specifically implemented by a computer chip or entity, or implemented by a product with a certain function.
  • a typical implementation device is a computer.
  • the computer may 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.
  • the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Moreover, the present application may take the form of a computer program product implemented on one or more computer usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer usable program code.
  • computer usable storage media including but not limited to disk storage, CD-ROM, optical storage, etc.
  • These computer program instructions may also be stored in a computer-readable memory that can guide a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture including an instruction device, the instructions
  • the device implements the functions specified in one block or multiple blocks of the flowchart one flow or multiple flows and/or block diagrams.
  • These computer program instructions can also be loaded onto a computer or other programmable data processing device, so that a series of operating steps are performed on the computer or other programmable device to produce computer-implemented processing, which is executed on the computer or other programmable device
  • the instructions provide steps for implementing the functions specified in one block or multiple blocks of the flowchart one flow or multiple flows and/or block diagrams.
  • the computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
  • processors CPUs
  • input/output interfaces network interfaces
  • memory volatile and non-volatile memory
  • Memory may include non-permanent memory, random access memory (RAM) and/or non-volatile memory in computer-readable media, such as read only memory (ROM) or flash memory (flash RAM). Memory is an example of computer-readable media.
  • RAM random access memory
  • ROM read only memory
  • flash RAM flash random access memory
  • Computer-readable media including permanent and non-permanent, removable and non-removable media, can store information by any method or technology.
  • the information may 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 technologies, read-only compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, Magnetic tape cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media can be used to store information that can be accessed by computing devices.
  • computer-readable media does not include temporary computer-readable media (transitory media), such as modulated data signals and carrier waves.
  • program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types.
  • the present application may also be practiced in distributed computing environments in which tasks are performed by remote processing devices connected through a communication network.
  • program modules may be located in local and remote computer storage media including storage devices.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Computer Security & Cryptography (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

一种支付码生成方法、移动支付方法、装置及设备，该支付码生成方法包括：获取第一终端发送的账户信息；所述第一终端与所述账户信息的绑定设备不同（S101）；获取所述第一终端发送的第一身份验证信息（S102）；验证所述第一身份验证信息，得到第一验证结果（S103）；当所述第一验证结果表示所述第一身份验证信息验证成功时，生成所述账户信息对应的支付码（S104）；将所述支付码发送至所述第一终端（S105）。

Description

支付码生成、移动支付方法、装置及设备 技术领域
本申请涉及计算机技术领域，尤其涉及一种支付码生成、移动支付方法、装置及设备。
背景技术
现有技术中，移动支付的迅速普及给人们生活带来了极大的便利，相较于传统的现金支付模式，移动支付显得更加安全，支付的过程也更快，携带上也更具有便利性。但是移动支付也同时伴随着一个问题：对移动终端的依赖。在用户忘记携带手机，或者手机电量耗尽的场景下，用户将无法选择手机完成支付。这在很大程度上会导致用户出门仍然需要携带部分现金在身上，以备不时之需。
发明内容
有鉴于此，本申请实施例提供了一种支付码生成、移动支付方法、装置及设备，用于提高移动支付的便利性。
为解决上述技术问题，本说明书实施例是这样实现的：
本说明书实施例提供的一种支付码生成方法，包括：
获取第一终端发送的账户信息，所述第一终端与所述账户信息的绑定设备不同；
获取所述第一终端发送的第一身份验证信息；
验证所述第一身份验证信息，得到第一验证结果；
当所述第一验证结果表示所述第一身份验证信息验证成功时，生成所述账户信息对应的支付码；
将所述支付码发送至所述第一终端。
本说明书实施例提供的一种移动支付方法，包括：
获取针对所述支付码的扣款请求；
确定所述扣款请求对应的交易信息；
确定所述支付码的支付限制条件；
判断所述交易信息是否满足所述支付限制条件；
若是，根据所述扣款请求进行扣款操作。
本说明书实施例提供的一种支付码生成方法，包括：
第一终端获取账户信息，所述第一终端与所述账户信息的绑定设备不同；
获取第一身份验证信息；
将所述账户信息和所述第一身份验证信息发送至服务器；
当所述服务器确定所述第一身份验证信息验证成功时，接收所述服务器发送的所述账户信息的支付码；
打印所述支付码。
本说明书实施例提供的一种支付码生成装置，包括：
账户信息获取模块，用于获取第一终端发送的账户信息；所述第一终端与所述账户信息的绑定设备不同；
第一身份验证信息获取模块，用于获取所述第一终端发送的第一身份验证信息；
第一验证模块，用于验证所述第一身份验证信息，得到第一验证结果；
支付码生成模块，用于当所述第一验证结果表示所述第一身份验证信息验证成功时，生成所述账户信息对应的支付码；
支付码发送模块，用于将所述支付码发送至所述第一终端。
本说明书实施例提供的一种移动支付装置，包括：
扣款请求获取模块，用于获取针对所述支付码的扣款请求；
交易信息确定模块，用于确定所述扣款请求对应的交易信息；
支付限制条件确定模块，用于确定所述支付码的支付限制条件；
判断模块，用于判断所述交易信息是否满足所述支付限制条件；
扣款操作模块，用于所述交易信息满足所述支付限制条件时，根据所述扣款请求进行扣款操作。
本说明书实施例提供的一种支付码生成装置，包括：
账户信息获取模块，用于第一终端获取账户信息，所述第一终端与所述账户信息的绑定设备不同；
第一身份验证信息获取模块，用于获取第一身份验证信息；
第一发送模块，用于将所述账户信息和所述第一身份验证信息发送至服务器；
第一接收模块，用于当所述服务器确定所述第一身份验证信息验证成功时，接收所述服务器发送的所述账户信息的支付码；
支付码打印模块，用于打印所述支付码。
本说明书实施例提供的一种支付码生成设备，包括：
至少一个处理器；以及，
与所述至少一个处理器通信连接的存储器；其中，
所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够：
获取第一终端发送的账户信息，所述第一终端与所述账户信息的绑定设备不同；
获取所述第一终端发送的第一身份验证信息；
验证所述第一身份验证信息，得到第一验证结果；
当所述第一验证结果表示所述第一身份验证信息验证成功时，生成所述账户信息对应的支付码；
将所述支付码发送至所述第一终端。
本说明书实施例提供的一种支付码生成设备，包括：
至少一个处理器；以及，
与所述至少一个处理器通信连接的存储器；其中，
所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够：
第一终端获取账户信息，所述第一终端与所述账户信息的绑定设备不同；
获取第一身份验证信息；
将所述账户信息和所述第一身份验证信息发送至服务器；
当所述服务器确定所述第一身份验证信息验证成功时，接收所述服务器发送的所述账户信息的支付码；
打印所述支付码。
本说明书实施例提供的一种移动支付设备，包括：
至少一个处理器；以及，
与所述至少一个处理器通信连接的存储器；其中，
所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够：
获取针对所述支付码的扣款请求；
确定所述扣款请求对应的交易信息；
确定所述支付码的支付限制条件；
判断所述交易信息是否满足所述支付限制条件；
若是，根据所述扣款请求进行扣款操作。
本说明书实施例采用的上述至少一个技术方案能够达到以下有益效果：
通过对用户在非账户绑定设备的终端上输入的账户和身份信息进行验证，生成账户的授权支付码，用来解决用户的手机不在身边或者无法使用时的移动支付问题，提高了移动支付的便利性。
附图说明
此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：
图1为本说明书实施例1提供的一种支付码生成方法的流程示意图；
图2为本说明书实施例2提供的一种支付码生成方法的流程示意图；
图3为本说明书实施例3提供的一种移动支付方法的流程示意图；
图4为本说明书实施例提供的对应于图1的一种支付码生成装置的结构示意图；
图5为本说明书实施例提供的对应于图2的一种支付码生成装置的结构示意图；
图6为本说明书实施例提供的对应于图3的一种移动支付装置的结构示意图；
图7为本说明书实施例提供的对应于图1的一种支付码生成设备的结构示意图；
图8为本说明书实施例提供的对应于图2的一种支付码生成设备的结构示意图；
图9为本说明书实施例提供的对应于图3的一种移动支付设备的结构示意图。
具体实施方式
为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
以下结合附图，详细说明本申请各实施例提供的技术方案。
图1为本说明书实施例1提供的一种支付码生成方法的流程示意图。从程序角度而言，流程的执行主体可以为搭载于应用服务器的程序或应用客户端。
如图1所示，该流程可以包括以下步骤：
S101：获取第一终端发送的账户信息，所述第一终端与所述账户信息的绑定设备不同。
在本说明书实施例中，第一终端设备可以是由服务提供商在商场、餐馆、车站等位置布置的计算机，也可以是其他人拥有的移动智能终端、平板电脑、笔记本电脑等。当用户不能使用自己的手机(即账户信息的绑定设备)进行移动支付时，可以在第一终端设备上登录，例如输入自己的用户名、账户绑定的手机号码、邮箱等等，然后服务器获取第一终端发送的账户信息。
在获取账户信息时，账户信息可以包括账户的标识以及账户信息的发送设备，服务器首先需要判断所述发送设备与所述账户信息的绑定设备是否相同，因为本说明书实施例提供的方法就是为了解决用户的手机不在身边或者无法使用时的移动支付问题，所以只有在不相同时，才是本说明书实施例限定的方法。
在本说明书实施例中，所述的“第一”和“第二”只是为了区分用户，防止概念混淆，并不具有实际意义。
S102：获取所述第一终端发送的第一身份验证信息。
为了对账户信息进行验证，服务器还需要获取账户对应的身份验证信息，可以是密码登录信息，也可以是生物特征信息，例如指纹特征或者面部特征。
S103：验证所述第一身份验证信息，得到第一验证结果。
服务器在收到第一身份验证信息后，会将该验证信息与用户在注册时保存的注册信息进行比对，如果二者匹配，可以判定验证通过，否则验证不通过。
在进行验证时，服务器还可以采用风控措施，例如发现用户登录的设备发生了变化，可以结合用户名、密码验证和生物特征验证，例如先比对用户名和密码，通过后再比对生物特征，二者均验证通过才认定验证通过。当然，也可以采用其他的风控措施，例如用户输入用户名、密码错误次数达到上限，则锁定用户的账户。具体的风控措施，可以根据具体的应用需要来设置。
S104：当所述第一验证结果表示所述第一身份验证信息验证成功时，生成所述账户信息对应的支付码。
验证成功之后，服务器会根据账户的基本信息以及用户的支付习惯信息，生成所述账户的支付码，所述支付码还可以授权信息，所述授权信息可以包括支付金额上限，支付次数上限以及生效时间范围等。在本说明书实施例中，所述基本信息包括：用户名；所述用户的支付习惯信息包括：使用频率、累计支付金额、单次支付的平均金额和账户的历史日均支付额度。
另外，服务器还可以通过提供的授权页面让用户选择或者输入自己的授权信息；一般来说，授权信息可以包括支付码的生效时间。服务器根据用户输入的授权信息以及账户自身的信息共同确定用于线下支付的支付码的限制条件。如果，用户输入的授权信息与账户的自身信息不相符时，还可以进行二次身份验证或者其它风控措施。比如，服务器还可以随机生成一个6位数字密码，对应于此次生成的支付码。在每次采用该支付码进行支付的时候都需要用户输入6位数字密码，只有成功输入，才可以成功支付。通常情况下，6位数字密码也可以由用户本人预留。
S105：将所述支付码发送至所述第一终端。
服务器将具有账户的授权信息的支付码发送至第一终端，第一终端可以根据条码的编码规则，将所述支付码显示为条形码和/或二维码，用于线下支付，或者其它操作，比如添加好友或群组等。在本说明书实施例中，所述支付码可以包括用户账户的标识，比如账户名。
可选的，在第一终端支持打印功能的情况下，还可以将支付码打印出来以平面印刷品的方式进行线下支付，可以通过截屏后者拍照的方式进行支付码的传递，以实现在其他终端设备(与账户信息的绑定设备不同)上进行移动支付的功能。
图1中的方法，通过对用户在非账户绑定设备的终端上输入的账户和身份信息进行验证，生成账户的授权支付码，用来解决用户的手机不在身边或者无法使用时的移动支付问题，提高了移动支付的便利性。
基于图1的方法，本说明书实施例还提供了该方法的一些具体实施方式，下面进行说明。
在本说明书的实施例中，在所述生成所述账户信息的支付码之前，还包括：
确定支付限制条件，所述支付限制条件用于约束所述支付码的线下支付。
在本说明书实施例中，为了增加支付码线下支付的安全性，可以增加支付限制条件对支付码的线下支付进行限制，可以限制支付码的生效时间、还有支付金额等等。当然，这些支付限制条件可以根据用户的操作习惯生成，也可以根据用户在第一终端的授权页面上填写的信息生成，还可以综合以上两种情况共同生成。
可选的，所述确定支付限制条件，具体包括：
确定支付额度阈值；
和/或，确定支付次数阈值；
和/或，确定有效时间范围；
其中，所述支付额度阈值用于限定所述支付码的支付金额上限，所述支付次数阈值用于限定所述支付码在有效时间范围内的支付次数，所述支付码在所述有效时间范围内有效。
在本说明书实施例中，支付额度限制可以是单次支付额度阈值上限，也可以是支付总额度上限。例如，当用户出去逛街时，会买一些小东西，金额比较小，但是会买多个，那么可以设置支付总额为200元，而不对单次支付金额进行限制。当用户在确定自己要买的东西时，往往只需要支付一次就可以，那么支付额度限制可以支付总额度上限，比如500元、1000元。
在本说明书实施例中，支付次数阈值可以根据用户的实际场景进行设置，可以是一次，也可以是多次，可以与支付额度阈值有关系。
在本说明书实施例中，支付码的时间范围可以根据用户的实际情况进行确定，为了安全性的考虑，可以是3个小时，5个小时，一般在24小时之内，当然也可以为2天，或者更长的时间。
在本说明书实施例中，支付额度阈值、支付次数阈值和有效时间范围，可以单独设置一个，也可以同时设置多个。为了增强安全性，还可以有其他的支付限制条件，比如支付生效范围(可以限定在某个城市或者地区)，或者支付生效类别(可以是服饰、超市、交通、餐饮等等)。
本说明书实施例提供的方法还可以用于以下场景，比如，可以将给孩子的零花钱替换为上述方法提供的支付码，限定每次支付的最大金额，以及支付的次数，从而避免了孩子丢失钱造成的损失，或者没有零钱给孩子造成的麻烦。
可选的，所述确定支付额度阈值，具体包括：
获取所述第一终端发送的第一支付额度阈值；
根据所述账号信息确定第二支付额度阈值；
判断所述第一支付额度阈值是否小于所述第二支付额度阈值；
若是，确定所述第一支付额度阈值为所述支付额度阈值。
在本说明书实施例中，往往是根据账户的基本信息确定，但是在实际的应用场景中，常常会出现一种情况，用户往往需要进行一次大金额的支付，比如购买金银首饰，需要1500元。为了完成这次支付，用户输入的支付额度限制往往比自己平时使用账户支付的金额要多，在这种情况下，用户需要授权支付的金额就会多于账户生成的支付额度限制(比如500元)，此时，如果仍然将根据所述账号信息确定第二支付额度阈值(500元)作为支付额度限制的话，用户将无法使用支付码完成大金额的付款请求(1500元的金银首饰)。因此，需要将用户如用户输入的第一支付额度阈值作为支付额度限制的话。
可选的，在判断所述第一支付额度阈值是否小于所述第二支付额度阈值之后，还包括：
若否，获取所述第一终端发送的第二身份验证信息；
验证所述第二身份验证信息，得到第二验证结果；
当所述第二验证结果表示所述第二身份验证信息验证成功时，确定所述第一支付额度阈值为所述支付额度阈值。
在实际应用场景中，由于用户输入的第一支付额度阈值大于根据账户信息生成的第二支付阈值(预设支付阈值)，如果将第一支付额度阈值作为支付额度阈值的话，那么支付码的安全系数将会降低，为了避免这一情况，需要进行了二次身份验证，并根据二次验证结果确定支付额度阈值。
第二身份验证信息主要是为了进一步验证是否是账户的用户本人在进行授权操作，通常，第二身份验证信息可以比第一身份验证信息更加细致或者严格，可以采取人脸面部信息或者掌纹信息，还可以输入账户进行实名认证的证件号码，进一步的，还可以提供几种消费条目，让用户确认哪一种或者哪几种是由该账户产生的。如果，第二身份验证信息验证成功，则可以授予支付码比较大的支付金额权限，即用户请求的第一支付额度阈值。当第二身份验证信息验证失败时，则拒绝进行授权服务。
可选的，在所述确定支付限制条件之后，所述方法还包括：
根据所述支付限制条件确定预扣款，所述预扣款用于所述支付码的线下支付；
确定扣款渠道；
根据所述扣款渠道从指定账户中冻结所述预扣款对应的金额。
在本说明书实施例中，为了支付码的线下支付能够顺利完成，需要预先确定支付金额的扣款渠道，即从什么账户扣多少钱进行支付，即需要提前确定预扣款。账户的扣款渠道类似于支付渠道，服务器可以采用账户默认的支付渠道进行扣款，也可以根据用户选择的支付模式进行扣款，如余额、余额宝、蚂蚁花呗、银行卡等。
如果账户默认或者用户选择的支付渠道对应的账户余额为600元，大于预扣款的金额(500元)，那么直接从相应的账户中冻结500元就可以，如果账户余额为200元，小于500元，则需要从其他的账户进行金额的冻结，可以是第二个默认的账户，也可以让用户再次选择，直到对应的账户有足够的余额进行冻结预扣款的金额为止。
如果扣款渠道是内部支付工具，比如余额、余额宝，则会从用户账户内部对额度进行冻结，冻结的金额将只能支付所述支付码发起的扣款请求，不再作为它用。
可选的，所述根据所述扣款渠道从指定账户中扣除所述预扣款对应的金额，具体包括：
判断所述扣款渠道是否为第三方支付渠道；
若是，调用所述扣款渠道对应的第三方支付工具；
确定所述扣款渠道对应的付款账户；
利用所述第三方支付工具从所述付款账户中冻结所述预扣款对应的金额。
当服务器判断扣款渠道为第三方支付渠道时，需要调用第三方支付工具，如银行系统的程序、或者其它APP的程序。然后从利用第三方支付工具从付款账户中冻结预扣款对应的金额，冻结的金额将只能支付所述支付码发起的扣款请求，不再作为它用。
可选的，所述根据所述支付限制条件确定预扣款，具体包括：
将所述支付额度阈值和所述支付次数阈值的乘积确定为所述预扣款的金额，其中，所述支付额度阈值为单次支付额度阈值。
在本说明书实施例中，预扣款的金额就是总支付额度阈值，如果支付额度阈值是单次支付额度阈值，那么总支付额度阈值就需要支付额度阈值与支付次数阈值共同决定，即预扣款的金额的确定可以根据单次支付阈值与支付次数阈值的乘积进行确定，如单次支付阈值为100元，支付次数阈值为3次，那么预扣款的金额＝100×3＝300元。
可选的，所述根据所述支付限制条件确定预扣款，具体包括：
将所述支付额度阈值确定为所述预扣款的金额，其中，所述支付额度阈值为总支付额度阈值。
如果获得的支付额度阈值就是总支付额度阈值，那么预扣款的金额就是支付额度阈值，例如支付额度阈值为500元，那么不管支付多少次，多次支付的金额都不超过500元，那么预扣款的金额就是500元。
上述实施例是从服务器的角度阐释了本说明书的支付码生成方法，本说明书实施例还从第一终端的角度对本说明书的支付码生成方法进行了阐述。
图2为本说明书实施例2提供的一种支付码生成方法的流程示意图。从程序角度而言，流程的执行主体是第一终端。
如图2所示，该流程可以包括以下步骤：
S201：第一终端获取账户信息；所述第一终端与所述账户信息的绑定设备不同。
在本说明书实施例中，第一终端可以是由服务提供商在商场、餐馆、车站等位置布置的计算机，也可以是其他人拥有的移动智能终端、平板电脑、笔记本电脑等。当用户不能使用自己的手机(即账户信息的绑定设备)进行移动支付时，可以在第一终端设备上登录，例如输入自己的用户名、账户绑定的手机号码、邮箱等等。
第一终端呈现给用户可以是一个授权界面中登录界面，可以理解为此处的登录界面与正常状态下用户在账户信息的绑定设备上的登录界面时不同的。如果第一终端是服务提供商在商场、餐馆、车站等位置布置的计算机，是一种只具备特定功能的设备终端，与账户信息的绑定设备(移动智能终端、平板电脑或笔记本电脑)不同，即只能用来做线下支付的授权服务，不具备移动支付终端的其他功能，那么其登录界面只有一个，而这个登录界面可以做成与用户在账户信息的绑定设备上的登录界面不同的。如果第一终端时是他人拥有的移动智能终端、平板电脑、笔记本电脑等，与账户的信息的绑定设备相同，那么可以单独做一个授权界面，在进行登录时选择只具备授权功能的登录界面。
S202：获取第一身份验证信息。
在第一终端的授权界面的登录界面中获取第一身份验证信息，可以是密码登录信息，也可以是生物特征信息，例如指纹特征或者面部特征，还可以结合用户名、密码和生物特征多重验证，提高安全性。例如先比对用户名、密码，通过后再比对生物特征。
S203：将所述账户信息和所述第一身份验证信息发送至服务器。
在本说明书实施例中，账户信息和第一身份验证信息可以同时发给服务器，也可以是不同时的，即先发送账户信息，后发送第一身份验证信息。而且，第一身份验证信息可以一条也可以是两条，可以分先后顺序，也可以不分先后顺序。例如，第一身份验证信息包括账户密码和生物特征，第一终端可以同时将获取的账户密码和生物特征发送至服务器进行验证；也可以先将账户密码发送至服务器进行一次验证，然后再将生物特征发送至服务器进行二次验证。
S204：当所述服务器确定所述第一身份验证信息验证成功时，接收所述服务器发送的所述账户信息的支付码。
在本说明书实施例中，当服务器确定第一身份验证信息验证成功后，第一终端会接收一个携带有授权信息的支付码用于线下支付。支付码可以是二维码或者条形码，所述支付码包含用户的标识。
S205：打印所述支付码。
在本说明书实施例中，第一终端可以是自带打印功能的设备终端，可以直接将支付码进行打印；也可以通过与打印机进行无线或者无线连接，然后再进行打印。
在利用上述支付码进行支付时，还可以进行身份验证，比如在线下支付时，需要提供账户的支付密码或者绑定的手机号码，或者用户的生物特征信息，等等，只有通过 了验证，支付才能成功。
本说明书实施例中，将支付码打印出来，方便携带。用户可以抛开手机等电子设备，更加便捷的享受或使用支付码所带来的好处。对于货币电子化的普及具有更进一步的推动作用。
基于图2的方法，本说明书实施例还提供了该方法的一些具体实施方式，下面进行说明。
在本说明书实施例中，为了提高支付码的安全性，需要对支付码的支付环境或者支付条件进行限制。
可选的，在接收所述服务器发送的所述账户信息的支付码之前，还包括：获取用户输入的支付限制条件，所述支付限制条件用于约束所述支付码的线下支付。
在实际应用场景中，可以增加支付限制条件对支付码的线下支付进行限制，可以限制支付码的生效时间、还有支付金额等等。在服务器确定第一身份验证信息验证成功后，或返回第一终端一个支付限制条件的界面呈现给用户，用户可以根据自己的实际情况，在该界面上选择相应的勾选或者输入，第一终端获取用户输入的信息后，返回给服务器。
可选的，所述获取用户输入的支付限制条件，具体包括：
获取支付额度阈值；
和/或，获取支付次数阈值；
和/或，获取有效时间范围；
其中，所述支付额度阈值用于限定所述支付码的支付金额上限，所述支付次数阈值用于限定所述支付码在有效时间范围内的支付次数，所述支付码在所述有效时间范围内有效。
在本说明书实施例中，第一终端可以呈现多种限制条件给用户，比如，支付额度阈值，支付次数阈值和有效时间范围。用户可以根据需要选择相应的类别。用户的选择可以是其中的一种，也可以是多种。
在具体的应用场景中，支付额度阈值包括两种，一种是单次支付额度阈值，另一种是总支付额度阈值，如果用户需要支付的是多个小金额的物品，那么可以选择单次支付额度阈值为50元，支付次数阈值为10个，如果用户需要支付的一个大金额的物品， 那么可以选择总支付额度阈值为500元，支付次数阈值为1次。
有效时间范围对于支付码来说至关重要，如果不对支付码的有效时间范围进行限制的话，那么支付码将长期有效。当用户不小心将支付码丢掉的话，任何捡到该支付码的人都可以采用该支付码进行支付。为了防止这种问题的出现，本说明书实施例中，对有效时间范围进行限定，可以是2个小时，3个小时，8个小时，通常不大于24个小时。当然也不排除有另外的情况，比如7天。
在具体的应用场景中，还可以对支付码的有效地区进行限定，比如，仅仅限定于某个城市，如北京、杭州和广州，也可以对支付码的支付领域进行限定，比如，仅仅限定于买衣服，超市或者火车站等。
可选的，在所述获取用户输入的支付限制条件之后，还包括：
获取用户输入的扣款渠道，所述扣款渠道表示所述支付码用于支付的金额的扣款渠道；
将所述扣款渠道发送至服务器。
在本说明书实施例中，对支付码的支付限制条件进行获取后，还需要获取支付码的扣款渠道，即确定支付码用于支付的金额的来源。扣款渠道可以是服务器将账户信息中的扣款方式呈现给第一终端，供客户进行选择。扣款渠道可以是内部支付工具，如余额、零钱包等，也可以是外部支付工具，即需要服务器调用第三方支付工具，如银行卡，需要调用相应的银行系统进行扣款操作。
可选的，所述获取支付额度阈值，具体包括：
获取第一支付额度信息；
在所述获取支付额度阈值之后，还包括：
接收到所述服务器返回的安全验证指令；所述安全验证指令是所述服务器确定所述第一支付额度信息大于所述账户的预设支付额度后生成的；
显示验证信息输入界面；
获取基于所述验证信息输入界面输入的第二身份验证信息；
将所述第二身份验证信息发送至所述服务器。
在本说明书实施例中，对于支付额度阈值的确定，可以根据用户的账户信息和用 户的输入信息共同决定。如果用户想要获得的第一支付额度阈值大于根据账户信息生成的预设支付额度时，则需要对用户的身份进行进一步确定，可以获取第二身份验证信息。第二身份验证信息主要是为了进一步验证是否是账户的用户本人在进行授权操作，通常，第二身份验证信息可以比第一身份验证信息更加细致或者严格，可以采取人脸面部信息或者掌纹信息，还可以输入账户进行实名认证的证件号码，进一步的，还可以提供几种消费条目，让用户确认哪一种或者哪几种是由该账户产生的。如果，第二身份验证信息验证成功，则可以授予支付码比较大的支付金额权限，即用户请求的第一支付额度阈值。
本说明书实施例针对上述方法生成的支付码，还提供了一种支付码的移动支付方法。
图3为本说明书实施例3提供的一种支付码的移动支付方法的流程示意图。从程序角度而言，流程的执行主体可以为搭载于应用服务器的程序或应用客户端。
如图3所示，该流程可以包括以下步骤：
S301：获取针对所述支付码的扣款请求。
在本说明书实施例中，支付码的使用方法与其他在移动终端呈现的动态支付码是一样的，当采用支付码进行付款时，采用请求支付端对所述支付码进行扫描，生成扣款请求，所述扣款请求可以包括扣款请求的发起端，扫描的支付码信息、扣款金额。请求支付端可以为扫描枪，也可以是固定的扫描设备。
S302：确定所述扣款请求对应的交易信息。
在本说明书实施例中，扣款请求包含很多信息，服务器获取扣款请求之后，只需要对其中一些重要信息进行提取，比如：扣款请求的发起端，扣款请求的发起时间，付款账号、扣款金额等等。一个扣款请求的交易信息可以表示为：“餐饮××麻辣烫××美食城46元”。
S303：确定所述支付码的支付限制条件。
在本说明书实施例中，由于采用此支付码进行支付的情况与该支付码对应的账户信息的绑定设备进行支付的情况不同，服务器根据扣款请求调取所述支付码对应的付款程序，确定所述支付码的支付限制条件。此处的支付限制条件是服务器早就已经存储的，直接调用即可。
在实际应用场景中，由于支付限制条件是提前预设的，通常，需要确定的扣款请 求的交易信息往往与支付限制条件有关。比如，支付限制条件里面包括有效时间范围，那么，交易信息就需要包括扣款请求的发起时间，即“餐饮××麻辣烫××美食城46元2018年12月12日14时35分”
S304：判断所述交易信息是否满足所述支付限制条件。
在本说明书实施例中，判断扣款请求对应的交易信息是否满足支付码的支付限制条件，需要一一对所述支付限制条件进行判断，只有全部条件都符合，才表明交易信息满足支付码的支付限制条件。
S305：若是，根据所述扣款请求进行扣款操作。
当交易条件满足全部支付限制时，则可以确定是支付码对应的账户的本人在进行线下交易，在确认无误后，则可以完成所述扣款请求。通常，为了安全，还可以进行风险控制，即在确认交易条件满足全部支付限制时，仍然需要用户输入支付码对应账号绑定的手机号码，如果扣款渠道是银行卡，还可以要求用户输入银行卡的密码。
基于图3的方法，本说明书实施例还提供了该方法的一些具体实施方式，下面进行说明。
可选的，所述支付限制条件包括支付金额阈值，
判断所述交易信息是否满足所述支付限制条件，具体包括：
确定所述交易信息的扣款金额；
判断所述扣款金额是否小于所述支付金额阈值。
在本说明书实施例中，支付限制条件对支付金额阈值进行了限制，那么就需要判断交易信息的扣款金额是否符合支付金额阈值。如果限制的是单次支付额度阈值，如果扣款金额小于单次支付额度阈值，则说明交易信息满足支付限制条件。假设单次支付额度阈值设置为50元，扣款请求为“餐饮××麻辣烫××美食城46元2018年12月12日14时35分”的交易信息为46元，那么交易信息则满足支付限制条件。如果单次支付额度阈值设置为40元，那么交易信息就不满足支付限制条件。
如果限制的是总支付额度阈值，扣款金额的总额不能超过总支付额度阈值，则说明交易信息满足支付限制条件。假设总支付额度阈值设置为500元，针对“餐饮××麻辣烫××美食城46元2018年12月12日14时35分”的扣款请求，扣款金额为46，获取支付码已经支付的金额为412元，那么当前扣款金额的交易信息为458元，小于500 元，那么交易信息则满足支付限制条件。
可选的，所述支付限制条件包括有效时间范围，
判断所述交易信息是否满足支付限制条件，具体包括：
判断所述交易信息的发起时间是否属于所述有效时间范围。
在本说明书实施例中，支付限制条件对有效时间范围进行了限制，那么就需要判断交易信息的发起时间是否符合有效时间范围。假设设置的有限时间范围为2018年12月12日12时至2018年12月12日18时，扣款请求为“餐饮××麻辣烫××美食城46元2018年12月12日14时35分”的交易信息为发起时间2018年12月12日14时35分，2018年12月12日14时35分在2018年12月12日12时至2018年12月12日18时的范围之内，那么交易信息则满足支付限制条件。
可选的，所述支付限制条件包括支付次数阈值，
判断所述交易信息是否满足所述支付限制条件，具体包括：
获取所述支付码的支付次数；
判断所述支付次数是否小于所述支付次数阈值；
在所述根据所述扣款请求进行扣款操作之后，还包括：
对所述支付码的支付次数加一。
在本说明书实施例中，支付限制条件对支付次数进行了限制，而支付次数是在支付码端形成的，在支付开始时，支付次数为零，当支付码完成一次扣款请求之后，对所述支付次数加一。当判断当前扣款请求的支付次数是否满足支付次数阈值时，首先要获得已经采用支付码支付扣款请求的次数。假设支付次数阈值设置为5次，如果当前的支付次数为5次，那么当前扣款请求的交易次数为5次，不符合支付次数阈值限定的支付限制条件。
本说明书实施例中，支付限制条件可以是一种，也可以多种。例如，支付限制条件可以设置为：单次支付额度阈值为100元，支付次数阈值为3次，有效时间范围为2018年12月15日，获取的扣款请求为“服饰××短袖××广场186元2018年12月16日10时12分”，支付码的支付次数为1次，那么其相应的交易信息为：160元，1次，2018年12月16日10时12分，经过判断，可以得出，支付次数满足支付次数阈值，扣款请求的发起时间也在支付码的有效时间范围内，但是扣款金额不满足单次支付额度阈 值，则可以认定交易信息不满足支付限制条件，因此，当前扣款请求不能完成。
在本说明书实施例中，支付限制条件不仅仅限制于本说明书实施例中列举的集中，还可以包括：总支付额度阈值，地区限制和支付领域限制。地区限制可以限定于某个城市，如北京、杭州和广州，支付领域限制可以限定于买衣服，超市或者火车站等。
可选的，所述根据所述扣款请求进行扣款操作，具体包括：
从所述支付码的生成过程中确定的冻结金额中扣除所述交易信息对应的扣款金额。
在本说明书实施例中，在进行扣款请求时，就是要扣除扣款请求对应的金额。支付码的支付金额提前预留好，是从一个支付账户(如余额、银行卡)内冻结的金额。当要完成扣款，就是从冻结的金额中扣除相应的金额就可以，同时需要更新冻结金额，以确定剩余金额。
可选的，在所述根据所述扣款请求进行扣款操作之后，还包括：
当确定超过所述支付码的有效时间范围时，将所述冻结金额中的剩余部分返回扣款渠道对应的账户。
在本说明书实施例中，当超过支付码的有效时间范围时，就说明支付码已经失效了，利用支付码付款的交易将不能再完成，此时冻结金额也就不再有用，服务器会自动判断冻结金额是否为零，如果不是零，则将冻结金额返回扣款渠道对应的账户。
基于同样的思路，本说明书实施例还提供了上述方法对应的装置。图4为本说明书实施例提供的对应于图1的一种支付码生成装置的结构示意图。如图4所示，该装置可以包括：
账户信息获取模块401，用于获取第一终端发送的账户信息，所述第一终端与所述账户信息的绑定设备不同；
第一身份验证信息获取模块402，用于获取所述第一终端发送的第一身份验证信息；
第一验证模块403，用于验证所述第一身份验证信息，得到第一验证结果；
支付码生成模块404，用于当所述第一验证结果表示所述第一身份验证信息验证成功时，生成所述账户信息对应的支付码；
支付码发送模块405，用于将所述支付码发送至所述第一终端。
可选的，所述装置还包括：
支付条件确定模块，用于在所述生成所述账户信息的支付码之前，确定支付限制条件，所述支付限制条件用于约束所述支付码的线下支付。
可选的，所述支付条件确定模块，具体包括：
支付额度阈值确定单元，用于确定支付额度阈值；
支付次数阈值确定单元，用于确定支付次数阈值；
有效时间范围确定单元，用于确定有效时间范围；
其中，所述支付额度阈值用于限定所述支付码的支付金额上限，所述支付次数阈值用于限定所述支付码在有效时间范围内的支付次数，所述支付码在所述有效时间范围内有效。
可选的，所述支付额度阈值确定单元，具体包括：
第一支付额度阈值获取子单元，用于获取所述第一终端发送的第一支付额度阈值；
第二支付额度阈值确定子单元，用于根据所述账号信息确定第二支付额度阈值；
判断子单元，用于判断所述第一支付额度阈值是否小于所述第二支付额度阈值；
第一支付额度阈值确定子单元，用于所述第一支付额度阈值小于所述第二支付额度阈值时，确定所述第一支付额度阈值为所述支付额度阈值。
可选的，所述支付额度阈值确定单元，还包括：
第二身份验证信息获取子单元，用于所述第一支付额度阈值大于或等于所述第二支付额度阈值时，获取所述第一终端发送的第二身份验证信息；
第二验证子单元，用于验证所述第二身份验证信息，得到第二验证结果；
第二支付额度阈值确定子单元，用于当所述第二验证结果表示所述第二身份验证信息验证成功时，确定所述第一支付额度阈值为所述支付额度阈值。
可选的，所述第一身份验证信息获取模块402，具体用于获取密码登录信息或生物特征信息。
可选的，所述装置还包括：
预扣款确定模块，用于在所述确定支付限制条件之后，根据所述支付限制条件确定预扣款，所述预扣款用于所述支付码的线下支付；
扣款渠道确定模块，用于确定扣款渠道；
金额冻结模块，用于根据所述扣款渠道从指定账户中冻结所述预扣款对应的金额。
可选的，所述金额冻结模块，具体包括：
判断单元，用于判断所述扣款渠道是否为第三方支付渠道；
第三方支付工具调用单元，用于当所述扣款渠道是第三方支付渠道时，调用所述扣款渠道对应的第三方支付工具；
付款账户确定单元，用于确定所述扣款渠道对应的付款账户；
金额冻结单元，用于利用所述第三方支付工具从所述付款账户中冻结所述预扣款对应的金额。
可选的，所述预扣款确定模块，具体用于将所述支付额度阈值和所述支付次数阈值的乘积确定为所述预扣款的金额，其中，所述支付额度阈值为单次支付额度阈值。
可选的，所述预扣款确定模块，具体用于将所述支付额度阈值确定为所述预扣款的金额，其中，所述支付额度阈值为总支付额度阈值。
基于同样的思路，本说明书实施例还提供了上述方法对应的装置。图5为本说明书实施例提供的对应于图2的一种支付码生成装置的结构示意图。如图5所示，该装置可以包括：
账户信息获取模块501，用于第一终端获取账户信息；所述第一终端与所述账户信息的绑定设备不同；
第一身份验证信息获取模块502，用于获取第一身份验证信息；
第一发送模块503，用于将所述账户信息和所述第一身份验证信息发送至服务器；
第一接收模块504，用于当所述服务器确定所述第一身份验证信息验证成功时，接收所述服务器发送的所述账户信息的支付码；
支付码打印模块505，用于打印所述支付码。
可选的，所述装置还包括：
支付限制条件获取模块，用于在所述接收所述服务器发送的所述账户信息的支付码之前，获取用户输入的支付限制条件，所述支付限制条件用于约束所述支付码的线下支付。
可选的，所述支付限制条件获取模块，具体包括：
支付额度阈值获取单元，用于获取支付额度阈值；
支付次数阈值获取单元，用于获取支付次数阈值；
有效时间范围获取单元，用于获取有效时间范围；
其中，所述支付额度阈值用于限定所述支付码的支付金额上限，所述支付次数阈值用于限定所述支付码在有效时间范围内的支付次数，所述支付码在所述有效时间范围内有效。
可选的，所述装置还包括：
扣款渠道获取模块，用于在所述获取用户输入的支付限制条件之后，获取用户输入的扣款渠道，所述扣款渠道表示所述支付码用于支付的金额的扣款渠道；
扣款渠道发送模块，用于将所述扣款渠道发送至服务器。
可选的，所述第一身份验证信息获取模块502，具体用于获取密码登录信息或生物特征信息。
可选的，所述支付额度阈值获取单元，具体包括：
第一支付额度信息获取子单元，用于获取第一支付额度信息；
所述装置，还包括：
安全验证指令接收模块，用于接收到所述服务器返回的安全验证指令；所述安全验证指令是所述服务器确定所述第一支付额度信息大于所述账户的预设支付额度后生成的；
显示模块，用于显示验证信息输入界面；
第二身份验证信息获取模块，用于获取基于所述验证信息输入界面输入的第二身份验证信息；
第二发送模块，用于将所述第二身份验证信息发送至所述服务器。
基于同样的思路，本说明书实施例还提供了上述方法对应的装置。图6为本说明书实施例提供的对应于图3的一种移动支付装置的结构示意图。如图6所示，该装置可以包括：
扣款请求获取模块601，用于获取针对所述支付码的扣款请求；
交易信息确定模块602，用于确定所述扣款请求对应的交易信息；
支付限制条件确定模块603，用于确定所述支付码的支付限制条件；
判断模块604，用于判断所述交易信息是否满足所述支付限制条件；
扣款操作模块605，用于所述交易信息满足所述支付限制条件时，根据所述扣款请求进行扣款操作。
可选的，所述支付限制条件确定模块603，具体用于确定支付金额阈值；
所述判断模块604，具体包括：
扣款金额确定单元，用于确定所述交易信息的扣款金额；
第一判断单元，用于判断所述扣款金额是否小于所述支付金额阈值。
可选的，所述支付限制条件确定模块603，具体用于确定支付次数阈值，
所述判断模块604，具体包括：
支付次数获取单元，用于获取所述支付码的支付次数；
第二判断单元，用于判断所述支付次数是否小于所述支付次数阈值；
所述装置，还包括：
支付次数加一模块，用于在所述根据所述扣款请求进行扣款操作之后，对所述支付码的支付次数加一。
可选的，所述支付限制条件确定模块603，具体用于确定有效时间范围，
所述判断模块604，具体包括：
第三判断单元，用于判断所述交易信息的发起时间是否属于所述有效时间范围。
可选的，所述扣款操作模块605，具体用于从所述支付码的生成过程中确定的冻结金额中扣除所述交易信息对应的扣款金额。
可选的，所述装置，还包括：
冻结金额判断模块，用于在所述根据所述扣款请求进行扣款操作之后，当确定超过所述支付码的有效时间范围时，将所述冻结金额中的剩余部分返回扣款渠道对应的账户。
基于同样的思路，本说明书实施例还提供了上述方法对应的设备。
图7为本说明书实施例提供的对应于图1的一种支付码生成设备的结构示意图。如图7所示，设备700可以包括：
至少一个处理器710；以及，
与所述至少一个处理器通信连接的存储器730；其中，
所述存储器730存储有可被所述至少一个处理器710执行的指令720，所述指令被所述至少一个处理器710执行，以使所述至少一个处理器710能够：
获取第一终端发送的账户信息，所述第一终端与所述账户信息的绑定设备不同；
获取所述第一终端发送的第一身份验证信息；
验证所述第一身份验证信息，得到第一验证结果；
当所述第一验证结果表示所述第一身份验证信息验证成功时，生成所述账户信息对应的支付码；
将所述支付码发送至所述第一终端。
基于同样的思路，本说明书实施例还提供了上述方法对应的设备。
图8为本说明书实施例提供的对应于图2的一种支付码生成设备的结构示意图。如图8所示，设备800可以包括：
至少一个处理器810；以及，
与所述至少一个处理器通信连接的存储器830；其中，
所述存储器830存储有可被所述至少一个处理器810执行的指令820，所述指令被所述至少一个处理器810执行，以使所述至少一个处理器810能够：
第一终端获取账户信息；所述第一终端与所述账户信息的绑定设备不同；
获取第一身份验证信息；
将所述账户信息和所述第一身份验证信息发送至服务器；
当所述服务器确定所述第一身份验证信息验证成功时，接收所述服务器发送的所述账户信息的支付码；
打印所述支付码。
基于同样的思路，本说明书实施例还提供了上述方法对应的设备。
图9为本说明书实施例提供的对应于图3的一种移动支付设备的结构示意图。如图9所示，设备900可以包括：
至少一个处理器910；以及，
与所述至少一个处理器通信连接的存储器930；其中，
所述存储器930存储有可被所述至少一个处理器910执行的指令920，所述指令被所述至少一个处理器910执行，以使所述至少一个处理器910能够：
获取针对所述支付码的扣款请求；
确定所述扣款请求对应的交易信息；
确定所述支付码的支付限制条件；
判断所述交易信息是否满足所述支付限制条件；
若是，根据所述扣款请求进行扣款操作。
在20世纪90年代，对于一个技术的改进可以很明显地区分是硬件上的改进(例如，对二极管、晶体管、开关等电路结构的改进)还是软件上的改进(对于方法流程的改进)。然而，随着技术的发展，当今的很多方法流程的改进已经可以视为硬件电路结构的直接改进。设计人员几乎都通过将改进的方法流程编程到硬件电路中来得到相应的硬件电路结构。因此，不能说一个方法流程的改进就不能用硬件实体模块来实现。例如，可编程逻辑器件(Programmable Logic Device,PLD)(例如现场可编程门阵列(Field Programmable Gate Array，FPGA))就是这样一种集成电路，其逻辑功能由用户对器件编程来确定。由设计人员自行编程来把一个数字系统“集成”在一片PLD上，而不需要请芯片制造厂商来设计和制作专用的集成电路芯片。而且，如今，取代手工地制作集成电路芯片，这种编程也多半改用“逻辑编译器(logic compiler)”软件来实现，它与程序开发撰写时所用的软件编译器相类似，而要编译之前的原始代码也得用特定的编程语言来撰写，此称之为硬件描述语言(Hardware Description Language，HDL)，而HDL也并非仅有一种，而是有许多种，如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)等，目前最普遍使用的是VHDL(Very-High-Speed Integrated Circuit Hardware Description Language)与Verilog。本领域技术人员也应该清楚，只需要将方法流程用上述几种硬件描述语言 稍作逻辑编程并编程到集成电路中，就可以很容易得到实现该逻辑方法流程的硬件电路。
控制器可以按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(Application Specific Integrated Circuit，ASIC)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：ARC 625D、Atmel AT91SAM、Microchip PIC18F26K20以及Silicone Labs C8051F320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。
上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。
为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。
本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的 功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。
内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。
计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。
还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。
本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序 模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (28)

  1. 一种支付码生成方法，包括：
    获取第一终端发送的账户信息，所述第一终端与所述账户信息的绑定设备不同；
    获取所述第一终端发送的第一身份验证信息；
    验证所述第一身份验证信息，得到第一验证结果；
    当所述第一验证结果表示所述第一身份验证信息验证成功时，生成所述账户信息对应的支付码；
    将所述支付码发送至所述第一终端。
  2. 如权利要求1所述的方法，在生成所述账户信息的支付码之前，还包括：
    确定支付限制条件，所述支付限制条件用于约束所述支付码的线下支付。
  3. 如权利要求2所述的方法，确定所述支付限制条件，具体包括：
    确定支付额度阈值；和/或，
    确定支付次数阈值；和/或，
    确定有效时间范围；
    其中，所述支付额度阈值用于限定所述支付码的支付金额上限，所述支付次数阈值用于限定所述支付码在有效时间范围内的支付次数，所述支付码在所述有效时间范围内有效。
  4. 如权利要求3所述的方法，确定所述支付额度阈值，具体包括：
    获取所述第一终端发送的第一支付额度阈值；
    根据所述账号信息确定第二支付额度阈值；
    判断所述第一支付额度阈值是否小于所述第二支付额度阈值；
    若是，确定所述第一支付额度阈值为所述支付额度阈值。
  5. 如权利要求4所述的方法，在判断所述第一支付额度阈值是否小于所述第二支付额度阈值之后，还包括：
    若所述第一支付额度阈值大于所述第二支付额度阈值，获取所述第一终端发送的第二身份验证信息；
    验证所述第二身份验证信息，得到第二验证结果；
    当所述第二验证结果表示所述第二身份验证信息验证成功时，确定所述第一支付额度阈值为所述支付额度阈值。
  6. 如权利要求1所述的方法，获取所述第一身份验证信息，具体包括：
    获取密码登录信息或生物特征信息。
  7. 如权利要求3所述的方法，在确定所述支付限制条件之后，所述方法还包括：
    根据所述支付限制条件确定预扣款，所述预扣款用于所述支付码的线下支付；
    确定扣款渠道；
    根据所述扣款渠道从指定账户中冻结所述预扣款对应的金额。
  8. 如权利要求7所述的方法，根据所述扣款渠道从指定账户中扣除所述预扣款对应的金额，具体包括：
    判断所述扣款渠道是否为第三方支付渠道；
    若所述扣款渠道为第三方支付渠道，调用所述扣款渠道对应的第三方支付工具；
    确定所述扣款渠道对应的付款账户；
    利用所述第三方支付工具从所述付款账户中冻结所述预扣款对应的金额。
  9. 如权利要求7所述的方法，根据所述支付限制条件确定预扣款，具体包括：
    将所述支付额度阈值和所述支付次数阈值的乘积确定为所述预扣款的金额，其中，所述支付额度阈值为单次支付额度阈值。
  10. 如权利要求7所述的方法，根据所述支付限制条件确定预扣款，具体包括：
    将所述支付额度阈值确定为所述预扣款的金额，其中，所述支付额度阈值为总支付额度阈值。
  11. 一种移动支付方法，所述方法基于的支付码是采用权利要求1所述的支付码生成方法生成的，包括：
    获取针对所述支付码的扣款请求；
    确定所述扣款请求对应的交易信息；
    确定所述支付码的支付限制条件；
    判断所述交易信息是否满足所述支付限制条件；
    若所述交易信息满足所述支付限制条件，根据所述扣款请求进行扣款操作。
  12. 如权利要求11所述的方法，所述支付限制条件包括支付金额阈值，
    判断所述交易信息是否满足所述支付限制条件，具体包括：
    确定所述交易信息的扣款金额；
    判断所述扣款金额是否小于所述支付金额阈值。
  13. 如权利要求11所述的方法，所述支付限制条件包括支付次数阈值，
    判断所述交易信息是否满足所述支付限制条件，具体包括：
    获取所述支付码的支付次数；
    判断所述支付次数是否小于所述支付次数阈值；
    在所述根据所述扣款请求进行扣款操作之后，还包括：
    对所述支付码的支付次数加一。
  14. 如权利要求11所述的方法，所述支付限制条件包括有效时间范围，
    判断所述交易信息是否满足支付限制条件，具体包括：
    判断所述交易信息的发起时间是否属于所述有效时间范围。
  15. 如权利要求11所述的方法，根据所述扣款请求进行扣款操作，具体包括：
    从所述支付码的生成过程中确定的冻结金额中扣除所述交易信息对应的扣款金额。
  16. 如权利要求15所述的方法，在根据所述扣款请求进行扣款操作之后，还包括：
    当确定超过所述支付码的有效时间范围时，将所述冻结金额中的剩余部分返回扣款渠道对应的账户。
  17. 一种支付码生成方法，包括：
    第一终端获取账户信息，所述第一终端与所述账户信息的绑定设备不同；
    获取第一身份验证信息；
    将所述账户信息和所述第一身份验证信息发送至服务器；
    当所述服务器确定所述第一身份验证信息验证成功时，接收所述服务器发送的所述账户信息的支付码；
    打印所述支付码。
  18. 如权利要求17所述的方法，在接收所述服务器发送的所述账户信息的支付码之前，还包括：
    获取用户输入的支付限制条件，所述支付限制条件用于约束所述支付码的线下支付；
    将所述支付限制条件发送至服务器。
  19. 如权利要求18所述的方法，获取所述用户输入的所述支付限制条件，具体包括：
    获取支付额度阈值；和/或，
    获取支付次数阈值；和/或，
    获取有效时间范围；
    其中，所述支付额度阈值用于限定所述支付码的支付金额上限，所述支付次数阈值用于限定所述支付码在有效时间范围内的支付次数，所述支付码在所述有效时间范围内有效。
  20. 如权利要求18所述的方法，在获取所述用户输入的所述支付限制条件之后，还包括：
    获取所述用户输入的扣款渠道，所述扣款渠道表示所述支付码用于支付的金额的扣款渠道；
    将所述扣款渠道发送至服务器。
  21. 如权利要求17所述的方法，获取所述第一身份验证信息，具体包括：
    获取密码登录信息或生物特征信息。
  22. 如权利要求18所述的方法，获取所述支付额度阈值，具体包括：
    获取第一支付额度信息；
    在获取所述支付额度阈值之后，还包括：
    接收到所述服务器返回的安全验证指令；所述安全验证指令是所述服务器确定所述第一支付额度信息大于所述账户的预设支付额度后生成的；
    显示验证信息输入界面；
    获取基于所述验证信息输入界面输入的第二身份验证信息；
    将所述第二身份验证信息发送至所述服务器。
  23. 一种支付码生成装置，包括：
    账户信息获取模块，用于获取第一终端发送的账户信息，所述第一终端与所述账户信息的绑定设备不同；
    第一身份验证信息获取模块，用于获取所述第一终端发送的第一身份验证信息；
    第一验证模块，用于验证所述第一身份验证信息，得到第一验证结果；
    支付码生成模块，用于当所述第一验证结果表示所述第一身份验证信息验证成功时，生成所述账户信息对应的支付码；
    支付码发送模块，用于将所述支付码发送至所述第一终端。
  24. 一种移动支付装置，所述装置基于的支付码是采用权利要求1所述的支付码生成方法生成的，包括：
    扣款请求获取模块，用于获取针对所述支付码的扣款请求；
    交易信息确定模块，用于确定所述扣款请求对应的交易信息；
    支付限制条件确定模块，用于确定所述支付码的支付限制条件；
    判断模块，用于判断所述交易信息是否满足所述支付限制条件；
    扣款操作模块，用于所述交易信息满足所述支付限制条件时，根据所述扣款请求进行扣款操作。
  25. 一种支付码生成装置，包括：
    账户信息获取模块，用于第一终端获取账户信息，所述第一终端与所述账户信息的 绑定设备不同；
    第一身份验证信息获取模块，用于获取第一身份验证信息；
    第一发送模块，用于将所述账户信息和所述第一身份验证信息发送至服务器；
    第一接收模块，用于当所述服务器确定所述第一身份验证信息验证成功时，接收所述服务器发送的所述账户信息的支付码；
    支付码打印模块，用于打印所述支付码。
  26. 一种支付码生成设备，包括：
    至少一个处理器；以及，
    与所述至少一个处理器通信连接的存储器；其中，
    所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够：
    获取第一终端发送的账户信息，所述第一终端与所述账户信息的绑定设备不同；
    获取所述第一终端发送的第一身份验证信息；
    验证所述第一身份验证信息，得到第一验证结果；
    当所述第一验证结果表示所述第一身份验证信息验证成功时，生成所述账户信息对应的支付码；
    将所述支付码发送至所述第一终端。
  27. 一种支付码生成设备，包括：
    至少一个处理器；以及，
    与所述至少一个处理器通信连接的存储器；其中，
    所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够：
    第一终端获取账户信息，所述第一终端与所述账户信息的绑定设备不同；
    获取第一身份验证信息；
    将所述账户信息和所述第一身份验证信息发送至服务器；
    当所述服务器确定所述第一身份验证信息验证成功时，接收所述服务器发送的所述账户信息的支付码；
    打印所述支付码。
  28. 一种移动支付设备，包括：
    至少一个处理器；以及，
    与所述至少一个处理器通信连接的存储器；其中，
    所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够：
    获取针对所述支付码的扣款请求；
    确定所述扣款请求对应的交易信息；
    确定所述支付码的支付限制条件；
    判断所述交易信息是否满足所述支付限制条件；
    若是，根据所述扣款请求进行扣款操作。
PCT/CN2019/112170 2018-12-05 2019-10-21 支付码生成、移动支付方法、装置及设备 WO2020114113A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201811476736.0 2018-12-05
CN201811476736.0A CN110009335B (zh) 2018-12-05 2018-12-05 支付码生成、移动支付方法、装置及设备

Publications (1)

Publication Number Publication Date
WO2020114113A1 true WO2020114113A1 (zh) 2020-06-11

Family

ID=67165036

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/112170 WO2020114113A1 (zh) 2018-12-05 2019-10-21 支付码生成、移动支付方法、装置及设备

Country Status (3)

Country Link
CN (2) CN110009335B (zh)
TW (1) TW202022733A (zh)
WO (1) WO2020114113A1 (zh)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110009335B (zh) * 2018-12-05 2021-01-26 创新先进技术有限公司 支付码生成、移动支付方法、装置及设备
CN112036882A (zh) * 2020-08-31 2020-12-04 维沃移动通信有限公司 账户登录方法、装置及电子设备
CN112036869A (zh) * 2020-09-03 2020-12-04 中国银行股份有限公司 扫码支付的方法、移动终端、计算机设备及可读存储介质
CN114493579A (zh) * 2020-11-13 2022-05-13 Oppo广东移动通信有限公司 一种移动支付方法、移动支付装置、电子设备和存储介质
CN115131885A (zh) * 2022-06-20 2022-09-30 中国工商银行股份有限公司 移动交通工具计费方法及装置

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103646327A (zh) * 2013-11-14 2014-03-19 成都博约创信科技有限责任公司 基于二维码的支付方法
US9842330B1 (en) * 2016-09-06 2017-12-12 Apple Inc. User interfaces for stored-value accounts
CN107609877A (zh) * 2017-09-18 2018-01-19 上海博路信息技术有限公司 一种生物识别的兑换方法和系统
CN107833052A (zh) * 2017-10-27 2018-03-23 南京物联传感技术有限公司 一种基于区块链的聚合支付系统及工作方法
CN108520417A (zh) * 2018-03-21 2018-09-11 广东欧珀移动通信有限公司 支付方法、装置、服务器、支付终端及计算机可读介质
CN108573382A (zh) * 2018-03-27 2018-09-25 英业达科技有限公司 基于生物特征的信用支付系统及其方法
CN110009335A (zh) * 2018-12-05 2019-07-12 阿里巴巴集团控股有限公司 支付码生成、移动支付方法、装置及设备

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101165716A (zh) * 2006-10-16 2008-04-23 祁勇 一种基于交易代码的电子支付方法
CN103020818B (zh) * 2013-01-09 2016-04-20 重庆钱阿宝电子科技有限公司 动态二维验证码支付系统
CN104217333A (zh) * 2014-05-12 2014-12-17 陈俊 一种借助移动终端、互联网和计算机的认证支付方法
DE102015121300A1 (de) * 2015-12-08 2017-06-08 Tianjin Huanmao Jietong E-Commerce GmbH Elektronisches Geschäftsverbindung-System
CN108734471A (zh) * 2018-05-15 2018-11-02 惠龙易通国际物流股份有限公司 移动支付系统中身份认证方法、装置、系统和存储介质

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103646327A (zh) * 2013-11-14 2014-03-19 成都博约创信科技有限责任公司 基于二维码的支付方法
US9842330B1 (en) * 2016-09-06 2017-12-12 Apple Inc. User interfaces for stored-value accounts
CN107609877A (zh) * 2017-09-18 2018-01-19 上海博路信息技术有限公司 一种生物识别的兑换方法和系统
CN107833052A (zh) * 2017-10-27 2018-03-23 南京物联传感技术有限公司 一种基于区块链的聚合支付系统及工作方法
CN108520417A (zh) * 2018-03-21 2018-09-11 广东欧珀移动通信有限公司 支付方法、装置、服务器、支付终端及计算机可读介质
CN108573382A (zh) * 2018-03-27 2018-09-25 英业达科技有限公司 基于生物特征的信用支付系统及其方法
CN110009335A (zh) * 2018-12-05 2019-07-12 阿里巴巴集团控股有限公司 支付码生成、移动支付方法、装置及设备

Also Published As

Publication number Publication date
CN110009335A (zh) 2019-07-12
TW202022733A (zh) 2020-06-16
CN112785309A (zh) 2021-05-11
CN110009335B (zh) 2021-01-26

Similar Documents

Publication Publication Date Title
WO2020114113A1 (zh) 支付码生成、移动支付方法、装置及设备
US9864987B2 (en) Account provisioning authentication
JP6445031B2 (ja) 高スループットの料金支払い及びシステムアクセスを可能にするバイオメトリックソリューション
US10902415B2 (en) Payment card binding method, trust evaluation method, apparatus, and electronic device
US11961091B2 (en) Dynamic modification of a verification method associated with a transaction card
US20150120557A1 (en) Fingerprint payment method and related device and system
WO2020238231A1 (zh) 一种转账请求的处理方法、装置及设备
US20150081554A1 (en) Systems and Methods for Managing Mobile Account Holder Verification Methods
WO2016062173A1 (zh) 用户属性数值转移方法及终端
WO2021114895A1 (zh) 一种网络支付方法、装置、设备及系统
US20230410087A1 (en) System and method of operating a secure contactless transaction
US10083443B1 (en) Persistent authentication of a wearable device
US11887106B2 (en) Provisioning of secure application
US20170228735A1 (en) Fraud prevention security system
US11978042B1 (en) Systems and methods for providing queued credentials for an account
CN108280645A (zh) 付款码获取、支付请求响应方法、装置以及设备
US20130068836A1 (en) Authorizing Financial Transactions
US11367076B2 (en) Entity-based controls for value transfer cards
CA2944084C (en) Provisioning of secure application
US11410138B2 (en) Value transfer card management system
US8616444B2 (en) Authorizing financial transactions
CA3047263A1 (en) Value transfer card management system
CA3047266A1 (en) Entity-based controls for value transfer cards

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19892261

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19892261

Country of ref document: EP

Kind code of ref document: A1