Payment code generation method, payment code verification method and device, storage medium, terminal

Abstract

A payment code generation method, a payment code verification method and device, a storage medium, and a terminal, wherein the payment code generation method comprises: in response to receiving a payment code generation request, determining a working key, and using the working key to encrypt current time data to obtain a time factor; encrypting based on the first part of the data of the payment application identifier and the first part of the data of the time factor to generate a first payment subcode; encrypting based on the second part of the data of the payment application identifier and the first payment subcode to generate a second payment subcode, wherein the first part of the data of the payment application identifier and the second part of the data are the same at a specified data position; encrypting based on at least the user identifier, the first payment subcode, and the second payment subcode to generate a third payment subcode; and splicing the first payment subcode, the second payment subcode, and the third payment subcode to generate a payment code. The above scheme can generate a payment code with higher security and complexity.

Description

Technical Field

[0001] The present invention relates to the technical field of payment code generation, and in particular to a payment code generation method, a payment code verification method and device, a storage medium, and a terminal. Background Art

[0002] Payment code is a mainstream payment method currently using payment applications. For example, in convenience stores, shops, restaurants and other consumption places, users can show the payment code of the mobile terminal when checking out, and the merchant can use an infrared payment code scanner to scan the payment code (for example, barcode, QR code) displayed on the user's mobile phone to initiate cashiering.

[0003] The rapid popularization of payment codes has brought great convenience to people's lives, but at the same time, due to the existence of random intrusions, data tampering, theft and other problems, this payment method requires stronger security protection. For example, after the user generates a payment code and waits in line for payment, the probability of the payment code being maliciously cracked or tampered with for illegal payment is high, resulting in the inability to guarantee payment security. Summary of the invention

[0004] The technical problem solved by the embodiments of the present invention is how to generate a payment code with higher security and complexity, so that the difficulty of the payment code being maliciously cracked or tampered with is greatly increased.

[0005] To solve the above technical problems, an embodiment of the present invention provides a payment code generation method, comprising the following steps: in response to receiving a payment code generation request, determining a working key, and using the working key to encrypt current time data to obtain a time factor, wherein the working key is obtained by encrypting a user identifier using a preset first key; encrypting based on the first part of data of the payment application identifier and the first part of data of the time factor to generate a first payment subcode; encrypting based on the second part of data of the payment application identifier and the first payment subcode to generate a second payment subcode, wherein the second part of data of the payment application identifier is the same as the first part of data of the payment application identifier at a specified data bit; encrypting based on at least the user identifier, the first payment subcode and the second payment subcode to generate a third payment subcode; and concatenating the first payment subcode, the second payment subcode and the third payment subcode to generate a payment code.

[0006] Optionally, determining the working key includes: determining whether there is a pre-stored working key; if not, using the first key to decrypt the pre-encrypted background working key to obtain a key plaintext; verifying the key plaintext, and if the verification passes, using the key plaintext to encrypt the user identifier to obtain the working key.

[0007] Optionally, the first part of data based on the payment application identifier and the first part of data based on the time factor are encrypted to generate a first payment sub-code, including: performing XOR processing on the first part of data based on the payment application identifier and the first part of data based on the time factor to obtain a first XOR result; and encrypting the first XOR result to generate the first payment sub-code.

[0008] Optionally, the second part of data based on the payment application identifier and the first payment sub-code are encrypted to generate a second payment sub-code, including: performing data conversion on the first data bit in the second part of data identified by the payment application to obtain converted data; splicing the converted data and the second data bit and the third data bit in the second part of data identified by the payment application to obtain first spliced ​​data; and encrypting based on the first spliced ​​data and the first payment sub-code to generate the second payment sub-code.

[0009] Optionally, encrypting the first spliced ​​data and the first payment subcode to generate the second payment subcode includes: performing hexadecimal conversion on the first spliced ​​data to obtain converted first spliced ​​data; performing XOR processing on the converted first spliced ​​data and a first part of data of the first payment subcode to obtain a second XOR result; and encrypting the second XOR result to generate the second payment subcode.

[0010] Optionally, encryption is performed at least based on the user identifier, the first payment subcode and the second payment subcode to generate a third payment subcode, including: splicing the first payment subcode and the second payment subcode to obtain second spliced ​​data; performing XOR processing based on the user identifier and the second spliced ​​data to obtain a third XOR result; and encrypting the third XOR result to generate the third payment subcode.

[0011] Optionally, performing XOR processing on the user identifier and the second spliced ​​data to obtain a third XOR result includes: splicing the key version identifier and the first part of data of the user identifier to obtain third spliced ​​data, wherein the user identifier includes a check bit and the first part of data; performing XOR processing on the second spliced ​​data and the third spliced ​​data to obtain the third XOR result.

[0012] The embodiment of the present invention also provides a payment code verification method, comprising the following steps: in response to receiving a payment code verification request, parsing the payment code to be verified to obtain a first payment subcode to be verified, a second payment subcode to be verified, and a third payment subcode to be verified, wherein the payment code is generated based on the above-mentioned payment code generation method; decrypting the first payment subcode to be verified, the second payment subcode to be verified, and the third payment subcode to be verified to obtain a user identifier to be verified; encrypting the user identifier to be verified using the first key to obtain a working key to be verified; decrypting the first payment subcode to be verified and the second payment subcode to be verified to obtain a second part of data of the payment application identifier to be verified; and decrypting the second part of data of the payment application identifier to be verified based on the working key to be verified and the second part of data of the payment application identifier to be verified. Perform one or more rounds of iterative operations; wherein the iterative operation includes: starting from the first round of iteration, using the working key to be verified to encrypt the time data to be encrypted in the current round to obtain the time factor to be verified in the current round; decrypting based on the first part of the data of the time factor to be verified in the current round and the first payment subcode to be verified, and determining the iteration result of the current round; if the iteration result of the current round is different from the second part of the data of the payment application identifier to be verified in the specified data position, then reducing the preset time length of the time data to be encrypted in the current round to obtain the time data to be encrypted in the next round, and continuing the next round of iterative operation; until the iteration result of the current round is the same as the second part of the data of the payment application identifier to be verified in the specified data position, and the current iteration round is less than the preset round, stop the iteration and confirm that the payment code to be verified has passed the verification.

[0013] Optionally, if the current iteration round reaches a preset round, and the iteration result of the current round is still different from the second part of the data of the payment application identifier to be verified at the specified data position, the iteration is stopped and it is confirmed that the payment code to be verified has failed verification.

[0014] Optionally, the use of the first key to encrypt the user identification to be verified to obtain the working key to be verified includes: using the first key to decrypt the pre-encrypted background working key to obtain a key plaintext; verifying the key plaintext, and if the verification passes, using the key plaintext to encrypt the user identification to be verified to obtain the working key to be verified.

[0015] Optionally, based on the first part of the data of the time factor to be verified in the current round and the first payment subcode to be verified, the iterative result of the current round is determined by decrypting, including: decrypting the first payment subcode to be verified to obtain the first XOR result to be verified in the current round; performing XOR processing on the first XOR result to be verified in the current round and the first part of the data of the time factor to be verified in the current round to obtain the iterative result of the current round.

[0016] Optionally, decryption is performed based on the first payment subcode to be verified and the second payment subcode to be verified to obtain the second part of data of the payment application identifier to be verified, including: decryption is performed based on the first payment subcode to be verified and the second payment subcode to be verified to obtain the first spliced ​​data to be verified; parsing the first spliced ​​data to be verified to obtain the conversion data to be verified and the second data bit and the third data bit in the second part of data of the payment application identifier to be verified; performing data inverse conversion on the conversion data to be verified to obtain the first data bit in the second part of data of the payment application identifier to be verified; splicing the first data bit, the second data bit and the third data bit in the second part of data of the payment application identifier to be verified to obtain the second part of data of the payment application identifier to be verified.

[0017] Optionally, decryption is performed based on the first payment subcode to be verified and the second payment subcode to be verified to obtain the first spliced ​​data to be verified, including: decrypting the second payment subcode to obtain a second XOR result to be verified; performing XOR processing on the second XOR result to be verified and the first part of data of the first payment subcode to be verified to obtain the first spliced ​​data after conversion to be verified; performing decimal conversion on the first spliced ​​data after conversion to be verified to obtain the first spliced ​​data to be verified.

[0018] Optionally, decryption is performed based on the first payment subcode to be verified, the second payment subcode to be verified, and the third payment subcode to be verified to obtain a user identification to be verified, including: decrypting the third payment subcode to be verified to obtain a third XOR result to be verified; splicing the first payment subcode to be verified and the second payment subcode to be verified to obtain second spliced ​​data to be verified; performing XOR processing based on the third XOR result to be verified and the second spliced ​​data to be verified to obtain the user identification to be verified.

[0019] Optionally, performing XOR processing on the third XOR result to be verified and the second spliced ​​data to be verified to obtain the user identifier to be verified, including: performing XOR processing on the third XOR result to be verified and the second spliced ​​data to be verified to obtain the third spliced ​​data to be verified; parsing the third spliced ​​data to be verified to obtain the first part data of the user identifier to be verified, wherein the user identifier to be verified includes a check bit and the first part data; determining the check bit of the user identifier to be verified based on the first part data of the user identifier to be verified, and splicing the check bit of the user identifier to be verified and the first part data of the user identifier to be verified to obtain the user identifier to be verified.

[0020] An embodiment of the present invention also provides a payment code generation device, including: a time factor determination module, used to determine a working key in response to receiving a payment code generation request, and use the working key to encrypt current time data to obtain a time factor, wherein the working key is obtained by encrypting a user identifier using a preset first key; a first encryption module, used to encrypt based on a first part of data of a payment application identifier and a first part of data of the time factor to generate a first payment subcode; a second encryption module, used to encrypt based on a second part of data of the payment application identifier and the first payment subcode to generate a second payment subcode, wherein the second part of data of the payment application identifier is the same as the first part of data of the payment application identifier at a specified data bit; a third encryption module, used to encrypt based on at least the user identifier, the first payment subcode and the second payment subcode to generate a third payment subcode; a payment code generation module, used to splice the first payment subcode, the second payment subcode and the third payment subcode to generate a payment code.

[0021] The embodiment of the present invention further provides a payment code verification device, comprising: a payment code parsing module, for parsing the payment code to be verified in response to receiving a payment code verification request, to obtain a first payment subcode to be verified, a second payment subcode to be verified, and a third payment subcode to be verified, wherein the payment code is generated based on the above-mentioned payment code generation method; a first decryption module, for decrypting based on the first payment subcode to be verified, the second payment subcode to be verified, and the third payment subcode to be verified, to obtain a user identification to be verified; a working key determination module, for encrypting the user identification to be verified using the first key, to obtain a working key to be verified; a second decryption module, for decrypting based on the first payment subcode to be verified and the second payment subcode to be verified, to obtain a second part of data of the payment application identification to be verified; an iteration module, for decrypting based on the working key to be verified and the third payment subcode to be verified The second part of the data of the payment application identifier to be verified is subjected to one or more rounds of iterative operations; wherein the iterative operation includes: starting from the first round of iteration, the time data to be encrypted in the current round is encrypted using the working key to be verified to obtain the time factor to be verified in the current round; decryption is performed based on the first part of the data of the time factor to be verified in the current round and the first payment subcode to be verified to determine the iteration result of the current round; if the iteration result of the current round is different from the second part of the data of the payment application identifier to be verified in the specified data position, the time data to be encrypted in the current round is reduced by a preset time length to obtain the time data to be encrypted in the next round, and the next round of iterative operations is continued; until the iteration result of the current round is the same as the second part of the data of the payment application identifier to be verified in the specified data position, and the current iteration round is less than the preset round, the iteration is stopped and it is confirmed that the payment code to be verified has been verified.

[0022] An embodiment of the present invention further provides a storage medium having a computer program stored thereon, wherein when the computer program is executed by a processor, the computer program executes the steps of the payment code generation method or the steps of the payment code verification method.

[0023] An embodiment of the present invention also provides a terminal, including a memory and a processor, wherein the memory stores a computer program that can be run on the processor, and when the processor runs the computer program, the processor executes the steps of the above-mentioned payment code generation method, or executes the steps of the above-mentioned payment code verification method.

[0024] Compared with the prior art, the technical solution of the embodiment of the present invention has the following beneficial effects:

[0025] In an embodiment of the present invention, the payment code is generated by combining important information such as user identification, time information, and application identification, and at least three encryption operations are performed. Among them, when performing the encryption operation, not only the result of the previous encryption operation is based on the data, but also data different from the data used in the previous encryption operation is introduced as one of the data to be encrypted. Specifically, the data to be encrypted in the "primary encryption" operation are the first part of the data of the payment application identification and the first part of the data of the time factor, and the encryption result is the first payment subcode; the data to be encrypted in the "secondary encryption" operation not only includes the result of the "primary encryption", that is, the first payment subcode, but also includes the second part of the data of the payment application identification, and the encryption result is the second payment subcode; the data to be encrypted in the "secondary encryption" operation not only includes the results of the "primary encryption" and the "secondary encryption", that is, the first payment subcode and the second payment subcode, but also includes the user identification, and the encryption result is the third payment subcode. Finally, the results of the three encryptions are spliced ​​to generate the payment code. In this way, the difficulty of cracking and misappropriation of the payment code can be significantly improved to ensure payment security.

[0026] Furthermore, the user identification is used at least twice in the entire encryption process. One of them is the "working key" as the core key of the encryption and decryption operation, which is obtained by encrypting the user identification. Compared with directly using plain text data as the "working key", this implementation scheme uses ciphertext data containing the user identification as the "working key", which can not only contain the most critical information required to complete the payment, but also help reduce the risk of theft and tampering. The other time is the process of performing the "re-encryption" operation to generate the third payment sub-code, and the user identification is used as one of the data to be encrypted. Compared with directly using the encryption results of the first two times, that is, the first payment sub-code and the second payment sub-code for encryption, this implementation scheme further introduces the user identification, which can further increase the difficulty of cracking and enhance security.

[0027] Further, the second part of the data based on the payment application identifier and the first payment subcode are encrypted to generate the second payment subcode, including: performing data conversion on the first data bit in the second part of the data of the payment application identifier to obtain conversion data; splicing the conversion data and the second data bit and the third data bit in the second part of the data of the payment application identifier to obtain the first spliced ​​data; encrypting based on the first spliced ​​data and the first payment subcode to generate the second payment subcode. It can be understood that if the original data of the second part of the data of the payment application identifier and the first payment subcode are directly used to perform the encryption operation, the encryption result may be easily cracked when the format of the payment application identifier is relatively fixed. In comparison, in the embodiment of the present invention, the second part of the data of the payment application identifier is partially converted in advance, and then some but not all data bits are extracted for splicing, which can effectively increase the obfuscation and complexity of the data format, further increase the difficulty of cracking the encryption result, and improve security.

[0028] In the embodiment of the present invention, when performing the "re-encryption" operation, the first payment subcode and the second payment subcode obtained by the first two encryption operations are first concatenated to obtain the second concatenated data, and then XOR-processed and encrypted in combination with the user identifier. Compared with the user identifier being concatenated with the first payment subcode and the second payment subcode respectively and then encrypted, the present embodiment concatenates the first payment subcode and the second payment subcode. Since the first payment subcode and the second payment subcode are themselves generated by encryption, they themselves have high complexity and concealment, and the second concatenated data and subsequent encryption results obtained by concatenation will be more difficult to crack.

[0029] Further, based on the user identifier and the second spliced ​​data, an XOR process is performed to obtain a third XOR result, including: splicing the key version identifier and the first part of the user identifier to obtain the third spliced ​​data, wherein the user identifier includes the check bit and the first part of the data; performing XOR processing on the second spliced ​​data and the third spliced ​​data to obtain the third XOR result. Since the keys used in actual encryption and decryption operations often have a high update frequency, therefore, on the basis of using the XOR processing method to achieve primary encryption and other encryption algorithms for secondary encryption, the key version identifier is further introduced, which can further increase the difficulty of cracking and improve security without increasing complexity and computational overhead.

[0030] Further, the embodiment of the present invention also provides a payment code verification method, which corresponds to the payment code generation method, and performs one or more rounds of iterative operations by combining the user identifier to be verified, the application identifier to be verified, and the time data that can represent the timing of payment code verification. Specifically, since the timing of payment code verification is after the timing of payment code generation, the preset time length is used as a unit, and the preset time length (for example, 1 second) is reduced in each round of iterative operation for the time data to be encrypted in the current round, and the time data to be encrypted in the next round is obtained, and the next round of iterative operation is continued. It can be understood that if the payment code to be verified is a correct payment code that has not been tampered with, there must be a certain round of iterative operations within the preset rounds, and the iteration result of the current round is exactly the same as the second part of the data of the payment application identifier to be verified at the specified data position. Based on this principle, this implementation scheme can realize accurate verification of the payment code to be verified and ensure payment security by utilizing the sequential relationship between the payment code generation timing and the payment code verification timing. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Figure 1 is a flow chart of a payment code generation method in an embodiment of the present invention;

[0032] Figure 2 yes Figure 1 A flowchart of a specific implementation of step S12;

[0033] Figure 3 yes Figure 1 A flowchart of a specific implementation of step S13;

[0034] Figure 4 yes Figure 1 A flowchart of a specific implementation of step S14;

[0035] Figure 5 is a flow chart of a payment code verification method in an embodiment of the present invention;

[0036] Figure 6 yes Figure 5 A flowchart of a specific implementation of step S52;

[0037] Figure 7 yes Figure 5 A flowchart of a specific implementation method of determining the iteration result of the current round in the iterative operation;

[0038] Figure 8 yes Figure 5 A flowchart of a specific implementation of step S54;

[0039] Fig. 9 is a flow chart of a payment code generating device in an embodiment of the present invention;

[0040] Fig.10 It is a flow chart of a payment code verification device in an embodiment of the present invention. DETAILED DESCRIPTION

[0041] In order to make the above-mentioned objects, features and beneficial effects of the present invention more obvious and understandable, specific embodiments of the present invention are described in detail below with reference to the accompanying drawings.

[0042] Reference Figure 1 , Figure 1 1 is a flow chart of a payment code generation method in an embodiment of the present invention. The method may include steps S11 to S15:

[0043] Step S11: in response to receiving a payment code generation request, determining a working key, and using the working key to encrypt current time data to obtain a time factor, wherein the working key is obtained by encrypting a user identifier using a preset first key;

[0044] Step S12: Encrypting the first part of the data of the payment application identifier and the first part of the data of the time factor to generate a first payment subcode;

[0045] Step S13: Encrypting the second part of the payment application identifier and the first payment subcode to generate a second payment subcode, wherein the second part of the payment application identifier is identical to the first part of the payment application identifier at a specified data position;

[0046] Step S14: Encrypting based on at least the user identification, the first payment subcode and the second payment subcode to generate a third payment subcode;

[0047] Step S15: concatenate the first payment subcode, the second payment subcode and the third payment subcode to generate a payment code.

[0048] It should be noted that the encryption algorithm used in the steps of the encryption operation in this application can be an existing conventional encryption algorithm, such as the basic encryption (Base64) algorithm, the data encryption standard (Data Encryption Standard, DES) algorithm, the byte string encryption (Message-Digest Algorithm 5, MDA5) algorithm, etc. Correspondingly, the steps involving the decryption operation are decrypted using the same algorithm as the corresponding encryption operation.

[0049] In an embodiment of the present invention, the payment code is generated by encrypting important information such as user identification, time information, and application identification, and at least three encryption operations are performed, and the encryption schemes used in each round of encryption operations are not completely consistent. Among them, when performing the encryption operation, not only the result of the previous encryption operation is based on the data, but also data different from the data used in the previous encryption operation is introduced as one of the data to be encrypted. Specifically, the data to be encrypted in the "primary encryption" operation are the first part of the data of the payment application identification and the first part of the data of the time factor, and the encryption result is the first payment subcode; the data to be encrypted in the "secondary encryption" operation not only includes the result of the "primary encryption", that is, the first payment subcode, but also includes the second part of the data of the payment application identification, and the encryption result is the second payment subcode; the data to be encrypted in the "secondary encryption" operation not only includes the results of the "primary encryption" and the "secondary encryption", that is, the first payment subcode and the second payment subcode, but also includes the user identification, and the encryption result is the third payment subcode. Finally, the results of the three encryptions are spliced ​​to generate the payment code. In this way, the difficulty of cracking and misappropriation of the payment code can be significantly improved to ensure payment security.

[0050] Furthermore, the user identification is used at least twice in the entire encryption process. One is the "working key" as the core key for encryption and decryption operations, which is obtained by encrypting the user identification. Compared with directly using plain text data as the "working key", this implementation scheme uses ciphertext data containing the user identification as the "working key", which can not only contain the most critical information required to complete the payment, but also help reduce the risk of theft and tampering. The other is the process of performing the "re-encryption" operation to generate the third payment subcode. The user identification is one of the data to be encrypted. Compared with directly using the encryption results of the first two times, that is, the first payment subcode and the second payment subcode for encryption, this implementation scheme further introduces the user identification, which can enhance the identity attribute of the payment code, and further increase the difficulty of cracking and enhance security.

[0051] In some embodiments, the payment code may be generated offline. In this case, the payment code generation method may be applied to a payer terminal, which may also be referred to as a client, user terminal or payment terminal. The payment terminal may be selected from, but not limited to, various mobile terminals such as mobile phones, tablet computers, and smart wearable devices (e.g., smart watches).

[0052] In other embodiments, the payment code may be generated online. In this case, the payment code generation method may be applied to a payment service terminal, which may also be referred to as a server or payment service terminal. The payment service terminal may be selected from but not limited to a payment service system, server, cloud platform, etc. provided by a payment service provider or a payment application developer.

[0053] The payment code may be displayed on the client's screen in black and white or color image format, and its display format may be selected from but not limited to QR code, bar code, etc.

[0054] The above steps S11 to S15 are described in detail below.

[0055] In the specific implementation of step S11, the payment code generation request may be triggered by the user. For example, the user triggers the payment code generation request by clicking or touching the payment button on the screen to generate a new payment code. For another example, the user triggers the payment code generation request by clicking or touching a payment code generated in the past on the screen to update the payment code generated in the past.

[0056] Furthermore, determining the working key in step S11 may specifically include: judging whether there is a pre-stored working key; if not, using the first key to decrypt the pre-encrypted background working key to obtain a key plaintext; verifying the key plaintext, and if the verification passes, using the key plaintext to encrypt the user identifier to obtain the working key.

[0057] In the embodiment of the present invention, since the working key not only contains the important information of the user identification information, but also plays an important role in the payment code generation stage and the payment code verification stage, this implementation scheme performs double protection on the key used to encrypt the user identification (i.e., the background working key) in the operation of generating the working key. The first level of protection is to store the background working key in ciphertext form, and the second level of protection is to decrypt and verify the background working key before encrypting the user identification, and only encrypt the user identification when the verification passes to obtain the working key. Therefore, compared with directly using a preset key to encrypt the user identification to obtain the working key, this implementation scheme can significantly increase the complexity of the working key being stolen and tampered with, and improve the security of the payment code.

[0058] Furthermore, if there is a pre-stored working key, the pre-stored working key can be used as the working key of the embodiment of the present invention after confirming that the pre-stored working key is within the preset validity period. In this way, there is no need to perform the working key generation operation each time, thereby reducing the computational overhead.

[0059] In a specific implementation, the current time data may be the system timestamp information corresponding to the time point when the payment code generation request is received, or the system timestamp information corresponding to the time point when the working key is determined, or the system timestamp information corresponding to the time point when the encryption operation is performed using the working key, or other appropriate time information that can characterize the timing of generating the payment code may be used as the current time data.

[0060] In the specific implementation of step S12, an "initial encryption" operation is performed, that is, encryption is performed based on the first portion of data of the payment application identifier and the first portion of data of the time factor to generate a first payment subcode.

[0061] In the first specific implementation of step S12, the "initial encryption" operation can use the following "single-round" encryption method to encrypt the original data to generate the first payment sub-code, which can specifically include: selecting one of the first part data of the payment application identifier and the first part data of the time factor as the key for encryption, and the other as the data to be encrypted; encrypting the data to be encrypted using the selected key through an encryption algorithm to obtain the first payment sub-code.

[0062] In the second specific implementation of step S12, the "initial encryption" operation can be encrypted using a "double-round" encryption method to generate the first payment subcode. Specifically, the original data can be XORed first, and then the XORed result can be encrypted to obtain the first payment subcode. Figure 2 The "two-round" encryption scheme of the second specific implementation method is described in detail.

[0063] like Figure 2 As shown, Figure 2 yes Figure 1 Specifically, the encryption method of this embodiment may include steps S21 to S22.

[0064] In step S21, an XOR process is performed on the first part of the data of the payment application identifier and the first part of the data of the time factor to obtain a first XOR result.

[0065] Among them, the first part of the data of the payment application identifier and the first part of the data of the time factor can be appropriately selected from the original payment application identifier and the time factor according to actual needs. For example, several data bits can be selected from the left side of the payment application identifier and several data bits can be selected from the right side of the time factor for XOR processing. For another example, several data bits can be selected from the middle area of ​​the payment application identifier and the time factor for XOR processing. Alternatively, other appropriate methods can be selected to select several data bits for XOR processing.

[0066] As a non-limiting embodiment, the first part of the payment application identifier may be the last 7 digits of the payment application identifier; the first part of the time factor may be the first 3 digits of the time factor.

[0067] In step S22, the first XOR result is encrypted to generate the first payment subcode.

[0068] In an embodiment of the present invention, since the XOR operation itself is a simple encryption method, by first performing XOR processing on the first part of the data of the payment application identifier and the first part of the data of the time factor, and then using other encryption algorithms for encryption, compared with directly performing a single round of encryption operation on the original data, it helps to improve the cracking complexity of the generated first payment sub-code.

[0069] Furthermore, before executing the XOR processing operation of step S21, the first part of the data of the payment application identifier may be converted into hexadecimal.

[0070] It should be noted that since hexadecimal data can use fewer data bits to express richer data content, it can be more convenient and efficient when performing data integrity and accuracy verification. In particular, for the schemes involving more encryption, XOR, verification and other operations in the embodiments of the present invention, the significance of hexadecimal conversion is more prominent.

[0071] Continue to refer to Figure 1 In the specific implementation of step S13, the first payment subcode obtained by the "primary encryption" operation of step S12 is used to perform a "secondary encryption" operation, that is, the second part of data based on the payment application identifier and the first payment subcode are encrypted to generate a second payment subcode.

[0072] In the first specific implementation of step S13, the "double encryption" operation can use the following "single-round" encryption method to encrypt the original data and generate the second payment sub-code, which can specifically include: selecting one of the second part of the data identified by the payment application and the first payment sub-code as the key for encryption, and the other as the data to be encrypted; encrypting the data to be encrypted using the selected key through an encryption algorithm to obtain the second payment sub-code.

[0073] In the second specific implementation of step S13, the "double encryption" operation can be encrypted by a "double-round" encryption method. Specifically, the original data can be XORed first, and then the XOR result can be encrypted to obtain the second payment subcode.

[0074] In the third specific implementation of step S13, the "double encryption" operation can first perform pre-processing operations such as "data conversion + data bit extraction + data splicing" on the original data to be encrypted, and then perform a "double-round encryption" operation, that is, perform XOR processing and encryption operations in sequence to obtain the second payment subcode. Figure 3 The third encryption scheme mentioned above is described in detail.

[0075] like Figure 3 As shown, Figure 3 yes Figure 1 Flow chart of a specific implementation of step S13 in the embodiment. In this implementation, the encryption and generation of the second payment sub-code in step S13 may specifically include steps S31 to S33.

[0076] In step S31, data conversion is performed on the first data bit in the second part of data of the payment application identifier to obtain converted data.

[0077] In a specific implementation, the method of performing data conversion may be selected from but not limited to data encryption, base conversion, replacing some data bits with 0, data bit sequence conversion, etc.

[0078] In step S32, the second data bit and the third data bit in the second part of the data of the conversion data and the payment application identifier are spliced ​​to obtain first spliced ​​data.

[0079] In a specific implementation, the second part of the data of the payment application identifier and its first, second, and third data bits can be appropriately selected from the original payment application identifier according to actual needs. Among them, the first data bit, the second data bit, and the third data bit can contain one or more bits of data. In order to facilitate the subsequent payment code verification operation and reduce the error probability, data at different positions can be selected from the original payment application identifier as the first data bit, the second data bit, and the third data bit.

[0080] As a non-limiting embodiment, the second part of the data of the payment application identifier can use the 1st to 3rd and 6th to 10th bits of the payment application identifier, wherein the 1st to 2nd bits are used as the first data bits, the 3rd bit is used as the second data bit, and the 6th to 10th bits are used as the third data bits.

[0081] In a specific implementation, the first part of the data of the payment application identifier and the second part of the data of the payment application identifier have the same designated data bits (also referred to as overlapping data bits) which can be set according to actual conditions. For example, the payment application identifier has a total of 10 data bits, the first part of the data of the payment application identifier selects the last 7 bits (i.e., the 4th to 10th bits), and the second part of the data of the payment application identifier selects the 6th to 10th bits, therefore, the first part of the data of the payment application identifier and the second part of the data are the same in the 6th to 10th bits (i.e., the designated data bits).

[0082] In step S33, encryption is performed based on the first splicing data and the first payment subcode to generate the second payment subcode.

[0083] It is understandable that if the original data of the second part of the data of the payment application identifier and the first payment subcode are directly used to perform the encryption operation, the encryption result may be easily cracked when the format of the payment application identifier is relatively fixed. In contrast, in the embodiment of the present invention, the second part of the data of the payment application identifier is partially converted in advance, and then part of the data bits are extracted but not all for splicing, which can effectively increase the obfuscation and complexity of the data format, further increase the difficulty of cracking the encryption result, and improve security.

[0084] Furthermore, the step S33 may specifically include: performing hexadecimal conversion on the first spliced ​​data to obtain converted first spliced ​​data; performing XOR processing on the converted first spliced ​​data and the first part of data of the first payment subcode to obtain a second XOR result; and encrypting the second XOR result to generate the second payment subcode.

[0085] For the principle and technical effect of performing hexadecimal conversion and XOR processing before encryption, see Figure 2 The description of each step in the above will not be repeated here.

[0086] Continue to refer to Figure 1 In the specific implementation of step S14, the first payment subcode obtained by the "primary encryption" operation in step S12, the second payment subcode and the user identification are obtained by the "secondary encryption" operation in step S13, and the "re-encryption" operation is performed, that is: encryption is performed at least based on the user identification, the first payment subcode and the second payment subcode to generate a third payment subcode.

[0087] In the first specific implementation of step S14, the "re-encryption" operation can use the following "single-round" encryption method to encrypt the original data to generate the third payment subcode, which can specifically include: selecting two of the user identifier, the first payment subcode and the second payment subcode as encryption keys, and the other as the data to be encrypted; encrypting the data to be encrypted using the selected key through an encryption algorithm to obtain the third payment subcode.

[0088] In the second specific implementation of step S13, the "re-encryption" operation may include: selecting two of the user identification, the first payment subcode and the second payment subcode for splicing; then performing a "double-round encryption" operation based on the splicing result and the other of the three, that is, first performing XOR processing and then encrypting to obtain the third payment subcode. Figure 4 The second specific implementation method mentioned above is described in detail.

[0089] like Figure 4 As shown, Figure 4 yes Figure 1 Flow chart of a specific implementation of step S14 in the embodiment. In this implementation, the encryption and generation of the third payment sub-code in step S14 may specifically include steps S41 to S43.

[0090] In step S41, the first payment subcode and the second payment subcode are spliced ​​to obtain second spliced ​​data.

[0091] In a specific implementation, the first payment subcode and the second payment subcode may be completely spliced, or some of the data bits thereof may be selected for splicing. The splicing position may be the position after the last data bit of the subcode, the position before the first data bit of the subcode, or the designated position between the first data bit and the last data bit of the subcode.

[0092] For example, some data bits of the second payment subcode may be selected and spliced ​​to the last data bit of the first payment subcode. For another example, some data bits of the first payment subcode may be selected and spliced ​​to the last data bit of the second payment subcode.

[0093] The embodiment of the present invention does not limit the order, position, and method of splicing, as long as it can increase the complexity of data cracking while facilitating subsequent accurate verification.

[0094] In step S42, an XOR process is performed based on the user identifier and the second spliced ​​data to obtain a third XOR result.

[0095] Further, the step S42 may specifically include: splicing the key version identifier and the first part of the user identifier to obtain third spliced ​​data, wherein the user identifier includes a check bit and the first part of the data; performing XOR processing on the second spliced ​​data and the third spliced ​​data to obtain the third XOR result.

[0096] The key version identifier may refer to the version number of the background working key.

[0097] In a specific implementation, the check digit of the user identification may be determined based on the first part of the data of the user identification. For example, the first part of the data of the user identification is encrypted, and the encryption result is used as the check digit. Alternatively, one or more data bits are selected from the user identification as the check digit. Alternatively, the check digit may be determined in other appropriate ways.

[0098] In step S43, the third XOR result is encrypted to generate the third payment subcode.

[0099] In the embodiment of the present invention, in the execution of the "re-encryption" operation, not only the first payment subcode and the second payment subcode obtained by the first two encryption operations are used as the data to be encrypted, but also the key information of the user identification is introduced, which is helpful to enhance the identity attribute of the payment code and increase the difficulty of cracking. Further, compared with the use of the user identification and the first payment subcode and the second payment subcode for splicing and re-encryption, this embodiment splices the first payment subcode and the second payment subcode. Since the first payment subcode and the second payment subcode are themselves generated by encryption, they themselves have high complexity and concealment. The second spliced ​​data obtained by splicing and the subsequent encryption results will be more difficult to crack.

[0100] Furthermore, since the keys used in actual encryption and decryption operations often have a high update frequency, on the basis of using the XOR processing method to achieve primary encryption and other encryption algorithms for secondary encryption, the key version identifier is further introduced to further increase the difficulty of cracking without increasing the complexity and computational overhead.

[0101] Continue to refer to Figure 1 In the specific implementation of step S15, the first payment subcode, the second payment subcode and the third payment subcode are spliced, and a payment code is generated based on the splicing result. Specifically, since the splicing result is in the form of data, the data in the form of data can be converted into a payment code in the form of an image. The method for converting to obtain the payment code can adopt an existing conventional method, which will not be described in detail here.

[0102] In the first specific implementation of step S15, the first payment subcode, the second payment subcode and the third payment subcode may be directly completely spliced. As a non-limiting example, the second payment subcode may be completely spliced ​​to the last data bit of the first payment subcode, and the third payment subcode may be completely spliced ​​to the last data bit of the second payment subcode to obtain a splicing result.

[0103] In the second specific implementation of step S15, multiple data bits can be selected from the left side of the first payment subcode, multiple data bits can be selected from the middle position of the second payment subcode, and multiple data bits can be selected from the right position of the third payment subcode, and the data bits selected from each selected subcode can be completely spliced. In this way, by selecting some data bits at different positions, it is helpful to further increase the difficulty for malicious parties to discover patterns and crack compared to directly using original data for splicing.

[0104] Furthermore, during the splicing operation, a payment code identifier may be added to the first or last data bit to identify the payment code. The payment code identifier may be a single digit or a combination of multiple digits. For example, the number "8" is used as the payment code identifier.

[0105] The embodiment of the present invention also provides a payment code verification method. Figure 5 , Figure 5 is a flow chart of a payment code verification method in an embodiment of the present invention. The payment code verification method can be Figures 1 to 4 The payment code generated by the payment code generation method shown in any embodiment is verified.

[0106] The payment code verification method may specifically include steps S51 to S55.

[0107] Step S51: in response to receiving a payment code verification request, parsing the payment code to be verified to obtain a first payment subcode to be verified, a second payment subcode to be verified, and a third payment subcode to be verified.

[0108] Step S52: decrypt based on the first payment subcode to be verified, the second payment subcode to be verified, and the third payment subcode to be verified to obtain the user identification to be verified.

[0109] Step S53: using the first key to encrypt the user identification to be verified, to obtain a working key to be verified.

[0110] Step S54: decrypting based on the first payment subcode to be verified and the second payment subcode to be verified to obtain the second part of the payment application identifier to be verified.

[0111] Step S55: performing one or more rounds of iterative operations based on the working key to be verified and the second part of the data of the payment application identifier to be verified.

[0112] The iterative operation includes:

[0113] Starting from the first round of iteration, the working key to be verified is used to encrypt the time data to be encrypted in the current round to obtain the time factor to be verified in the current round;

[0114] Decrypting based on the first part of the time factor to be verified in the current round and the first payment subcode to be verified, to determine the iteration result of the current round;

[0115] If the iteration result of the current round is not the same as the second part of the data of the payment application program identifier to be verified at the specified data position, the time data to be encrypted of the current round is reduced by a preset time length to obtain the time data to be encrypted of the next round, and the iteration operation of the next round is continued;

[0116] Until the iteration result of the current round is the same as the second part of the data of the payment application identifier to be verified at the specified data position, and the current iteration round is less than the preset round, the iteration is stopped and it is confirmed that the payment code to be verified has been verified.

[0117] Among them, in the first round of iteration, the time data to be encrypted, for example, may be the system timestamp information corresponding to the time point when the payment code verification request is received; for another example, it may be the system timestamp information corresponding to the time point when the first round of iteration operation starts; for another example, it may be the system timestamp information corresponding to the time point when the encryption operation is performed using the working key to be verified; for another example, other appropriate time information that can indicate the timing of payment code verification may be used, such as selecting the system timestamp information corresponding to an appropriate time point within an appropriate period of time after the payment code is generated.

[0118] The preset time length for reducing the time data to be encrypted in the current round in each iteration is, for example, 1 second, that is, the time data to be encrypted in the current round is reduced by 1 second in each round to obtain the time data to be encrypted in the next round.

[0119] The preset rounds can be appropriately set in combination with the actual payment scenario. For example, the total number of seconds contained in the possible queuing time of the actual payment scenario can be used as the preset rounds. In a non-limiting manner, the total number of seconds of 5 to 20 minutes, that is, 300 to 1200 times, can be set as the preset rounds.

[0120] Further, if the current iteration round reaches the preset round, and the iteration result of the current round is still different from the second part of the data of the payment application identifier to be verified at the specified data position, the iteration is stopped and it is confirmed that the payment code to be verified has failed verification.

[0121] In a specific implementation, after confirming that the payment code to be verified has been verified, it can be confirmed that the user identification to be verified is correct, that is, the user identification to be verified comes from a real and credible payer. The payee can then connect the correctly verified user identification to the payment service provider and deduct money from the user account.

[0122] In the embodiment of the present invention, since the timing of payment code verification is after the timing of payment code generation, 1 second is subtracted from the time data to be encrypted in the current round in each round of iterative operation, and if the payment code to be verified is a correct payment code that has not been tampered with, there must be a certain round of iterative operation within the preset rounds, and the iteration result of the current round is exactly the same as the second part of the data of the payment application identifier to be verified at the specified data position. Based on this principle, the payment code verification scheme provided in the embodiment of the present invention corresponds to the payment code generation scheme, and by utilizing the sequential relationship between the payment code generation timing and the payment code verification timing, and combining the user identifier to be verified, the application identifier to be verified, and the current latest time information to perform one or more rounds of iterative operations, accurate verification of the payment code to be verified can be achieved, ensuring payment security.

[0123] In a specific implementation, the payment code verification method can be applied to a payee terminal, which can also be called a merchant terminal or a point of sale terminal (POS terminal). The payee terminal can be a terminal with data processing function, such as but not limited to: a computer, a mobile phone, a tablet computer, a smart wearable device, a server, a cloud platform, etc.

[0124] In actual applications, if the payee terminal itself does not have the payment code scanning function, the payee terminal usually needs to be connected to a scanning device with payment code scanning function (for example, a desktop or handheld scanner). The scanning device connects to the payee terminal through various methods such as USB, Bluetooth, WIFI, etc. to realize information reading, transmission and processing.

[0125] The above steps S51 to S55 are described in detail below.

[0126] In the specific implementation of step S51, the payment code verification request may be triggered by the payee (specifically, the merchant's salesperson, cashier, waiter, etc.). For example, the payee triggers the payment code verification request by clicking or touching the payment button on the screen. For another example, the payee or the payer in the self-service payment scenario uses a code scanning device to scan the payment code to be verified provided by the user, and the code scanning device triggers the payment code verification request when it recognizes or successfully scans the payment code.

[0127] The parsing of the payment code to be verified may specifically include: first converting the payment code to be verified in the form of an image into payment code data in the form of a data, and then executing Figure 1 Step S15 performs the inverse operation of splicing the first payment subcode, the second payment subcode and the third payment subcode (i.e., payment code data disassembly or decomposition operation) on the first payment subcode, the second payment subcode and the third payment subcode to be verified to obtain the first payment subcode to be verified, the second payment subcode to be verified and the third payment subcode to be verified.

[0128] Combination Figure 6 , Figure 6 yes Figure 5 Flow chart of a specific implementation of step S52 in FIG. Specifically, in this implementation, step S52 may include steps S61 to S63.

[0129] In step S61, the third payment subcode to be verified is decrypted to obtain a third XOR result to be verified.

[0130] Among them, the third payment subcode is generated by encrypting a third XOR result, and the third XOR result is obtained by XOR processing based on the user identifier and the second splicing data, and the second splicing data is obtained by splicing the first payment subcode and the second payment subcode.

[0131] In short, the third payment sub-code is adopted Figure 4 The scheme of steps S41 to S43 shown is generated.

[0132] In step S62, the first payment subcode to be verified and the second payment subcode to be verified are spliced ​​to obtain second spliced ​​data to be verified.

[0133] In step S63, an XOR process is performed based on the third XOR result to be verified and the second concatenated data to be verified to obtain the user identification to be verified.

[0134] Further, the step S63 may include: performing XOR processing on the third XOR result to be verified and the second spliced ​​data to be verified to obtain the third spliced ​​data to be verified; parsing the third spliced ​​data to be verified to obtain the first part data of the user identifier to be verified, wherein the user identifier to be verified includes a check bit and the first part data; based on the first part data of the user identifier to be verified, determining the check bit of the user identifier to be verified, and splicing the check bit of the user identifier to be verified and the first part data of the user identifier to be verified to obtain the user identifier to be verified.

[0135] The third XOR result is obtained by performing XOR processing on the second spliced ​​data and the third spliced ​​data, and the third spliced ​​data is obtained by splicing the key version identifier and the first part of the user identifier.

[0136] It should be pointed out that Figure 6 Steps S61 to S63 shown in FIG. Figure 4 The steps S41 to S43 shown in FIG. Figure 6 The steps in the above are about generating the first payment sub-code, which is actually Figure 4 The reverse operation of each step of obtaining the user identification to be verified in . Figure 6 For the specific execution process of each step, see Figure 4 The steps in the above are performed in reverse order and will not be described in detail here.

[0137] for Figure 5 In the step S52, decryption is performed to obtain the user identification to be verified. Figure 1 The reverse operation of other implementation methods for encrypting and generating the third payment sub-code in step S14 is performed and will not be described in detail here.

[0138] Continue to refer to Figure 5 In the specific implementation of step S53, the first key is used to encrypt the user identification to be verified to obtain the working key to be verified.

[0139] Furthermore, the step S53 may include: using the first key to decrypt the pre-encrypted background working key to obtain the key plaintext; verifying the key plaintext, and if the verification passes, using the key plaintext to encrypt the user identifier to be verified to obtain the working key to be verified.

[0140] For details on determining the working key to be verified and its technical effects, see Figure 1 The specific description of determining the original working key in step S11 is not repeated here.

[0141] Combination Figure 7 , Figure 7 yes Figure 5 A flowchart of a specific implementation method of determining the iteration result of the current round in the iterative operation. Specifically, Figure 5 In the iterative operation, decryption is performed based on the first part of the data of the time factor to be verified in the current round and the first payment subcode to be verified to determine the iteration result of the current round, which may specifically include steps S71 to S72.

[0142] In step S71, the first payment subcode to be verified is decrypted to obtain the first XOR result to be verified in the current round.

[0143] The first payment subcode is generated by encrypting a first XOR result, and the first XOR result is obtained by XORing a first part of data of the payment application identifier and a first part of data of the time factor.

[0144] In short, the first payment sub-code is Figure 2 The scheme of steps S21 to S22 shown is generated.

[0145] In step S72, an XOR process is performed on the first XOR result to be verified in the current round and the first part of data of the time factor to be verified in the current round to obtain the iteration result of the current round.

[0146] It should be pointed out that Figure 7 Steps S71 to S72 shown in FIG. Figure 2The steps S21 to S22 shown in FIG. Figure 7 The solution of decrypting first and then XORing to get the iteration result of the current round is actually Figure 2 The reverse operation of the scheme of first XOR processing and then encryption to generate the first payment subcode in . Figure 7 For the specific execution process of each step, see Figure 2 The steps in the above code are executed in reverse order.

[0147] for Figure 7 Other possible implementations of determining the iteration result of the current round in the iterative operation are correspondingly adopted Figure 1 The inverse operation of other implementation methods of encrypting and generating the first payment subcode in step S12 is performed and will not be described in detail here.

[0148] Combination Figure 8 , Figure 8 yes Figure 5 Flow chart of a specific implementation of step S54 in the embodiment. Specifically, in this implementation, step S54 may include steps S81 to S84.

[0149] In step S81, decryption is performed based on the first payment subcode to be verified and the second payment subcode to be verified to obtain first spliced ​​data to be verified.

[0150] Among them, the second payment subcode is generated by encrypting the first splicing data and the first payment subcode, the first splicing data is obtained by splicing the second data bit and the third data bit in the second part of the data of the conversion data and the payment application identifier, and the conversion data is obtained by data conversion of the first data bit in the second part of the data of the payment application identifier.

[0151] In short, the second payment sub-code is Figure 3 The scheme of steps S31 to S33 shown is generated.

[0152] Further, the step S81 may specifically include: decrypting the second payment subcode to obtain a second XOR result to be verified; performing XOR processing on the second XOR result to be verified and the first part of the data of the first payment subcode to be verified to obtain the first spliced ​​data after conversion to be verified; performing decimal conversion on the first spliced ​​data after conversion to be verified to obtain the first spliced ​​data to be verified.

[0153] Correspondingly, in the further improvement scheme provided for the step S81 above, the second payment subcode is generated by encrypting the second XOR result, the second XOR result is obtained by XOR processing the converted first spliced ​​data and the first part of the data of the first payment subcode, and the converted first spliced ​​data is obtained by hexadecimal conversion of the first spliced ​​data.

[0154] In step S82, the first concatenated data to be verified is parsed to obtain the converted data to be verified and the second data bit and the third data bit in the second part of the data of the payment application identifier to be verified.

[0155] In step S83, the converted data to be verified is subjected to data inverse conversion to obtain the first data bit in the second part of the data of the payment application identifier to be verified.

[0156] In step S84, the first data bit, the second data bit and the third data bit in the second part of the data of the payment application identifier to be verified are concatenated to obtain the second part of the data of the payment application identifier to be verified.

[0157] It should be pointed out that Figure 8 The scheme of steps S81 to S84 for obtaining the second part of the data of the payment application identifier to be verified is actually Figure 3 The steps S31 to S33 shown in FIG. 1 are the inverse operations of the second payment subcode scheme. Figure 8 For the specific execution process of each step, see Figure 3 The steps in the above code are executed in reverse order.

[0158] For other possible implementations of obtaining the second part of the data of the payment application identifier to be verified in step S54, correspondingly adopt Figure 1 The reverse operation of other implementations of generating the second payment subcode in step S13 is performed and will not be described in detail here.

[0159] Fig. 9 1 is a flow chart of a payment code generating device in an embodiment of the present invention. The payment code generating device may include:

[0160] The time factor determination module 91 is used to determine a working key in response to receiving a payment code generation request, and use the working key to encrypt the current time data to obtain a time factor, wherein the working key is obtained by encrypting the user identifier using a preset first key;

[0161] A first encryption module 92, configured to encrypt based on a first portion of data of the payment application identifier and a first portion of data of the time factor to generate a first payment subcode;

[0162] A second encryption module 93, configured to generate a second payment subcode by encrypting based on a second portion of data of the payment application identifier and the first payment subcode, wherein the second portion of data of the payment application identifier is identical to the first portion of data of the payment application identifier at a specified data position;

[0163] A third encryption module 94, configured to encrypt based on at least the user identifier, the first payment subcode and the second payment subcode to generate a third payment subcode;

[0164] The payment code generation module 95 is used to concatenate the first payment subcode, the second payment subcode and the third payment subcode to generate a payment code.

[0165] For the principle, specific implementation and beneficial effects of the payment code generation device, please refer to the previous article and Figures 1 to 4 The relevant description about the payment code generation method shown is not repeated here.

[0166] Fig.10 1 is a flow chart of a payment code verification device in an embodiment of the present invention. The payment code verification device may include:

[0167] The payment code parsing module 101 is used to parse the payment code to be verified in response to receiving the payment code verification request, and obtain the first payment subcode to be verified, the second payment subcode to be verified, and the third payment subcode to be verified, wherein the payment code is based on Figures 1 to 4 Generated by the payment code generation method shown in any embodiment;

[0168] A first decryption module 102, configured to perform decryption based on the first payment subcode to be verified, the second payment subcode to be verified, and the third payment subcode to be verified to obtain a user identification to be verified;

[0169] A working key determination module 103, configured to encrypt the user identification to be verified by using the first key to obtain a working key to be verified;

[0170] A second decryption module 104, configured to perform decryption based on the first payment subcode to be verified and the second payment subcode to be verified to obtain a second portion of data of the payment application identifier to be verified;

[0171] An iteration module 104, configured to perform one or more rounds of iteration operations based on the working key to be verified and the second part of the payment application identifier to be verified;

[0172] The iterative operation includes:

[0173] Starting from the first round of iteration, the working key to be verified is used to encrypt the time data to be encrypted in the current round to obtain the time factor to be verified in the current round;

[0174] Decrypting based on the first part of the time factor to be verified in the current round and the first payment subcode to be verified, to determine the iteration result of the current round;

[0175] If the iteration result of the current round is not the same as the second part of the data of the payment application program identifier to be verified at the specified data position, the time data to be encrypted of the current round is reduced by a preset time length to obtain the time data to be encrypted of the next round, and the iteration operation of the next round is continued;

[0176] Until the iteration result of the current round is the same as the second part of the data of the payment application identifier to be verified at the specified data position, and the current iteration round is less than the preset round, the iteration is stopped and it is confirmed that the payment code to be verified has been verified.

[0177] For the principle, specific implementation and beneficial effects of the payment code verification device, please refer to the previous article and Figures 5 to 8 The relevant description about the payment code generation method shown is not repeated here.

[0178] The embodiment of the present invention further provides a storage medium on which a computer program is stored, and the computer program is executed by a processor. Figures 1 to 4 The steps of the payment code generation method shown in any embodiment, or executing Figures 5 to 8 The steps of the payment code verification method shown in any embodiment. The computer-readable storage medium may include a non-volatile memory or a non-transitory memory, and may also include an optical disk, a mechanical hard disk, a solid-state hard disk, etc.

[0179] Specifically, in the embodiment of the present invention, the processor may be a central processing unit (CPU), and the processor may also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc.

[0180] It should also be understood that the memory in the embodiments of the present application may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. Among them, the non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), which is used as an external cache. By way of example but not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic random access memory (DRAM), synchronous DRAM (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link DRAM (SLDRAM) and direct rambus RAM (DR RAM).

[0181] The embodiment of the present invention further provides a terminal, including a memory and a processor, wherein the memory stores a computer program that can be run on the processor, and the processor executes the above-mentioned Figures 1 to 4The steps of the payment code generation method shown in any embodiment, or executing Figures 5 to 8 The steps of the payment code verification method shown in any embodiment.

[0182] It should be understood that the term "and / or" in this article is only a description of the association relationship of the associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in this article indicates that the associated objects before and after are in an "or" relationship.

[0183] The "plurality" appearing in the embodiments of the present application refers to two or more.

[0184] The first, second, etc. descriptions appearing in the embodiments of the present application are only used for illustration and distinction of the description objects. There is no order, nor do they indicate any special limitation on the number of devices in the embodiments of the present application, and cannot constitute any limitation on the embodiments of the present application.

[0185] It should be noted that the serial numbers of the steps in this embodiment do not limit the execution order of the steps.

[0186] Although the present invention is disclosed as above, the present invention is not limited thereto. Any person skilled in the art can make various changes and modifications without departing from the spirit and scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the scope defined by the claims.

Claims

1. A payment code generation method, characterized in that: include: In response to receiving a payment code generation request, determining a working key, and using the working key to encrypt current time data to obtain a time factor, wherein the working key is obtained by encrypting a user identifier using a preset first key; Encrypting based on the first part of the data of the payment application program identifier and the first part of the data of the time factor to generate a first payment subcode; Encrypting based on the second part of the data of the payment application identifier and the first payment subcode to generate a second payment subcode, wherein the second part of the data of the payment application identifier is identical to the first part of the data of the payment application identifier at a specified data position; Encrypting based on at least the user identification, the first payment subcode and the second payment subcode to generate a third payment subcode; The first payment subcode, the second payment subcode and the third payment subcode are concatenated to generate a payment code.

2. The method according to claim 1, characterized in that The determining of the working key comprises: Determining whether there is a pre-stored working key; If not, the first key is used to decrypt the pre-encrypted background working key to obtain the key plaintext; The key plaintext is verified, and if the verification is successful, the user identification is encrypted using the key plaintext to obtain the working key.

3. The method according to claim 1, characterized in that The first part of data based on the payment application identifier and the first part of data of the time factor are encrypted to generate a first payment subcode, including: Performing an XOR process on the first part of the data of the payment application identifier and the first part of the data of the time factor to obtain a first XOR result; The first XOR result is encrypted to generate the first payment subcode.

4. The method according to claim 1 or 3, characterized in that: The step of encrypting the second part of data based on the payment application identifier and the first payment subcode to generate a second payment subcode includes: Performing data conversion on the first data bit in the second part of the data identified by the payment application program to obtain converted data; splicing the conversion data and the second data bit and the third data bit in the second part of data of the payment application identifier to obtain first spliced ​​data; The second payment subcode is generated by encrypting the first spliced ​​data and the first payment subcode.

5. The method according to claim 4, characterized in that Encrypting the first spliced ​​data and the first payment subcode to generate the second payment subcode includes: Performing hexadecimal conversion on the first spliced ​​data to obtain converted first spliced ​​data; Performing an XOR process on the converted first spliced ​​data and the first part of the data of the first payment subcode to obtain a second XOR result; The second XOR result is encrypted to generate the second payment subcode.

6. The method according to claim 1, characterized in that Encrypting at least based on the user identifier, the first payment subcode, and the second payment subcode to generate a third payment subcode includes: splicing the first payment subcode and the second payment subcode to obtain second spliced ​​data; Performing an XOR process based on the user identifier and the second spliced ​​data to obtain a third XOR result; The third XOR result is encrypted to generate the third payment subcode.

7. The method according to claim 6, characterized in that Performing XOR processing based on the user identifier and the second spliced ​​data to obtain a third XOR result includes: splicing the key version identifier and the first part of the data of the user identifier to obtain third spliced ​​data, wherein the user identifier includes a check digit and the first part of the data; Performing an XOR process on the second spliced ​​data and the third spliced ​​data to obtain the third XOR result.

8. A payment code verification method, characterized in that: include: In response to receiving a payment code verification request, parsing the payment code to be verified to obtain a first payment subcode to be verified, a second payment subcode to be verified, and a third payment subcode to be verified, wherein the payment code is generated based on the payment code generation method according to any one of claims 1 to 7; decrypting the first payment subcode to be verified, the second payment subcode to be verified, and the third payment subcode to be verified to obtain a user identifier to be verified; Using the first key to encrypt the user identification to be verified to obtain a working key to be verified; Decrypting based on the first payment subcode to be verified and the second payment subcode to be verified to obtain the second part of the payment application identifier to be verified; Perform one or more rounds of iterative operations based on the working key to be verified and the second part of the data of the payment application identifier to be verified; The iterative operation includes: Starting from the first round of iteration, the working key to be verified is used to encrypt the time data to be encrypted in the current round to obtain the time factor to be verified in the current round; Decrypting based on the first part of the time factor to be verified in the current round and the first payment subcode to be verified, to determine the iteration result of the current round; If the iteration result of the current round is not the same as the second part of the data of the payment application program identifier to be verified at the specified data position, the time data to be encrypted of the current round is reduced by a preset time length to obtain the time data to be encrypted of the next round, and the iteration operation of the next round is continued; Until the iteration result of the current round is the same as the second part of the data of the payment application identifier to be verified at the specified data position, and the current iteration round is less than the preset round, the iteration is stopped and it is confirmed that the payment code to be verified has been verified.

9. The method according to claim 8, characterized in that If the current iteration round reaches the preset round number, and the iteration result of the current round is still different from the second part of the data of the payment application identifier to be verified at the specified data position, the iteration is stopped and it is confirmed that the payment code to be verified has failed verification.

10. The method according to claim 8, characterized in that The first key is used to encrypt the user identification to be verified to obtain a working key to be verified, including: The first key is used to decrypt the pre-encrypted background working key to obtain the key plaintext; the key plaintext is verified, and if the verification passes, the key plaintext is used to encrypt the user identification to be verified to obtain the working key to be verified.

11. The method according to claim 8, characterized in that Decrypting based on the first part of the time factor to be verified in the current round and the first payment subcode to be verified, determining the iteration result of the current round, including: Decrypting the first payment subcode to be verified to obtain a first XOR result to be verified in the current round; The first XOR result to be verified in the current round and the first part of the data of the time factor to be verified in the current round are XORed to obtain the iteration result of the current round.

12. The method according to claim 8, characterized in that Decryption is performed based on the first payment subcode to be verified and the second payment subcode to be verified to obtain the second part of data of the payment application program identifier to be verified, including: Decryption is performed based on the first payment subcode to be verified and the second payment subcode to be verified to obtain first spliced ​​data to be verified; Parsing the first concatenated data to be verified to obtain the conversion data to be verified and the second data bit and the third data bit in the second part of the data of the payment application program identifier to be verified; Performing data inverse conversion on the conversion data to be verified to obtain the first data bit in the second part of the data of the payment application identifier to be verified; The first data bit, the second data bit and the third data bit in the second part of the data of the payment application identifier to be verified are concatenated to obtain the second part of the data of the payment application identifier to be verified.

13. The method according to claim 12, characterized in that Decryption is performed based on the first payment subcode to be verified and the second payment subcode to be verified to obtain first spliced ​​data to be verified, including: Decrypting the second payment subcode to obtain a second XOR result to be verified; Performing XOR processing on the second XOR result to be verified and the first part of the data of the first payment subcode to be verified to obtain the first concatenated data after conversion to be verified; Performing a decimal conversion on the converted first spliced ​​data to be verified to obtain the first spliced ​​data to be verified.

14. The method according to claim 8, characterized in that Decryption is performed based on the first payment subcode to be verified, the second payment subcode to be verified, and the third payment subcode to be verified to obtain the user identification to be verified, including: Decrypting the third payment subcode to be verified to obtain a third XOR result to be verified; splicing the first payment subcode to be verified and the second payment subcode to be verified to obtain second spliced ​​data to be verified; XOR processing is performed based on the third XOR result to be verified and the second spliced ​​data to be verified to obtain the user identification to be verified.

15. The method according to claim 14, characterized in that Performing XOR processing based on the third XOR result to be verified and the second spliced ​​data to be verified to obtain the user identification to be verified, including: Performing XOR processing on the third XOR result to be verified and the second spliced ​​data to be verified to obtain third spliced ​​data to be verified; The third spliced ​​data to be verified is parsed to obtain the first part data of the user identifier to be verified, wherein the user identifier to be verified includes a check digit and the first part data; based on the first part data of the user identifier to be verified, the check digit of the user identifier to be verified is determined, and the check digit of the user identifier to be verified and the first part data of the user identifier to be verified are spliced ​​to obtain the user identifier to be verified.

16. A payment code generating device, characterized in that: include: A time factor determination module, configured to determine a working key in response to receiving a payment code generation request, and encrypt current time data using the working key to obtain a time factor, wherein the working key is obtained by encrypting a user identifier using a preset first key; A first encryption module, used for encrypting based on a first portion of data of the payment application identifier and a first portion of data of the time factor to generate a first payment subcode; a second encryption module, configured to encrypt based on a second portion of data of the payment application identifier and the first payment subcode to generate a second payment subcode, wherein the second portion of data of the payment application identifier is identical to the first portion of data of the payment application identifier at a specified data position; A third encryption module, configured to encrypt based on at least the user identifier, the first payment subcode and the second payment subcode to generate a third payment subcode; The payment code generation module is used to splice the first payment subcode, the second payment subcode and the third payment subcode to generate a payment code.

17. A payment code verification device, characterized in that: include: a payment code parsing module, configured to, in response to receiving a payment code verification request, parse the payment code to be verified to obtain a first payment subcode to be verified, a second payment subcode to be verified, and a third payment subcode to be verified, wherein the payment code is generated based on the payment code generation method according to any one of claims 1 to 7; A first decryption module, used for decrypting based on the first payment subcode to be verified, the second payment subcode to be verified, and the third payment subcode to be verified to obtain a user identification to be verified; A working key determination module, used to encrypt the user identification to be verified by using the first key to obtain the working key to be verified; A second decryption module, configured to perform decryption based on the first payment subcode to be verified and the second payment subcode to be verified to obtain a second portion of data of the payment application identifier to be verified; An iteration module, configured to perform one or more rounds of iteration operations based on the working key to be verified and the second part of data of the payment application identifier to be verified; The iterative operation includes: Starting from the first round of iteration, the working key to be verified is used to encrypt the time data to be encrypted in the current round to obtain the time factor to be verified in the current round; Decrypting based on the first part of the time factor to be verified in the current round and the first payment subcode to be verified, to determine the iteration result of the current round; If the iteration result of the current round is not the same as the second part of the data of the payment application program identifier to be verified at the specified data position, the time data to be encrypted of the current round is reduced by a preset time length to obtain the time data to be encrypted of the next round, and the iteration operation of the next round is continued; Until the iteration result of the current round is the same as the second part of the data of the payment application identifier to be verified at the specified data position, and the current iteration round is less than the preset round, the iteration is stopped and it is confirmed that the payment code to be verified has been verified.

18. A storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the payment code generation method according to any one of claims 1 to 7 are executed, or the steps of the payment code verification method according to any one of claims 8 to 15 are executed.

19. A terminal comprising a memory and a processor, wherein the memory stores a computer program that can be run on the processor, characterized in that: When the processor runs the computer program, it executes the steps of the payment code generation method according to any one of claims 1 to 7, or executes the steps of the payment code verification method according to any one of claims 8 to 15.

Images