Methods for generating aggregation codes

Abstract

The present invention relates to a method for generating an aggregation code, comprising: defining a data element based on an application transaction count, an unpredictable number, and an application ciphertext to be assigned, wherein the data element adopts a first general data format; encrypting a hash value of a numerical combination of assigned items of the data element to obtain an encryption result; assigning a value to the application ciphertext with the encryption result; and generating an aggregation code based on the data element assigned with the application ciphertext. The method can be used to generate an aggregation code or a QR code that is universal in multiple countries or regions and across industries, which can not only ensure the security of electronic payment, but also facilitate users' travel and help improve the user experience.

Description

Technical Field

[0001] The present invention relates to the field of electronic payment technology, and more specifically, to a method for generating an aggregation code. Background Art

[0002] QR code technology is widely used in the field of electronic payment. However, in the existing technology, there are still some problems in the use of QR code, including:

[0003] 1. Some QR code-based App payment solutions are only applicable to the App itself and can be used in merchants associated with the App at most, but do not support cross-APP payment based on the same QR code.

[0004] 2. Different industries use separate industry QR codes. For example, public transportation facilities will use unique industry QR codes and corresponding payment apps. When switching from shopping to public transportation, users need to switch QR codes or download new apps, and cannot directly use the original QR code for cross-industry use. Frequent switching of apps will cause inconvenience to users.

[0005] 3. QR codes are not internationally compatible. If the QR code standard is customized by an enterprise, it will conflict with the definitions of other enterprises on the global Internet.

[0006] Therefore, the existing QR code technology is still subject to many restrictions such as App, industry and region when used. Summary of the invention

[0007] According to one aspect of the present invention, a method for generating a universal two-dimensional code is provided.

[0008] The present invention discloses a method for generating an aggregation code, wherein the aggregation code is used by a payment application on an intelligent terminal to realize electronic payment. The method comprises: defining a data element based on an application transaction count, an unpredictable number and an application ciphertext to be assigned, wherein the data element adopts a first universal data format; encrypting a hash value of a numerical combination of assigned items of the data element to obtain an encryption result; assigning a value to the application ciphertext with the encryption result; and generating an aggregation code based on the data element assigned with the application ciphertext.

[0009] According to another aspect of the present invention, a method for generating and verifying a universal two-dimensional code is provided.

[0010] To this end, the present invention discloses a method for a payment application on a smart terminal to apply for an aggregation code online, comprising: the payment application applies to the payment application background to generate a payment QR code; the payment application generates an aggregation code based on a character string received from the payment application background; wherein the payment application background is configured to: define a data element based on an application transaction count, an unpredictable number and an application ciphertext, wherein the data element adopts a first universal data format; encrypt a hash value of a numerical combination of assigned items of the data element to obtain an encryption result; assign an application ciphertext with the encryption result; and convert the data element assigned with the application ciphertext into a character string.

[0011] The present invention also discloses a method for offline generation of aggregation codes by a payment application on a smart terminal, comprising: the payment application generates an aggregation code by adopting the above-mentioned method for generating aggregation codes.

[0012] The present invention further discloses a method for verifying an aggregation code via a transaction terminal over the Internet, comprising: the transaction terminal scans the aggregation code to form a terminal message; wherein the terminal message adopts a first general data format and at least includes an application ciphertext, an application transaction count and an unpredictable number; the transaction terminal transmits an authorization message generated based on the terminal message to a payment application background; wherein the authorization message includes the application ciphertext, the application transaction count and the unpredictable number; the transaction terminal obtains a verification result of the aggregation code from the payment application background; wherein the verification result is generated by the payment application background based on a comparison of a first hash value and a second hash value, the first hash value is obtained by decrypting the application ciphertext by the payment application background, and the second hash value is obtained by performing a hash operation on a numerical combination of the application transaction count and the unpredictable number by the payment application background.

[0013] The present invention also discloses a method for offline verification of an aggregation code by a transaction terminal, comprising: the transaction terminal scans the aggregation code to form payment data, wherein the payment data adopts a first universal data format and at least includes an application ciphertext, an application transaction count and an unpredictable number; the transaction terminal generates a first hash value and a second hash value based on the payment data; the transaction terminal generates a verification result based on a comparison between the first hash value and the second hash value; wherein the first hash value is obtained by decrypting the application ciphertext by the transaction terminal, and the second hash value is obtained by performing a hash operation on a numerical combination of the application transaction count and the unpredictable number by the transaction terminal.

[0014] The method for generating an aggregation code provided by the present invention can be used to generate an aggregation code or a two-dimensional code that is universal in multiple countries or regions and across industries, which can not only ensure the security of electronic payment, but also facilitate user travel and improve the user experience. In addition, whether online or offline, the aggregation code application method and verification method based on the method can be successfully implemented, further expanding the application occasions of such an aggregation code. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 It is a flowchart of a method for generating an aggregation code provided by an embodiment of the present invention.

[0016] Figure 2 It is a flowchart of a method for verifying an aggregation code through networking of a transaction terminal provided by another embodiment of the present invention.

[0017] Figure 3 It is a flowchart of a method for offline verification of aggregation codes by a transaction terminal provided by another embodiment of the present invention. DETAILED DESCRIPTION

[0018] Specific details are provided in the following description to provide a thorough understanding of the present invention. However, it will be clear to those skilled in the art that embodiments of the present invention may be implemented without these specific details. In the present invention, specific numerical references may be made, such as "first element", "first step", "second device", etc. However, specific numerical references should not be understood to be subject to their literal order, but should be understood to be different from "first element" and "second element".

[0019] The specific details presented in the present invention are merely exemplary and may be varied while still falling within the spirit and scope of the present invention.The term "coupled" is defined to mean connected directly to a component or indirectly connected to a component via another component.

[0020] Preferred embodiments of methods, systems and devices suitable for implementing the present invention are described below with reference to the accompanying drawings. Although each embodiment is described for a single combination of elements, it should be understood that the present invention includes all possible combinations of disclosed elements. Therefore, if one embodiment includes elements (steps) A, B and C, and a second embodiment includes elements (steps) B and D, the present invention should be considered to include other remaining combinations of elements (steps) A, B, C or D, even if not explicitly disclosed.

[0021] like Figure 1 As shown, an embodiment of the present invention provides a method for generating an aggregation code, which includes main steps S10-S12-S14-S16. The method can be executed by a payment application App on a smart terminal held by a user, or by the background of the payment application App.

[0022] In step S10, a data element in the first general data format is defined, and the data element includes at least three data items: application transaction count, unpredictable number, and application ciphertext. Among them, the application transaction count and the unpredictable number can be assigned values ​​in the definition stage of step S10. The application ciphertext is assigned in the subsequent step S14. The data element may further include other data items, such as the file name (AID) of the application definition file (ADF) of the payment application, two-track data, and the bank card serial number used by the user for payment. The data element may also include user-defined data items, such as the credit of the payment account and the expiration time of the aggregation code.

[0023] The first general data format may be the QR Code Specification for Payment Systems: Consumer Presented Mode (EMV CPQRS) of the EMV organization. This specification is an internationally accepted industry specification, in which several data items are defined for the data element, and each data item may have a different length and a fixed format. EMV CPQRS does not specifically limit the data source and algorithm of the data item. As an example, the data element defined in the present invention adopts the EMV CPQRS industry specification, in which the application transaction count occupies 2 bytes, the unpredictable number occupies 4 bytes, and the application ciphertext occupies a variable number of bytes. The application transaction count and the unpredictable number are used as dynamic values, in which the application transaction count increases with each transaction, and the unpredictable number can be generated by a random number algorithm, and they can be assigned in step S10. Other data items in the data element can also be assigned at this stage according to the relevant information mastered by the subject (user terminal or payment application background) executing step S10, and the application ciphertext data item is left to be assigned in step S14.

[0024] In step S12, a hash value is first calculated for the numerical combination of the assigned items of the data element, and then the hash value is encrypted to obtain an encrypted result. After the hash operation, an output hash value of a fixed length can be obtained, which is independent of the number of the assigned items of the data element or its length, and the hash value is encrypted to obtain an encrypted result. As an example, the assigned items include a 2-byte application transaction count and a 4-byte unpredictable number, wherein the value of the application transaction count is 56 and the value of the unpredictable number is 61 1A, then the hash value of the numerical combination of 56 61 1A is calculated. As other examples, the data item adopts the TLV (identifier, length, value) format, and the value of the first data item (such as the application transaction count) including the identifier, length and value and the value of the second data item (such as the unpredictable number) arranged in a similar structure can be combined to perform a hash value calculation. As some other examples, the assigned data items include the file name of the application definition file, the bank card serial number, and the public key certificate of the card issuer in addition to the application transaction count and the unpredictable number. The hash calculation is performed on the numerical combination obtained by connecting the numerical values ​​of the total of 5 data items. After the hash calculation, the hash value is encrypted.

[0025] In some embodiments of the present invention, the hash value can be encrypted using the private key of the issuing institution (also referred to as the App private key) corresponding to the public key certificate of the bank card issuing institution (also referred to as the App public key certificate) according to the specified encryption algorithm. Specifically, the App public key, private key and CA public key index can be generated at the issuing institution end and provided by the payment network to the payment application on the smart terminal held by the user. At the same time, the payment network uses the CA private key to sign the App public key according to the agreed algorithm, generates the App public key certificate and provides it to the payment application. The payment application stores the App private key, CA public key index and App public key certificate in the secure storage area of ​​the payment application. Accordingly, the data element may include data items related to encryption or digital signature for storing such as App public key certificate, CA public key index and algorithm identifier of the encryption algorithm. Encryption can use any appropriate algorithm in the prior art, and the identifier of the encryption algorithm can be stored in the encryption algorithm identifier data item of the data element, which can be assigned in step S10 or step S12. As a specific example, the SHA-256 algorithm may be used when calculating the hash value, and the Elliptic Curve Digital Signature (ECDSA) algorithm may be used when encrypting the hash value.

[0026] In the present invention, the payment network generally includes a card issuing institution end, a bank end, a merchant terminal and an intelligent terminal and a payment application backend end.

[0027] In step S14, the encryption result of the data item is used to assign a value to the application ciphertext data item of the data element. The application ciphertext embodies the characteristics of multiple assigned data items and also embodies the characteristics of the encryption algorithm. The application ciphertext can be uniquely reproduced according to multiple assigned data items and the encryption algorithm identification data item. Therefore, based on this principle, the generation and verification of the same aggregation code can be achieved at different ends of the payment network (for example, smart terminals and merchant terminals), thereby achieving the security and convenience of electronic payment. Generally speaking, before step S14, most of the data items of the data element have been assigned. After step S14, the assignment of the application ciphertext data items can be completed.

[0028] The aggregation code is generated in step S16. When the customized data item includes the expiration time (item) of the aggregation code, the expiration time (item) may also be assigned a value in step S16. The aggregation code adopts the style of a two-dimensional code, which is displayed by the user's smart terminal and scanned by the merchant terminal to realize electronic payment.

[0029] In some embodiments of the present invention, to generate an aggregation code, the data element that completes the application ciphertext data item assignment is first converted into a string in BASE 64 format, and then the string is converted into an aggregation code in the form of a two-dimensional code. An example of a string in BASE 64 format is shown below:

[0030] hQVDUFYwMWEaTwegAAAAVVVVVw8SNFZ4kBI0WNGRIgESNF8

[0031] The generated aggregation code incorporates a variety of information, and the corresponding data elements conform to the first general data format. Furthermore, such an aggregation code has good versatility and is not limited to the custom standards of a certain enterprise or industry. With such an aggregation code generation method, the user's smartphone can be used for ordinary merchant transactions and industries such as subway transportation at the same time, without the user having to switch applications or QR codes.

[0032] According to some embodiments of the present invention, a method for a payment application on a smart terminal to apply for an aggregation code online is implemented, the method comprising step 1, the payment application applies to the payment application backend to generate a payment QR code; step 2, the payment application receives the generated aggregation code from the payment application backend. The aggregation code is generated by the payment application backend using the above-mentioned method for generating an aggregation code.

[0033] Specifically, first, the payment application (hereinafter referred to as App) makes an online request to the payment application backend (hereinafter referred to as App backend) to generate a payment QR code. In response, the App backend performs the following operations: defines a data element in the EMV CPQRS data format based on the application transaction count, unpredictable number and application ciphertext; performs hash value calculation and encryption operation on the numerical combination of the assigned items of the data element, and assigns the application ciphertext with the encrypted result; and then converts the data element assigned with the application ciphertext into a string in BASE 64 format. After receiving the string from the App backend, the App converts the string into a QR code according to the ISO 18004 specification. Before or at the same time as assigning the application ciphertext, the App backend can fill the App public key certificate into the card issuer public key certificate data item of the data element, and fill the CA public key index into the CA public key index data item.

[0034] When connecting to the Internet (especially for the first time), the App can obtain and store the application definition file name corresponding to the App, the App private key corresponding to the file name, the App public key certificate, and the CA public key index. This information can be used to define data elements, generate aggregation codes, or update the information required to generate aggregation codes.

[0035] According to some embodiments of the present invention, the payment application (App) on the user's smart terminal can also generate an aggregation code offline (not connected to the Internet). As an example, in the previous networking process, the App can obtain information such as the App private key, the App public key certificate and the CA public key index. Alternatively, this information can come from the historical transaction data saved on the App side. In addition, the App can also generate application transaction counts and unpredictable numbers offline, so the payment application can generate the aggregation code required for payment according to the above steps S10-S12-S14-S16, and the merchant terminal can still realize electronic payment after scanning the aggregation code. Specifically, the App directly generates the scanned aggregation code based on the EMV QRCPS specification, in which the App public key certificate is filled in the card issuer public key certificate data item, and the CA public key index is filled in the CA public key index data item. The App then converts the string into a QR code for display according to the ISO 18004 specification.

[0036] Since smart terminals can generate widely applicable aggregate codes offline, electronic payment will be applicable to open-loop networks. Even if the smart terminal held by the user is temporarily unable to connect to the Internet, the user can still carry out activities such as shopping and public transportation, which improves the user experience.

[0037] In some embodiments of the present invention, a machine-readable storage medium is provided, on which a batch of computer executable instructions are stored, and when these computer executable instructions are executed by a processor, the above-mentioned method for generating an aggregation code can be implemented. In other embodiments, a computer device is provided, which includes a memory, a processor, and a computer program stored in the memory and executed by the processor, wherein the processor can implement steps S10-S12-S14-S16 of the above-mentioned method for generating an aggregation code when executing the computer program.

[0038] Figure 2 A method for verifying an aggregation code by a transaction terminal (merchant terminal) via networking is shown, and the method includes steps S20-S22-S24.

[0039] Step S20: The transaction terminal scans the aggregation code to form a terminal message. The aggregation code is presented by the user terminal to the transaction terminal, and the transaction terminal can form a terminal message after scanning and identifying it. The terminal message adopts the first universal data format and includes at least three data items: application ciphertext, application transaction count, and unpredictable number.

[0040] Step S22: The transaction terminal transmits the terminal message to the payment application backend.

[0041] Step S24: The transaction terminal obtains the verification result from the payment application background. The verification result is generated by the payment application background based on the comparison of the first hash value and the second hash value. The first hash value is obtained by the payment application background decrypting the application ciphertext, and the second hash value is obtained by the payment application background performing a hash operation on the numerical combination of the application transaction count and the unpredictable number.

[0042] Regarding the method of verifying the aggregation code online, a specific example is provided below, which includes the following steps.

[0043] 1) The transaction terminal scans the aggregation code presented by the user terminal to obtain the aggregation code data, decodes it using BASE 64, and constructs a terminal message that complies with the EMV CPQRS specification.

[0044] 2) The transaction terminal reads the application definition file name (AID) in the message to determine the payment network for routing; reads the track 2 data and converts it into the 35 field data of the ISO 8583 specification authorization message; reads the application specific transparent template data, assembles the terminal data, and puts it into the 55 field of the ISO 8583 specification authorization message. The transaction terminal sends the authorization message to the payment application backend in the payment network.

[0045] 3) The payment application backend restores the App ID from the authorization message, retrieves the public and private key pair assigned to the App from the database, and uses the App public key to decrypt the application ciphertext to restore the hash value (the first hash value).

[0046] 4) The payment application background extracts two dynamic data, application transaction count and unpredictable number, from the authorization message and other data items of the authorization message that comply with the ISO 8583 specification, and converts them into the TLV format specified in the EMV specification in sequence, concatenates them into data elements, denoted as S, and uses the agreed algorithm to calculate the hash value of S (the second hash value).

[0047] 5) Compare the hash values ​​in 3) and 4). If they are equal, the aggregation code verification succeeds. If they are not equal, the verification fails.

[0048] It should be understood that the above method can be implemented regardless of whether the transaction terminal (merchant terminal) supports EMV migration technology. Specifically, as long as both the transaction terminal and the payment application backend support or adopt a unified data format specification, the message or data conversion can be implemented in accordance with this specification, and then the first hash value obtained by decryption from the aggregation code can be compared with the second hash value generated based on the application transaction count and the unpredictable number to determine the result of the aggregation code verification.

[0049] Figure 3 A method for offline verification of an aggregation code by a transaction terminal is shown. The method includes steps S31-S33-S35. As an example, in step S31, the transaction terminal scans the aggregation code to form payment data, wherein the payment data adopts a first universal data format (such as the EMV CPQRS specification) and includes at least an application ciphertext, an application transaction count, and an unpredictable number. In step S33, the transaction terminal generates a first hash value and a second hash value based on the payment data. In step S35, the transaction terminal generates a verification result based on a comparison of the first hash value and the second hash value. The first hash value is obtained by decrypting the application ciphertext by the transaction terminal, and the second hash value is obtained by performing a hash operation on a numerical combination of the application transaction count and the unpredictable number by the transaction terminal.

[0050] When the transaction terminal scans the aggregation code, the expiration time information of the aggregation code can be determined. If it can be determined that the aggregation code is invalid, the transaction terminal can reject the transaction.

[0051] A specific example of the offline verification method is provided below, and the method includes the following steps.

[0052] 1) The transaction terminal scans the QR code to obtain the QR code data, and decodes it using BASE64 according to the requirements of the EMV CPQRS specification to form payment data.

[0053] 2) The transaction terminal refers to traditional POS transactions, reads the application definition file name (AID), CA public key index from the payment data, and searches for the CA public key. The transaction terminal then reads the public key certificate of the card issuer, decrypts it using the corresponding CA public key and its agreed algorithm, and recovers the App public key.

[0054] 3) The transaction terminal uses the App public key and the asymmetric algorithm indicated by the encryption algorithm identifier to decrypt the application ciphertext and restore the hash value (first hash value).

[0055] 4) The transaction terminal converts the two dynamic data, application transaction count and unpredictable number, and / or other data in the payment data into the TLV format specified in the EMV specification in sequence, concatenates them into a data element, denoted as S, and uses the agreed algorithm to calculate the hash value of S (the second hash value).

[0056] 5) Compare the hash values ​​in 3) and 4). If they are equal, the aggregation code is successfully verified.

[0057] According to this offline verification method, the transaction terminal can perform certain transaction operations, such as opening the gate, without being connected to the Internet (such as network failure or poor wireless signal), and then deduct money from the payment application when it is connected to the Internet. This method can facilitate users' travel and improve the efficiency of opening the gate.

[0058] In addition, the merchant terminal does not need to establish commercial and technical connections with various apps, but only needs to connect to the payment network when needed, and achieve one-point access on the merchant side to achieve networking and interoperability of QR code (aggregation code) payment of various apps, thus reducing hardware resources, network resources and transaction costs. This online and offline parallel solution can be applied to multiple industries, such as the transportation industry (which needs to support offline code application and verification), and also ensures the payment function across apps, which is conducive to improving the user experience.

[0059] It will be appreciated by those skilled in the art that the various illustrative logic blocks, modules, circuits and algorithmic steps described in conjunction with the aspects disclosed herein can be implemented as electronic hardware, computer software or a combination of the two. In order to show the interchangeability between hardware and software, various illustrative components, blocks, modules, circuits and steps are generally described above according to their functionality. Whether such functionality is implemented as hardware or software will depend on the specific application and the design restrictions imposed on the overall system. The technician can implement the described functionality in a varying manner for a specific specific application, but such implementation decision should not be understood as causing a departure from the scope of the invention.

[0060] The above description is only for the preferred embodiment of the present invention and is not intended to limit the protection scope of the present invention. Those skilled in the art may make various modified designs without departing from the concept of the present invention and the accompanying claims.

Claims

1. A method for generating an aggregation code, wherein the aggregation code is used by a payment application on a smart terminal to implement electronic payment, the method comprising: Defining a data element based on the application transaction count, the unpredictable number and the application ciphertext to be assigned, wherein the data element adopts a first universal data format; Encrypting the hash value of the numerical combination of the assigned items of the data element to obtain an encryption result; Assigning a value to the application ciphertext using the encryption result; and generating the aggregation code based on the data element valued by applying the ciphertext, The step of generating the aggregation code based on the data element assigned with the application ciphertext comprises: Convert the data element assigned with the application ciphertext into a string in BASE 64 format; Convert the string into the aggregation code in the form of a QR code, The data elements further include: the file name of the application definition file of the payment application, track 2 data, and the serial number of the bank card used by the user for payment.

2. The method according to claim 1, characterized in that Encrypting the hash value includes: The hash value is encrypted according to an encryption algorithm using the card issuing institution's private key corresponding to the card issuing institution's public key certificate.

3. The method according to claim 2, characterized in that The data element also includes the card issuer's public key certificate signed using the CA private key.

4. The method according to claim 3, characterized in that The data element also includes a CA public key index corresponding to the CA private key.

5. The method according to claim 2, characterized in that: The data element also includes an algorithm identifier of the encryption algorithm.

6. The method according to claim 1, characterized in that The data element also includes an application definition file name for determining the payment application.

7. The method according to claim 1, characterized in that The data element also includes additional information, and the additional information includes at least one of the following: Payment account credit investigation; expiration date of the aggregation code.

8. A method for a payment application on a smart terminal to apply for an aggregation code through networking, comprising: The payment application applies to the payment application backend to generate a payment QR code; The payment application generates an aggregation code in the form of a QR code based on a string in a BASE 64 format received from the payment application backend; Wherein, the payment application backend is configured as follows: Defining a data element based on the application transaction count, the unpredictable number and the application ciphertext, wherein the data element adopts a first universal data format; Encrypting the hash value of the numerical combination of the assigned items of the data element to obtain an encryption result; Assigning a value to the application ciphertext using the encryption result; and Convert the data element assigned with the application ciphertext into a string in BASE 64 format. The data elements further include: the file name of the application definition file of the payment application, track 2 data, and the serial number of the bank card used by the user for payment.

9. The method according to claim 8, further comprising an online registration step, wherein: When connected to the network, the payment application obtains and stores the application definition file name of the payment application and the payment application private key, payment application public key certificate and CA public key index corresponding to the application definition file name.

10. A method for generating an aggregation code offline by a payment application on a smart terminal, comprising: The payment application generates the aggregation code using the method as claimed in claim 1.

11. The method according to claim 10, characterized in that The data elements based on which the aggregation code is generated include the card issuer's public key certificate and the CA public key index; wherein the card issuer's public key certificate and the CA public key index are assigned by the payment application based on previously obtained historical transaction data.

12. A machine-readable storage medium having a batch of computer-executable instructions stored thereon, wherein when the computer-executable instructions are executed by a processor, the method according to any one of claims 1 to 7 is implemented.

13. A computer device comprising a memory, a processor, and a computer program stored in the memory and executed by the processor, wherein: When executing the computer program, the processor implements the steps of the method according to any one of claims 1 to 7.

14. A computer program product, comprising computer executable instructions, which, when executed, implement the method according to any one of claims 1 to 7.

Images