A transaction processing method and apparatus

Abstract

This invention relates to a transaction processing method and apparatus. The method includes: a payment device acquiring authorization factor information corresponding to a card used for payment; the authorization factor information is obtained based on an authorization factor generated by an authorization factor generating entity; the authorization factor is generated by the authorization factor generating entity after the card's personal identification number (PIN) has been verified by the card issuing institution; the payment device sending the authorization factor information to a receiving device; the receiving device acquiring card information and sending the card information and authorization factor information to the authorization factor generating entity; and the authorization factor generating entity verifying the authorization factor information and card information to obtain a first verification result. Thus, users do not need to enter their card's PIN on the receiving device, eliminating security risks associated with the receiving device; the receiving device can also verify whether the payment device knows the card's PIN and whether it has payment authorization for the card, thereby ensuring the security of the entire transaction process.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of financial technology, and in particular to a transaction processing method, apparatus, computing device and computer-readable storage medium. Background Technology

[0002] Generally, important cards are assigned a Personal Identification Number (PIN), commonly known as a password. For example, debit cards, credit cards, and membership cards used for purchases all have PINs. In one possible scenario, a user hands their debit card to a merchant for payment. The merchant uses a point-of-sale (POS) terminal to read the card information, typically including the card number. The user then enters the debit card's PIN on the POS machine, completing the transaction. Because the PIN is crucial security information for the cardholder, its leakage can seriously jeopardize the card account's security. Traditional POS machines employ stringent technologies to prevent PIN leakage during user input, such as customized secure operating systems, physical tamper protection, screen privacy protection, and robust key protection mechanisms.

[0003] With the development of technology, new types of open terminals have emerged that can replace traditional POS machines for payment collection. These new open terminals are popular with users due to their portability and open ecosystem.

[0004] However, these new open terminals, due to their more open system environment and non-customized devices, make it difficult to guarantee transaction security and gain user trust. For example, the most typical new open terminal is the smartphone, which can replace traditional POS terminals for payment collection, offering greater convenience for merchants. However, the following problems exist: 1. The operating environment of the merchant's smartphone cannot be guaranteed to be secure. If malicious programs are installed on the merchant's phone, the PIN can be hijacked when the user enters it; 2. Even if the merchant's smartphone has a secure operating environment, users are unlikely to accept entering their debit card PIN on the merchant's smartphone; 3. Because smartphones lack special anti-spy design, there is a risk of PIN being viewed and leaked by others during the user's PIN entry process; 4. Some visually impaired individuals can only operate their own specially designed terminals and cannot operate the merchant's terminals, thus making it impossible for them to enter their PIN. Summary of the Invention

[0005] This invention provides a transaction processing method to improve the security of offline transactions.

[0006] In a first aspect, embodiments of the present invention provide a transaction processing method, including:

[0007] The payment device obtains the authorization factor information corresponding to the card used for payment; the authorization factor information is obtained based on the authorization factor generated by the authorization factor generating entity; the authorization factor is generated by the authorization factor generating entity after the card's personal identification code (PIN) is verified by the card issuing institution; the PIN is provided by the payment device to the authorization factor generating entity when registering the card with a token;

[0008] The payment device sends the authorization factor information to the receiving device; the receiving device obtains the card information and sends the card information and the authorization factor information to the authorization factor generating entity; the authorization factor generating entity verifies the authorization factor information and the card information to obtain a first verification result, so that the receiving device completes the payment task based on the first verification result.

[0009] Since the authorization factor information is derived from the authorization factor generated by the authorization factor generating entity, which generates the authorization factor after the card's PIN has been verified by the issuing institution, the issuing institution can guarantee that the PIN provided by the payment device during token registration is correct. Then, the authorization factor generating entity generates an authorization factor for the card. This is equivalent to the issuing institution verifying the PIN provided by the payment device. The payment device obtains the authorization factor information corresponding to the card used for payment and sends it to the receiving device. The receiving device cannot directly obtain the card's PIN, nor can it decrypt the encrypted authorization factor, ensuring the security of the card's PIN. The receiving device sends the card information and the authorization factor information to a trusted authorization factor generating entity. The authorization factor generating entity verifies the card information and the authorization factor information and sends the first verification result to the receiving device. Thus, the user does not need to enter their card's PIN on the receiving device, eliminating concerns about security risks; the receiving device can also verify whether the payment device knows the card's PIN and whether it has payment authorization for the card, thereby ensuring the security of the entire transaction process.

[0010] In some embodiments, it also includes:

[0011] In response to a user's token registration request for the card, the payment device sends the token registration request for the card to the authorization factor generation entity; the token registration request includes the PIN encrypted of the card; the PIN encrypted is generated based on the PIN;

[0012] The payment device receives the authorization factor sent by the authorization factor generating entity and obtains the authorization factor information based on the authorization factor; the authorization factor is generated by the authorization factor generating entity after the PIN is verified by the card issuing institution.

[0013] Users can register a token for their card on the payment device. When the receiving device initiates a payment request, the user can find the token corresponding to the card on the payment device and send the authorization factor information carried by the registered token to the receiving device, making the transaction faster and more time-saving. Through the user's token registration request, the payment device obtains the card information and the card's PIN. The payment device encrypts the PIN to obtain PIN ciphertext. Since the payment device's operating environment is secure, the PIN is secure. The payment device sends the PIN ciphertext to the authorization factor generation entity, which generates the authorization factor after the card's PIN has been verified by the card issuer. Because the card issuer verifies the PIN, it ensures that the PIN provided by the payment device during token registration is correct. The authorization factor is generated by a trusted third party—the authorization factor generation entity—facilitating subsequent verification by the receiving device and ensuring the security of the entire transaction process.

[0014] In some embodiments, the token registration request may also include device information of the payment device; the authorization factor ciphertext is generated by the authorization factor generating entity after the PIN is verified by the card issuer and the device information is verified by the device manufacturer of the payment device.

[0015] This verification of device information ensures that the operating environment of the payment device is secure.

[0016] In some embodiments, it also includes:

[0017] In response to a request to set an authorization policy for the card, the payment device sends the setting request to the authorization factor generating entity; the authorization policy is used to characterize the payment device's usage rights over the authorization factor.

[0018] In this way, each authorized factor will have a pre-set usage permission, ensuring that the authorized factor will not be used without restriction, thus improving the security of transactions.

[0019] In some embodiments, before the payment device obtains the authorization factor information corresponding to the card used for payment, the method further includes:

[0020] The payment device receives a payment request sent by the receiving device, and the payment request carries card information of the card used for payment;

[0021] The payment device obtains the authorization factor information corresponding to the card used for payment, including:

[0022] The payment device obtains authorization factor information that matches the card information based on the card information.

[0023] In some embodiments, the authorization factor information corresponds to multiple cards.

[0024] Setting the authorization factor information of multiple cards to the same value makes the process of generating authorization factor information faster and more efficient, and improves the user experience.

[0025] Secondly, embodiments of the present invention also provide a transaction processing method, comprising:

[0026] The payment device initiates a payment request for any card, obtains the card information, and sends the card information and the card's authorization factor information obtained through the payment device to the authorization factor generation entity. The authorization factor generation entity is used to decrypt the authorization factor information to obtain the authorization factor, verify whether the authorization factor matches the card information, and obtain a first verification result.

[0027] The payment collection device completes its payment collection task based on the first verification result sent by the authorization factor generation entity.

[0028] In some embodiments, the payment device obtains the card information and the authorization factor information in the following ways:

[0029] The payment device obtains the card information via Near Field Communication (NFC) technology to generate the payment request, and obtains the authorization factor information via NFC technology based on the payment request; or

[0030] The payment device obtains the card information and the authorization factor information through NFC technology.

[0031] Thirdly, embodiments of the present invention also provide a transaction processing method, including:

[0032] The authorization factor generating entity receives card information and authorization factor information for any card sent by the payment receiving device;

[0033] The authorization factor generating entity decrypts the authorization factor information to obtain the authorization factor;

[0034] The authorization factor generating entity verifies whether the authorization factor matches the card information and obtains a first verification result;

[0035] The authorization factor generating entity sends the first verification result to the payment receiving device.

[0036] In some embodiments, it also includes:

[0037] The authorization factor generating entity receives a token registration request for the card, the token registration request including the PIN encrypted of the card; the PIN encrypted is generated based on the PIN;

[0038] The authorization factor generating entity generates the authorization factor for the card after the PIN is verified by the card issuing institution;

[0039] The authorization factor generating entity sends the authorization factor to the payment device.

[0040] In some embodiments, after the authorization factor generating entity decrypts the authorization factor information to obtain the authorization factor and before obtaining the first verification result, the method further includes:

[0041] The authorization factor generating entity obtains the authorization strategy of the authorization factor based on the authorization factor; the authorization strategy is used to characterize the payment device's usage rights of the authorization factor;

[0042] The payment device is determined to have permission to use the authorization factor based on the authorization policy.

[0043] After obtaining an authorization factor each time, the entity generating the authorization factor first verifies whether the payment device still has the permission to use the authorization factor. If it does, then the first verification result is obtained. This ensures the security of the transaction process.

[0044] In some embodiments, it also includes:

[0045] If the authorization factor generating entity determines, based on the authorization policy, that the payment device does not have permission to use the authorization factor, then it obtains the updated authorization policy of the payment device.

[0046] An updated authorization factor ciphertext is generated according to the updated authorization policy, and the updated authorization factor ciphertext is sent to the payment device.

[0047] If the entity generating the authorization factor determines that the payment device does not have permission to use the authorization factor, then the first verification result will not be obtained based on that authorization factor, because the authorization factor has expired. Therefore, an updated authorization strategy is obtained, an updated authorization factor is generated based on the updated authorization strategy, and the updated authorization factor is sent to the payment device so that the payment device generates updated authorization factor information. This ensures that the payment device does not have unlimited access to a particular authorization factor, but rather frequently changes the authorization factor, thus guaranteeing the security of the transaction process.

[0048] In some embodiments, the authorization factor information corresponds to multiple cards.

[0049] Fourthly, embodiments of the present invention also provide a transaction processing apparatus, comprising:

[0050] The acquisition unit is used to acquire authorization factor information corresponding to the card used for payment; the authorization factor information is obtained based on the authorization factor generated by the authorization factor generating entity; the authorization factor is generated by the authorization factor generating entity after the card's personal identification code PIN is verified by the card issuing institution; the PIN is provided by the payment device to the authorization factor generating entity when registering the card with a token;

[0051] The first sending unit is used to send the authorization factor information to the payment receiving device; the payment receiving device is used to obtain the card information of the card and send the card information and the authorization factor information to the authorization factor generating entity; the authorization factor generating entity is used to verify the authorization factor information and the card information to obtain a first verification result, so that the payment receiving device can complete the payment receiving task based on the first verification result.

[0052] In some embodiments, the first transmitting unit is further configured to:

[0053] In response to a user's token registration request for the card, the payment device sends the token registration request for the card to the authorization factor generation entity; the token registration request includes the PIN encrypted of the card; the PIN encrypted is generated based on the PIN;

[0054] It also includes a first receiving unit, which is used to receive the authorization factor sent by the authorization factor generating entity and obtain the authorization factor information based on the authorization factor; the authorization factor is generated by the authorization factor generating entity after the PIN is verified by the card issuing institution.

[0055] In some embodiments, the token registration request may also include device information of the payment device; the authorization factor ciphertext is generated by the authorization factor generating entity after the PIN is verified by the card issuer and the device information is verified by the device manufacturer of the payment device.

[0056] In some embodiments, the first transmitting unit is further configured to:

[0057] In response to a request to set an authorization policy for the card, the payment device sends the setting request to the authorization factor generating entity; the authorization policy is used to characterize the payment device's usage rights over the authorization factor.

[0058] In some embodiments, the first receiving unit is further configured to:

[0059] Receive a payment request sent by a payment device, wherein the payment request carries card information of the card used for payment;

[0060] The acquisition unit is specifically used for:

[0061] The payment device obtains authorization factor information that matches the card information based on the card information.

[0062] In some embodiments, the authorization factor information corresponds to multiple cards.

[0063] Fifthly, embodiments of the present invention also provide a transaction processing apparatus, comprising:

[0064] The second sending unit is used to initiate a payment request for any card, obtain the card information of the card, and send the card information and the authorization factor information of the card obtained through the payment device to the authorization factor generation entity; the authorization factor generation entity is used to decrypt the authorization factor information to obtain the authorization factor, verify whether the authorization factor matches the card information, and obtain a first verification result;

[0065] The first processing unit is used to generate a first verification result sent by the subject based on the authorization factor, and to complete the payment collection task of the payment collection device.

[0066] In some embodiments, the second transmitting unit is specifically used for:

[0067] The payment device obtains the card information via Near Field Communication (NFC) technology to generate the payment request, and obtains the authorization factor information via NFC technology based on the payment request; or

[0068] The payment device obtains the card information and the authorization factor information through NFC technology.

[0069] Sixthly, embodiments of the present invention also provide a transaction processing apparatus, comprising:

[0070] The second receiving unit is used to receive card information and authorization factor information of any card sent by the payment device;

[0071] The second processing unit is used to decrypt the authorization factor information to obtain the authorization factor; and to verify whether the authorization factor matches the card information to obtain a first verification result.

[0072] The third sending unit is used to send the first verification result to the payment receiving device.

[0073] In some embodiments, the second receiving unit is further configured to:

[0074] Receive a token registration request for the card, the token registration request including the PIN encrypted of the card; the PIN encrypted is generated based on the PIN;

[0075] The second processing unit is further configured to: generate an authorization factor for the card after the PIN has been verified by the card issuing institution;

[0076] The third sending unit is further configured to: send the authorization factor to the payment device.

[0077] In some embodiments, the second processing unit is further configured to:

[0078] The authorization strategy for the authorization factor is obtained based on the authorization factor; the authorization strategy is used to characterize the payment device's access rights to the authorization factor.

[0079] The payment device is determined to have permission to use the authorization factor based on the authorization policy.

[0080] In some embodiments, the second processing unit is further configured to:

[0081] If the authorization factor generating entity determines, based on the authorization policy, that the payment device does not have permission to use the authorization factor, then it obtains the updated authorization policy of the payment device.

[0082] An updated authorization factor ciphertext is generated according to the updated authorization policy, and the updated authorization factor ciphertext is sent to the payment device.

[0083] In some embodiments, the authorization factor information corresponds to multiple cards.

[0084] In a seventh aspect, embodiments of the present invention also provide a computing device, comprising:

[0085] Memory, used to store computer programs;

[0086] The processor is configured to invoke a computer program stored in the memory and execute the transaction processing method listed in any of the above methods according to the obtained program.

[0087] Eighthly, embodiments of the present invention also provide a computer-readable storage medium storing a computer-executable program for causing a computer to perform the transaction processing methods listed in any of the above embodiments. Attached Figure Description

[0088] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0089] Figure 1A schematic diagram illustrating an application scenario provided by an embodiment of the present invention;

[0090] Figure 2 This is a schematic diagram illustrating a method for generating authorization factor information for a card, provided by an embodiment of the present invention.

[0091] Figure 3 This is a schematic diagram of an interface for a user to register a token for a card on a payment device, provided as an embodiment of the present invention.

[0092] Figure 4 This is a schematic diagram illustrating a method for offline payment using authorization factor information, provided by an embodiment of the present invention.

[0093] Figure 5a A schematic diagram of the interface for a merchant's payment collection device provided in an embodiment of the present invention;

[0094] Figure 5b This is a schematic diagram of the interface of a user's payment device provided in an embodiment of the present invention;

[0095] Figure 5c This is a schematic diagram of the display interface of a payment device provided in an embodiment of the present invention;

[0096] Figure 5d This is a schematic diagram of the display interface of a payment device provided in an embodiment of the present invention;

[0097] Figure 5e This is a schematic diagram of the display interface of a payment device provided in an embodiment of the present invention;

[0098] Figure 5f This is a schematic diagram of the display interface of a payment device provided in an embodiment of the present invention;

[0099] Figure 6 A schematic diagram of a system architecture provided for an embodiment of the present invention;

[0100] Figure 7 This is a schematic diagram illustrating a method for establishing a secure channel between a payment device and a token service center, and between a payment device and a card issuing institution, provided by an embodiment of the present invention.

[0101] Figure 8 This is a schematic diagram illustrating a method for registering a token for a card according to an embodiment of the present invention;

[0102] Figure 9 This is a schematic diagram illustrating a method for receiving payments using a payment collection device, as provided in an embodiment of the present invention.

[0103] Figure 10 This is a schematic diagram illustrating a method for registering a token for a card according to an embodiment of the present invention;

[0104] Figure 11 This is a schematic diagram illustrating a method for receiving payments using a payment collection device, as provided in an embodiment of the present invention.

[0105] Figure 12 This is a schematic diagram illustrating the verification of the authorization strategy for authorization factors according to an embodiment of the present invention.

[0106] Figure 13 This is a schematic flowchart of a token cancellation method provided by an embodiment of the present invention;

[0107] Figure 14 This is a schematic diagram of the structure of a transaction processing device provided in an embodiment of the present invention;

[0108] Figure 15 This is a schematic diagram of the structure of a transaction processing device provided in an embodiment of the present invention;

[0109] Figure 16 This is a schematic diagram of the structure of a transaction processing device provided in an embodiment of the present invention;

[0110] Figure 17 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0111] To make the objectives, implementation methods and advantages of this application clearer, the exemplary implementation methods of this application will be clearly and completely described below with reference to the accompanying drawings of the exemplary embodiments of this application. Obviously, the described exemplary embodiments are only some embodiments of this application, and not all embodiments.

[0112] Based on the exemplary embodiments described in this application, all other embodiments obtained by those skilled in the art without inventive effort are within the scope of protection of the appended claims. Furthermore, although the disclosures in this application are presented by way of one or more exemplary examples, it should be understood that each aspect of these disclosures can also constitute a complete implementation on its own.

[0113] It should be noted that the brief descriptions of terms in this application are only for the convenience of understanding the embodiments described below, and are not intended to limit the embodiments of this application. Unless otherwise stated, these terms should be understood in their ordinary and common meaning.

[0114] The terms "first," "second," "third," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar or related objects or entities and do not necessarily imply a specific order or sequence, unless otherwise indicated. It should be understood that such terms can be used interchangeably where appropriate, for example, to implement the application in a sequence other than those given in the embodiments illustrated or described herein.

[0115] Furthermore, the terms “comprising” and “having”, and any variations thereof, are intended to cover but not exclusively include, for example, a product or device that includes a series of components is not necessarily limited to those that are explicitly listed, but may include other components that are not explicitly listed or that are inherent to such product or device.

[0116] Figure 1 An exemplary application scenario applicable to an embodiment of the present invention is shown, including a payment device 100, a receiving device 200, and an authorization factor generation entity 300.

[0117] Payment device 100 can be any terminal that can be used to make payments, such as a mobile phone, tablet, computer, etc.

[0118] The payment receiving device 200 can be any terminal capable of offline payment collection, such as a mobile phone, tablet computer, or computer with POS functionality. The payment receiving device provided in this embodiment is not limited to smart terminals; it can also be a traditional POS machine.

[0119] The authorization factor generation entity 300 can generate an authorization factor for a card based on a token registration request from the payment device 100 for that card; and verify the authorization factor information sent by the receiving device 200, sending a first verification result to the receiving device 200. For example, when a user registers a token for card A on the payment device 100, the payment device 100 sends the token registration request to the authorization factor generation entity 300; the authorization factor generation entity 300 generates an authorization factor and sends it to the payment device 100, which then generates authorization factor information for card A based on the authorization factor. When a merchant initiates a payment request for card A using the receiving device 200, the payment device 100 sends the authorization factor information corresponding to card A to the receiving device 200; the receiving device 200 sends the card information and authorization factor information of card A to the authorization factor generation entity 300; the authorization factor generation entity 300 verifies whether the card information and authorization factor information correspond, and sends a first verification result indicating whether they correspond to each other to the receiving device 200. If the first verification result is yes, the receiving device 200 can perform a payment collection operation on card A; if the first verification result is no, it means that the authorization factor information sent by the payment device 100 is not the authorization factor information of card A, and the receiving device 200 cannot perform a payment collection operation on card A.

[0120] Based on the above application scenarios, this embodiment of the invention provides a transaction processing method. The method generates corresponding tokens for each card in the user's payment device, and each token contains authorization factor information. The authorization factor information is then sent to the receiving device to enable the receiving device to complete the payment collection task. The process of generating authorization factor information for the card is described below. Figure 2 As shown, it includes:

[0121] Step 201: In response to the user's token registration for the card, the payment device obtains the card information and the card's PIN.

[0122] The tokens corresponding to each card can be in a separate token management application or WeChat mini-program, or integrated into other existing card management applications, such as UnionPay QuickPass, a bank's mobile application, or mobile payment. This embodiment of the invention does not impose any limitations on this. The following description uses a token management application as an example.

[0123] Figure 3 The diagram illustrates the user interface for registering a token for a card on a payment device. The user opens the token management application, and as shown, brings the card close to the payment device. The payment device reads the card information using NFC technology. The user clicks "Start Registration" and enters the card's corresponding PIN, such as 123456, in the pop-up window.

[0124] Therefore, the payment device obtains the card information and PIN.

[0125] Step 202: The payment device sends a token registration request to the authorization factor generating entity.

[0126] The payment device encrypts the PIN to obtain the PIN ciphertext and sends a token registration request to the authorization factor generating entity. The token registration request includes at least the obtained card information and the PIN ciphertext.

[0127] Step 203: The authorization factor generating entity receives a token registration request for the card.

[0128] Step 204: The authorization factor generating entity generates the authorization factor after the PIN is verified by the card issuing institution.

[0129] If the authorization factor generator is the card issuer, the issuer can directly verify the PIN (because the card was previously registered with that issuer, so the issuer knows the PIN used during registration). If the verification is successful, it means the user entering the PIN into the payment device does indeed know the card's real PIN. Therefore, the authorization factor generator generates the authorization factor for this card. If the verification fails, it means the PIN entered by the user into the payment device is not the card's real PIN registered with the issuer; therefore, the authorization factor generator does not generate the authorization factor for this card.

[0130] The authorization factor may contain a PIN; or it may contain a PIN; or it may not contain a PIN and a PIN, but serve as a unique identifier to uniquely identify the card. The above are just examples.

[0131] Step 205: The authorization factor generating entity sends the authorization factor to the payment device.

[0132] If verification is successful, the entity that generated the authorization factor sends a verification success message and the authorization factor to the payment device. The payment device then generates a token for the card, containing the authorization factor information. The payment device's interface displays a "Binding Successful" message. Thus, in the token management application, the card possesses the corresponding token.

[0133] If the verification fails, the authorization factor generating entity will not generate an authorization factor for the card and will send a verification failure message to the payment device. For example, the payment device may display: Binding failed. The PIN you provided is incorrect. Please re-enter.

[0134] Step 206: The payment device receives the authorization factor sent by the authorization factor generating entity and obtains the authorization factor information based on the authorization factor.

[0135] The payment device can use the authorization factor directly as authorization factor information, or it can encrypt the authorization factor to obtain the authorization factor information. This embodiment of the invention does not impose any restrictions on this.

[0136] In one possible implementation, the obtained authorization factor information can only be decrypted and verified by the authorization factor generating entity. If the authorization factor is decrypted and modified by another entity, the authorization factor received by the authorization factor generating entity from the payment device will be tampered with, affecting the verification result.

[0137] Users can register a token for their card on the payment device. When the receiving device initiates a payment request, the user can find the token corresponding to the card on the payment device and send the authorization factor information carried by the registered token to the receiving device, making the transaction faster and more time-saving. Through the user's token registration request, the payment device obtains the card information and the card's PIN. The payment device encrypts the PIN to obtain PIN ciphertext. Since the payment device's operating environment is secure, the PIN is secure. The payment device sends the PIN ciphertext to the authorization factor generation entity, which generates the authorization factor after the card's PIN has been verified by the card issuer. Because the card issuer verifies the PIN, it ensures that the PIN provided by the payment device during token registration is correct. The authorization factor is generated by a trusted third party—the authorization factor generation entity—facilitating subsequent verification by the receiving device and ensuring the security of the entire transaction process.

[0138] The payment device registers a token for each card, meaning each card possesses its own authorization factor information. The following describes the process of making payments offline using this authorization factor information. Figure 4 As shown, it includes:

[0139] Step 401: The payment device initiates a payment request for any card.

[0140] Step 402: The payment device obtains the authorization factor information corresponding to the card used for payment.

[0141] Step 403: The payment device sends the authorization factor information to the receiving device.

[0142] Step 404: The receiving device obtains the card information and authorization factor information of the card.

[0143] Step 405: The payment device sends the card information and authorization factor information to the authorization factor generation entity.

[0144] Step 406: The authorization factor generating entity receives card information and authorization factor information of any card sent by the payment device.

[0145] Step 407: The authorization factor generating entity decrypts the authorization factor information to obtain the authorization factor.

[0146] Step 408: The authorization factor generating entity verifies whether the authorization factor matches the card information and obtains the first verification result.

[0147] Step 409: The authorization factor generating entity sends the first verification result to the payment receiving device.

[0148] Step 410: The payment receiving device generates the first verification result sent by the main body based on the authorization factor, and completes the payment receiving task of the payment receiving device.

[0149] In step 401, the payment device initiates a payment request for any card.

[0150] One possible approach is for the user to hand their payment card to the merchant. The merchant operates the payment device or card, bringing the payment device close to the card. Near Field Communication (NFC) technology is used to obtain the card information, which may include the card number, issuing bank, and other basic card information. A payment request is then generated for this card, carrying the card information. The payment device sends the payment request to the payment device via a first communication method. The payment device can then automatically obtain the token corresponding to the card information from the payment request and send the authorization factor information carried in the token to the payment device. The first communication method can be image (e.g., scanning a QR code), NFC technology, Wi-Fi, Bluetooth, 2G / 3G / 4G / 5G, etc. For example, if the first communication method is NFC, the merchant brings the payment device and payment device close together, allowing the payment device to send the payment request to the payment device via NFC.

[0151] Figure 5a This diagram illustrates the interface of a merchant's payment collection device. Figure 5a In this process, the merchant enters the payment amount, 25.00 yuan, on the payment device, and then holds the user's card close to the device to read the card information, such as card number 6217×××. The page then displays "Waiting for token," and may also indicate "Use PIN verification instead." This means the user can choose to send the authorization factor information from the token to the payment device, or enter their PIN into the payment device.

[0152] Another possible approach is for the user to present a payment QR code containing card information. The merchant then uses a payment device to scan the QR code, obtain the card information, and generate a payment request, which also includes the card information. The payment device then sends the payment request to the payment device via a first communication method. The payment device can then automatically retrieve the token corresponding to the card information from the payment request and send the authorization factor information contained in that token to the payment device.

[0153] In step 402, the payment device obtains the authorization factor information corresponding to the card used for payment.

[0154] The following describes two methods for payment devices to obtain authorization factor information.

[0155] One possible approach is for the user to hand their payment card to the merchant, allowing the merchant to access the card information using their payment device. Simultaneously, the user locates the token corresponding to the card within the payment device, clicks on the token, and the payment device then obtains the authorization factor information for that card. Figure 5b The diagram shows the user's payment device interface. In the token management application, the user selects a token for payment, which corresponds to the card given to the merchant. After selection, the payment device obtains the authorization factor information of the token.

[0156] Another possible approach is for the user to hand their payment card to the merchant, allowing the merchant to operate the payment device to obtain the card information. The payment device receives the payment request from the payment device via a first communication method, automatically locates the token corresponding to the card information carried in the payment request, and automatically obtains the authorization factor information from that token.

[0157] In step 403, the payment device sends the authorization factor information to the receiving device.

[0158] The payment device sends authorization factor information to the receiving device via a second communication method. This second communication method can be image (e.g., scanning a QR code), NFC technology, Wi-Fi, Bluetooth, 2G / 3G / 4G / 5G, etc. For example, if the second communication method is NFC, the merchant brings the receiving device and the payment device close together, allowing the payment device to send the authorization factor information to the receiving device via NFC. Alternatively, if the second communication method is scanning a QR code, the payment device displays a QR code containing authorization factor information, which the receiving device scans to obtain the authorization factor information.

[0159] Figure 5c The diagram illustrates the display interface of a payment device. After the user clicks on the token corresponding to the card, or after the payment device automatically selects the token based on the payment request, the payment device displays the token. By tapping the token against the receiving device, the payment device sends the token's authorization factor information to the receiving device.

[0160] Figure 5dThe diagram illustrates the display interface of a payment device. After a user clicks on the token corresponding to the card, or after the payment device automatically selects the token based on a payment request, the device displays a QR code containing the authorization factor information for that token. This QR code is generated based on the authorization factor information and the time of day. To ensure transaction security, the QR code contains a validity period, such as 10 seconds. Figure 5e The diagram shows the display interface of the payment device. The payment device obtains the authorization factor information by scanning the QR code provided by the payment device.

[0161] In step 404, the receiving device obtains the card information and authorization factor information of the card.

[0162] The payment device can obtain card information from a physical card via NFC technology or by scanning a user-provided payment QR code. The payment device can also obtain authorization factor information from the payment device via a second communication method, such as NFC technology or by scanning a QR code containing authorization factor information provided by the payment device.

[0163] One possible approach is for the receiving device to first obtain card information, generate a payment request based on that information, and then send the payment request to the payment device via a first communication method. The payment device then sends authorization factor information to the receiving device via a second communication method. For example, the receiving device might obtain card information for card A using NFC technology, generate a payment request for card A, bring the receiving device close to the payment device, and send the payment request to the payment device via NFC technology. The payment device will then send the automatically acquired authorization factor information to the receiving device via NFC technology.

[0164] This invention does not restrict the order of steps 401-203 described above. Card information and authorization factor information can be obtained simultaneously. For example, if the card provided by the payment device contains authorization factor information, the receiving device obtains both the card information and the authorization factor information simultaneously via NFC technology. Alternatively, the payment device may present a QR code containing both card information and authorization factor information; the receiving device scans the QR code to simultaneously obtain both information. That is, the payment QR code and the authorization factor information QR code are combined into one, making the entire transaction process faster and more convenient.

[0165] In step 405, the payment device sends the card information and authorization factor information to the authorization factor generation entity.

[0166] This invention does not restrict the entity that generates the authorization factor; it can be any third party trusted by the payment device and the receiving device. For example, the entity that generates the authorization factor can be a card issuer or a token service center. A token service center is a service center that manages the tokens of each card in the payment device.

[0167] In step 406, the authorization factor generating entity receives card information and authorization factor information of any card sent by the payment device.

[0168] In step 407, the authorization factor generating entity decrypts the authorization factor information to obtain the authorization factor.

[0169] The authorization factor information sent from the payment device to the receiving device is encrypted. This encryption method allows only the entity that generated the authorization factor to decrypt it and obtain the authorization factor. Other entities do not have decryption privileges, thus ensuring that the authorization factor information cannot be tampered with and guaranteeing transaction security.

[0170] The authorization factor generating entity decrypts the authorization factor information received from the receiving device to obtain the authorization factor, which has not been tampered with.

[0171] In step 408, the authorization factor generating entity verifies whether the authorization factor matches the card information and obtains a first verification result.

[0172] Since the authorization factors for each card are generated by the authorization factor generation entity, the entity stores the correspondence between each card's information and its authorization factor. The authorization factor generation entity verifies the authorization factor information and card information received from the payment device. If they match, the first verification result is a match; if they do not match, it indicates that either the card information or the authorization factor information is incorrect, and the first verification result is a mismatch.

[0173] In step 409, the authorization factor generating entity sends the first verification result to the payment receiving device.

[0174] In step 410, the payment receiving device generates the first verification result sent by the main body based on the authorization factor, and completes the payment receiving task of the payment receiving device.

[0175] If the first verification result is a match, it means that the authorization factor information provided by the user is the correct authorization factor information for the card, the user has payment authority for the card, and the payment device can perform payment operation based on the first verification result, such as deducting the amount of 25 yuan for this consumption from the card's account. Figure 5f The diagram shows a display interface of a payment device. When the first verification result is a match, the payment device displays "verification passed," deducts the transaction amount, and the transaction is successful.

[0176] If the first verification result is a mismatch, it indicates that the card information or authorization factor information is incorrect. The authorization factor information provided by the user is not the correct authorization factor information for this card, and the user does not have payment authorization for this card. A prompt message can be displayed on the payment device, such as: "The authorization factor information you provided is incorrect. Please resend." The above is merely an example and is not intended to limit the embodiments of this invention.

[0177] Since the authorization factor information is derived from the authorization factor generated by the authorization factor generating entity, which generates the authorization factor after the card's PIN has been verified by the issuing institution, the issuing institution can guarantee that the PIN provided by the payment device during token registration is correct. Then, the authorization factor generating entity generates an authorization factor for the card. This is equivalent to the issuing institution verifying the PIN provided by the payment device. The payment device obtains the authorization factor information corresponding to the card used for payment and sends it to the receiving device. The receiving device cannot directly obtain the card's PIN, nor can it decrypt the encrypted authorization factor, ensuring the security of the card's PIN. The receiving device sends the card information and the authorization factor information to a trusted authorization factor generating entity. The authorization factor generating entity verifies the card information and the authorization factor information and sends the first verification result to the receiving device. Thus, the user does not need to enter their card's PIN on the receiving device, eliminating concerns about security risks; the receiving device can also verify whether the payment device knows the card's PIN and whether it has payment authorization for the card, thereby ensuring the security of the entire transaction process.

[0178] Figure 6 The diagram illustrates the system architecture provided in this embodiment of the invention. The payment device operates in a Trusted Execution Environment (TEE). The user activates the payment device via biometric identification and interacts with it through a Trusted User Interface (TUI). The payment device interacts with a token service center and the card issuer to obtain authorization factor information. The payment device interacts with the receiving device via NFC technology, sending the authorization factor information to the receiving device.

[0179] In some embodiments, the authorization factor generating entity is the card issuing institution. The process of generating a token for the card is described in detail below. Figure 7 The document illustrates the process for establishing secure channels between payment devices and token service centers, and between payment devices and card issuers, including:

[0180] Step 701: In response to the user's token registration for the card, the payment device generates a token registration request, generates a second public key and a second private key; collects device information; signs the device information using the first key; and sends the token registration request, the signed device information, and the second public key to the token service center.

[0181] The first key is the device trust root key pre-injected at the factory. This first key is used to sign device information, enabling the device manufacturer to verify the device's operating environment. Device information includes at least the device ID and risk data.

[0182] The payment device retains a second private key and sends a second public key to a token service center. The token service center can be any system that manages tokens, such as the UnionPay system, mobile payment system, etc. This embodiment of the invention does not impose any limitations on this.

[0183] Step 702: The token service center forwards the device information signed with the first key to the device manufacturer.

[0184] The token service center retains the second public key.

[0185] Step 703: The device manufacturer uses the first public key to verify the signature, obtains the device information, and after confirming that the device is a secure device, sends the legitimate message of the device to the token service center.

[0186] Step 704: The token service center generates a third private key and a third public key, and sends the token registration request to the issuing institution.

[0187] Step 705: The issuing institution generates a fifth public key and a fifth private key, and sends the fifth public key to the token service center.

[0188] Step 706: The token service center encrypts the device's legitimate message, the third public key, and the fifth public key using the second public key, and sends them to the payment device.

[0189] Step 707: The payment device decrypts the received message using the second private key to obtain the device's legitimate message, the third public key, and the fifth public key.

[0190] Step 708: The payment device generates a fourth key, signs the fourth key using the second private key, encrypts it using the third public key, and sends it to the token service center.

[0191] Step 709: The token service center uses the third private key to decrypt and the second public key to verify the signature, thus obtaining the fourth key.

[0192] Step 710: The payment device generates a sixth private key and a sixth public key, encrypts the sixth public key using the fifth public key, and sends it to the token service center so that the token service center can forward it to the card issuer.

[0193] Step 711: The card issuer uses the fifth private key to decrypt and obtain the sixth public key.

[0194] At this point, the payment device has established a secure channel with the token service center: the payment device possesses a second private key, a third public key, and a fourth private key; the token service center possesses a second public key, a third private key, and a fourth private key; the private key is used for signing, and the public key is used for encryption. Since the fourth key is a symmetric key, using it for encryption and decryption is faster. The payment device has also established a secure channel with the card issuer: the payment device possesses a sixth private key and a fifth public key; the token service center possesses a sixth public key and a fifth private key; the private key is used for signing, and the public key is used for encryption.

[0195] The above process can be triggered by a token registration request or it can occur before the token registration request. For example, when a user applies for token registration for a card, the above process is triggered, establishing a secure channel. Alternatively, the secure channel can be established first using the above method, and then the payment device establishes the secure channel based on the user's token registration request.

[0196] Figure 8 The method flow for registering a token for a card is shown, including:

[0197] Step 801: In response to the user's token registration request for the card, the payment device obtains the card information and PIN.

[0198] Step 802: The payment device encrypts the PIN using the fifth public key to obtain the PIN ciphertext; the PIN ciphertext and card information are signed using the second private key and encrypted with the fourth key before being sent to the token service center.

[0199] Step 803: The token service center uses the fourth key to decrypt and the second public key to verify the signature, obtaining the card information and PIN ciphertext, and then forwards the card information and PIN ciphertext to the card issuing institution.

[0200] Step 804: The card issuer uses the fifth private key to decrypt the PIN ciphertext, obtains the PIN, and verifies whether the PIN is correct.

[0201] Since the card was previously registered with the issuing institution, the issuing institution stores the PIN corresponding to the card information, which can then be verified.

[0202] Step 805: If correct, the issuing institution generates an authorization factor based on the PIN, signs it with the fifth private key, encrypts it with the sixth public key, and sends the signed and encrypted authorization factor and the registration success message to the token service center.

[0203] Authorization factors can be generated based on a variety of information, such as unpredictable numbers, card number hashes, PINs, and authorization policies. Unique characteristic data is generated according to these information and certain rules. The authorization policy may include one or more combinations of the card's authorization factor usage count, authorization factor expiration time, authorized transaction amount, and authorized transaction scenario. The above is merely an example and is not intended to limit the embodiments of this invention.

[0204] Step 806: The card issuer saves the correspondence between each card information and the authorization factor.

[0205] Step 807: Upon receiving the registration success message, the token service center generates a virtual card number for the card and applies for the corresponding emulated card from the device manufacturer's TSM platform.

[0206] Step 808: The token service center forwards the signed and encrypted authorization factor and the registration success message to the payment device.

[0207] Step 809: The payment device decrypts using the sixth private key, verifies the signature using the fifth public key, obtains the authorization factor, signs using the fifth private key, and encrypts using the sixth public key to obtain the authorization factor information of the card.

[0208] Step 810: With the technical support of the equipment manufacturer, the payment device generates a token corresponding to the card in the token management application. The token stores the authorization factor information of the card.

[0209] The following specific example illustrates the verification process for authorization factor information when the authorization factor generator is the card issuer. Figure 9 This illustrates a possible payment collection process using a payment collection device.

[0210] Step 901: The receiving device obtains card information.

[0211] The payment device is brought close to the physical card provided by the user for payment, and the card information is read using NFC technology.

[0212] Step 902: The user opens the token management application on the payment device.

[0213] Users access token management applications through personal authentication methods such as facial recognition, fingerprint recognition, and password recognition, ensuring transaction security. Multi-factor authentication enhances security and prevents unauthorized use of cards.

[0214] Step 903: The user selects the token corresponding to the card in the payment device and sends the authorization factor information in the token to the receiving device.

[0215] For example, it can be sent to a payment device via NFC technology.

[0216] Step 904: The receiving device forwards the card information and authorization factor information to the POS backend, and the POS backend forwards the card information and authorization factor information to the issuing institution.

[0217] Step 905: The card issuer uses the fifth private key to decrypt and the sixth public key to verify the signature, obtains the authorization factor, and verifies whether the card information and the authorization factor match.

[0218] Step 906: The card issuer sends the first verification result to the POS backend, and the POS backend forwards the first verification result to the payment receiving device.

[0219] Step 907: The payment receiving device completes the payment receiving task based on the first verification result.

[0220] Since the fifth public key and the fifth private key are generated by the card issuer, and the sixth public key and the sixth private key are generated by the payment device, only the card issuer can decrypt the PIN encrypted with the fifth public key, and only the payment device can decrypt the authorization factor encrypted with the sixth public key, thus ensuring the security of the information transmission process.

[0221] In some embodiments, the authorization factor generation entity is a token service center. The process of generating a token for a card is described in detail below, such as... Figure 10 As shown. The methods for establishing a secure passage are... Figure 7 Similarly, except that steps 710 and 711 are not included, meaning that there is no need to generate a sixth public key and a sixth private key.

[0222] Step 1001: In response to the user's token registration request for the card, the payment device obtains the card information and PIN.

[0223] Step 1002: The payment device encrypts the PIN using the fifth public key to obtain the PIN ciphertext; it encrypts the card information using the fourth key, and signs the PIN ciphertext and the encrypted card information using the second private key. The above information is then sent to the token service center.

[0224] Step 1003: The token service center uses the second public key to verify the signature and the fourth key to decrypt, obtaining the card information and PIN ciphertext.

[0225] Step 1004: The token service center forwards the PIN encrypted message to the card issuer.

[0226] Since the token service center does not have the card's PIN, the encrypted PIN needs to be forwarded to the issuing institution for verification.

[0227] Step 1005: The card issuer uses the fifth private key to decrypt the PIN ciphertext, obtains the PIN, and verifies whether the PIN is correct.

[0228] Since the card was previously registered with the issuing institution, the issuing institution stores the PIN corresponding to the card information, which can then be verified.

[0229] Step 1006: If correct, the issuing institution will send a message indicating that the PIN verification has been successful to the token service center.

[0230] Step 1007: After receiving the message that the PIN verification is successful, the token service center generates the authorization factor.

[0231] Step 1008: The token service center stores the correspondence between the card information, authorization factor, and PIN encryption.

[0232] Step 1009: The token service center encrypts the authorization factor with the fourth key, signs it with the third private key, and sends it to the payment device.

[0233] Step 1010: The token service center generates a virtual card number for the card and applies for a corresponding emulated card from the device manufacturer's TSM platform.

[0234] Step 1011: The payment device uses the third public key to verify the signature and obtains the authorization factor encrypted with the fourth key. The authorization factor encrypted with the fourth key is directly determined as the authorization factor information.

[0235] Step 1012: With the technical support of the equipment manufacturer, the payment device generates a token corresponding to the card in the token management application. The token stores the authorization factor information of the card.

[0236] The following specific example illustrates the verification process for authorization factor information when the authorization factor generation entity is a token service center. Figure 11 This illustrates a possible payment collection process using a payment collection device.

[0237] Step 1101: The receiving device obtains card information.

[0238] Step 1102: The user opens the token management application on the payment device.

[0239] Step 1103: The user selects the token corresponding to the card in the payment device and sends the authorization factor information in the token to the receiving device.

[0240] Step 1104: The receiving device forwards the card information and authorization factor information to the POS backend, and the POS backend forwards the card information and authorization factor information to the token service center.

[0241] Step 1105: The token service center uses the fourth key to decrypt and obtain the authorization factor.

[0242] Step 1106: The token service center determines whether the card information and authorization factor match based on the previously stored correspondence between card information, authorization factor, and PIN ciphertext, and sends the first verification result to the POS backend. The POS backend then forwards the first verification result to the payment device.

[0243] Step 1107: The token service center sends the PIN encrypted message to the card issuer.

[0244] Step 1108: The card issuer uses the fifth private key to decrypt the PIN ciphertext to obtain the PIN, verifies whether the PIN matches the card information, and sends the second verification result to the POS backend. The POS backend then forwards the second verification result to the payment receiving device.

[0245] Step 1109: The payment device receives the first verification result and the second verification result, and completes the payment task based on the first verification result and the second verification result.

[0246] If the authorization factor is generated by a token service center, whose security level is lower than that of the card issuer, the token service center will not directly obtain the PIN. Instead, it will obtain the encrypted PIN and forward it to the card issuer for verification. This method eliminates the need for the card issuer to generate the authorization factor, reducing the workload of modifying the card issuer. Furthermore, the use of a symmetric key fourth key for encryption and decryption speeds up the process while ensuring the security of the entire transaction.

[0247] In some embodiments, each authorization factor corresponds to an authorization policy, which is set by the user through a payment device. For example, the authorization policy may include at least one of the following: the number of times the authorization factor can be used, the expiration time of the authorization factor, the authorized transaction amount, and the authorized transaction scenario. The setting method includes: in response to a request to set the authorization policy for the card, the payment device sends the setting request to the authorization factor generating entity; the authorization policy is used to characterize the payment device's usage rights over the authorization factor.

[0248] When the authorization factor generating entity receives the authorization factor information sent by the payment device, decrypts it to obtain the authorization factor, and before obtaining the first verification result, the authorization factor generating entity can obtain the corresponding authorization policy based on the authorization factor, thereby determining whether the payment device has permission to use the authorization factor. For example, if the authorization policy of the authorization factor explicitly states that it can be used 5 times, then if the authorization factor generating entity determines that the authorization factor has already been used 5 times, the payment device does not have permission to use it in this instance. A verification failure message is then sent to the payment device. Simultaneously, an updated authorization factor is sent to the payment device.

[0249] If the entity generating the authorization factor determines that the payment device has permission to use the authorization factor, then further verification will be performed. In this way, each authorization factor will have a pre-set usage permission, ensuring that the authorization factor is not used without restriction and improving transaction security.

[0250] If the authorization factor generating entity determines that the payment device does not have permission to use the authorization factor, it obtains the updated authorization policy from the payment device; generates an updated authorization factor ciphertext based on the updated authorization policy, and sends the updated authorization factor ciphertext to the payment device. In other words, a user can change the authorization policy of any card at any time in the payment device, and the payment device will send the changed authorization policy to the authorization factor generating entity.

[0251] After obtaining an authorization factor from its encrypted form each time, the authorization factor generator first verifies whether the payment device still has permission to use the authorization factor. If it does, it obtains the first verification result, ensuring transaction security. If the authorization factor generator determines that the payment device no longer has permission to use the authorization factor, it no longer obtains the first verification result based on that authorization factor, as it has expired. Therefore, it obtains an updated authorization strategy, generates an updated authorization factor based on the updated strategy, and sends the updated authorization factor to the payment device, enabling the payment device to generate an updated encrypted authorization factor. This ensures that the payment device does not have unlimited access to a particular authorization factor but frequently changes the authorization factor, thus guaranteeing transaction security.

[0252] Figure 12 A schematic diagram illustrating a method for verifying the authorization policy of an authorization factor is shown. As illustrated, the authorization factor generating entity queries the authorized usage records of the authorization factor to determine whether the usage frequency limit, usage amount limit, and usage time limit in the authorization policy have been exceeded. If none of these limits are exceeded, the verification is successful, indicating that the payment device can still use the authorization factor. If any one of these limits is exceeded, the authorization factor needs to be updated. The system then determines whether to update the authorization policy. If an update is needed, the authorization factor is generated based on the new policy; otherwise, it is generated based on the previous policy. The updated authorization factor is then sent to the payment device. The payment device generates updated authorization factor information based on this updated authorization factor, thus giving the card the updated authorization factor information.

[0253] In some embodiments, a single aggregated token can be generated for multiple cards during the token registration process, meaning one authorization factor corresponds to multiple cards. For example, during token registration, a user selects multiple cards, namely Card A, Card B, and Card C, and enters the same PIN for all three cards. The payment device sends the card information and PINs of all cards to the token service center. The token service center then sends the card information and PINs of all cards to their respective issuing institutions. After each issuing institution verifies the PIN, it sends a verification success message to the token service center. The token service center generates an aggregated authorization factor based on at least one of the following: the hash value of the multiple card numbers, the PIN, and the authorization policy. The token service center sends the aggregated authorization factor to the payment device, which generates a single aggregated token for the multiple cards. When any of the multiple cards is used for payment, this aggregated token is invoked. This simplifies the user's operation and improves the user experience.

[0254] In some embodiments, multiple registered tokens can be merged to generate a single aggregated token, meaning one authorization factor corresponds to multiple cards. The user selects the tokens to be aggregated on the payment device interface. The payment device sends the card information and authorization factors of the multiple tokens to a token service center. The token service center generates the aggregated authorization factor based on at least one of the following: the hash values ​​of the multiple card numbers, the PIN, and the authorization policy. Optionally, the authorization factor generating entity can automatically determine the authorization policy of any one of the multiple cards as the authorization policy of the aggregated authorization factor; or the user can redefine the authorization policy of the aggregated authorization factor in the payment device. The token service center sends the aggregated authorization factor to the payment device, and the payment device generates a single aggregated token for the multiple cards. When any of the multiple cards is used for payment, the aggregated token is invoked. This simplifies the user's operation and improves the user experience.

[0255] In some embodiments, users can choose to cancel the token corresponding to the card. Figure 13 A method flow for token revocation is shown. It includes:

[0256] Step 1301: The user selects to cancel the token of any card in the payment device.

[0257] Step 1302: The payment device verifies the user's identity.

[0258] For example, through facial recognition, fingerprint recognition, or password recognition.

[0259] Step 1303: The payment device initiates a cancellation request to the token service center.

[0260] Step 1304: After verifying the identity, the token service center will send the cancellation request to the card issuer.

[0261] Step 1305: The card issuer removes the binding relationship between the card information and the authorization factor.

[0262] Step 1306: The token service center applies to the device manufacturer's TSM platform to delete the emulated card.

[0263] Step 1307: The payment device deletes the locally stored authorization factor and, with the technical support of the device manufacturer, deletes the emulated card from the token management application.

[0264] Step 1308, cancellation complete.

[0265] Based on the same technological concept Figure 14 An exemplary embodiment of the present invention illustrates the structure of a transaction processing apparatus that can execute a transaction processing flow.

[0266] like Figure 14 As shown, the device specifically includes:

[0267] The acquisition unit 1401 is used to acquire authorization factor information corresponding to the card used for payment; the authorization factor information is obtained based on the authorization factor generated by the authorization factor generating entity; the authorization factor is generated by the authorization factor generating entity after the card's personal identification code PIN is verified by the card issuing institution; the PIN is provided by the payment device to the authorization factor generating entity when registering the card with a token;

[0268] The first sending unit 1402 is used to send the authorization factor information to the payment receiving device; the payment receiving device is used to obtain the card information of the card and send the card information and the authorization factor information to the authorization factor generating entity; the authorization factor generating entity is used to verify the authorization factor information and the card information to obtain a first verification result, so that the payment receiving device completes the payment receiving task based on the first verification result.

[0269] In some embodiments, the first transmitting unit 1402 is further configured to:

[0270] In response to a user's token registration request for the card, the payment device sends the token registration request for the card to the authorization factor generation entity; the token registration request includes the PIN encrypted of the card; the PIN encrypted is generated based on the PIN;

[0271] It also includes a first receiving unit 1403, which is used to receive the authorization factor sent by the authorization factor generating entity and obtain the authorization factor information based on the authorization factor; the authorization factor is generated by the authorization factor generating entity after the PIN is verified by the card issuing institution.

[0272] In some embodiments, the token registration request may also include device information of the payment device; the authorization factor ciphertext is generated by the authorization factor generating entity after the PIN is verified by the card issuer and the device information is verified by the device manufacturer of the payment device.

[0273] In some embodiments, the first transmitting unit 1402 is further configured to:

[0274] In response to a request to set an authorization policy for the card, the payment device sends the setting request to the authorization factor generating entity; the authorization policy is used to characterize the payment device's usage rights over the authorization factor.

[0275] In some embodiments, the first receiving unit 1403 is further configured to:

[0276] Receive a payment request sent by a payment device, wherein the payment request carries card information of the card used for payment;

[0277] The acquisition unit 1401 is specifically used for:

[0278] The payment device obtains authorization factor information that matches the card information based on the card information.

[0279] In some embodiments, the authorization factor information corresponds to multiple cards.

[0280] Based on the same technological concept Figure 15 An exemplary embodiment of the present invention illustrates the structure of a transaction processing apparatus that can execute a transaction processing flow.

[0281] like Figure 15 As shown, the device specifically includes:

[0282] The second sending unit 1501 is used to initiate a payment request for any card, obtain the card information of the card, and send the card information and the authorization factor information of the card obtained through the payment device to the authorization factor generation entity; the authorization factor generation entity is used to decrypt the authorization factor information to obtain the authorization factor, verify whether the authorization factor matches the card information, and obtain a first verification result;

[0283] The first processing unit 1502 is used to generate a first verification result sent by the subject based on the authorization factor, and complete the payment collection task of the payment collection device.

[0284] In some embodiments, the second transmitting unit 1501 is specifically used for:

[0285] The payment device obtains the card information via Near Field Communication (NFC) technology to generate the payment request, and obtains the authorization factor information via NFC technology based on the payment request; or

[0286] The payment device obtains the card information and the authorization factor information through NFC technology.

[0287] Based on the same technological concept Figure 16 An exemplary embodiment of the present invention illustrates the structure of a transaction processing apparatus that can execute a transaction processing flow.

[0288] like Figure 16 As shown, the device specifically includes:

[0289] The second receiving unit 1601 is used to receive card information and authorization factor information of any card sent by the payment device;

[0290] The second processing unit 1602 is used to decrypt the authorization factor information to obtain the authorization factor; and to verify whether the authorization factor matches the card information to obtain a first verification result.

[0291] The third sending unit 1603 is used to send the first verification result to the receiving device.

[0292] In some embodiments, the second receiving unit 1601 is further configured to:

[0293] Receive a token registration request for the card, the token registration request including the PIN encrypted of the card; the PIN encrypted is generated based on the PIN;

[0294] The second processing unit 1602 is further configured to: generate an authorization factor for the card after the PIN has been verified by the card issuing institution;

[0295] The third sending unit 1603 is further configured to: send the authorization factor to the payment device.

[0296] In some embodiments, the second processing unit 1602 is further configured to:

[0297] The authorization strategy for the authorization factor is obtained based on the authorization factor; the authorization strategy is used to characterize the payment device's access rights to the authorization factor.

[0298] The payment device is determined to have permission to use the authorization factor based on the authorization policy.

[0299] In some embodiments, the second processing unit 1602 is further configured to:

[0300] If the authorization factor generating entity determines, based on the authorization policy, that the payment device does not have permission to use the authorization factor, then it obtains the updated authorization policy of the payment device.

[0301] An updated authorization factor ciphertext is generated according to the updated authorization policy, and the updated authorization factor ciphertext is sent to the payment device.

[0302] In some embodiments, the authorization factor information corresponds to multiple cards.

[0303] Based on the same technical concept, embodiments of this application provide a computer device, such as... Figure 17 As shown, it includes at least one processor 1701 and a memory 1702 connected to at least one processor. In this embodiment, the specific connection medium between the processor 1701 and the memory 1702 is not limited. Figure 17 Taking the connection between the processor 1701 and the memory 1702 via a bus as an example, the bus can be divided into address bus, data bus, control bus, etc.

[0304] In this embodiment of the application, the memory 1702 stores instructions that can be executed by at least one processor 1701. By executing the instructions stored in the memory 1702, at least one processor 1701 can perform the steps of the above-described transaction processing method.

[0305] The processor 1701 is the control center of the computer device, capable of connecting to various parts of the computer device via various interfaces and lines. It performs transaction processing by running or executing instructions stored in the memory 1702 and accessing data stored in the memory 1702. In some embodiments, the processor 1701 may include one or more processing units. The processor 1701 may integrate an application processor and a modem processor, wherein the application processor primarily handles the operating system, user interface, and applications, while the modem processor primarily handles wireless communication. It is understood that the modem processor may not be integrated into the processor 1701. In some embodiments, the processor 1701 and the memory 1702 may be implemented on the same chip; in some embodiments, they may also be implemented on separate chips.

[0306] Processor 1701 can be a general-purpose processor, such as a central processing unit (CPU), digital signal processor, application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0307] Memory 1702, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules. Memory 1702 may include at least one type of storage medium, such as flash memory, hard disk, multimedia card, card-type memory, random access memory (RAM), static random access memory (SRAM), programmable read-only memory (PROM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), magnetic storage, magnetic disk, optical disk, etc. Memory 1702 can be any other medium capable of carrying or storing desired program code in the form of instructions or data structures that can be accessed by a computer, but is not limited thereto. Memory 1702 in the embodiments of this application may also be a circuit or any other device capable of implementing storage functions for storing program instructions and / or data.

[0308] Based on the same technical concept, embodiments of the present invention also provide a computer-readable storage medium storing a computer-executable program, the computer-executable program being used to cause a computer to perform the transaction processing method listed in any of the above methods.

[0309] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0310] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0311] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0312] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0313] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A transaction processing method, characterized in that, include: The payment device obtains the authorization factor information corresponding to the card used for payment; The authorization factor information is obtained based on the authorization factors generated by the authorization factor generating entity. The authorization factor is generated by the authorization factor generating entity after the card's personal identification code (PIN) has been verified by the card issuing institution; the PIN is provided by the payment device to the authorization factor generating entity when registering the card with a token. The payment device sends the authorization factor information to the receiving device; the receiving device obtains the card information and sends the card information and the authorization factor information to the authorization factor generating entity. The authorization factor generating entity is used to verify the authorization factor information and the card information to obtain a first verification result, so that the payment device can complete the payment task based on the first verification result; The operating environment of the payment device is a trusted execution environment. Users activate the payment device through biometric identification and interact with the payment device through a trusted user interface. If the authorization factor generating entity is a token service center, the first key is used to sign the payment device information. The first key is the payment device trust root key pre-injected when the payment device leaves the factory, so that the payment device manufacturer can verify the operating environment of the payment device. The payment device manufacturer uses the first public key to verify the signature, obtains the device information of the payment device, and after determining that the payment device is a secure device, sends the legitimate message of the payment device to the token service center. During the token registration process, an aggregated token can be generated for multiple cards, or multiple registered tokens can be merged into one aggregated token. The token service center generates an aggregated authorization factor based on at least one of the following information: the hash value of the multiple card numbers, the PIN, and the authorization policy.

2. The method as described in claim 1, characterized in that, Also includes: In response to a user's token registration for the card, the payment device sends the card's token registration request to the authorization factor generation entity; The token registration request includes the PIN of the card; the PIN is generated based on the PIN. The payment device receives the authorization factor sent by the authorization factor generating entity and obtains the authorization factor information based on the authorization factor; The authorization factor is generated by the authorization factor generating entity after the PIN has been verified by the card issuing institution.

3. The method as described in claim 2, characterized in that, The token registration request also includes the device information of the payment device; the authorization factor ciphertext is generated by the authorization factor generating entity after the PIN is verified by the card issuer and the device information is verified by the device manufacturer of the payment device.

4. The method as described in claim 1, characterized in that, Also includes: In response to a request to set the authorization policy for the card, the payment device sends the setting request to the authorization factor generating entity; The authorization strategy is used to characterize the payment device's access rights to the authorization factor.

5. The method as described in claim 1, characterized in that, Before the payment device obtains the authorization factor information corresponding to the card used for payment, it also includes: The payment device receives a payment request sent by the receiving device, and the payment request carries card information of the card used for payment; The payment device obtains the authorization factor information corresponding to the card used for payment, including: The payment device obtains authorization factor information that matches the card information based on the card information.

6. The method according to any one of claims 1-5, characterized in that, The authorization factor information corresponds to multiple cards.

7. A transaction processing method, characterized in that, include: The payment device initiates a payment request for any card, obtains the card information, and sends the card information and the card's authorization factor information obtained through the payment device to the authorization factor generation entity. The authorization factor generation entity is used to decrypt the authorization factor information to obtain the authorization factor, verify whether the authorization factor matches the card information, and obtain a first verification result. The payment collection device completes its payment collection task based on the first verification result sent by the authorization factor generated by the entity. The operating environment of the payment device is a trusted execution environment. Users activate the payment device through biometric identification and interact with the payment device through a trusted user interface. If the authorization factor generating entity is a token service center, the first key is used to sign the payment device information. The first key is the payment device trust root key pre-injected when the payment device leaves the factory, so that the payment device manufacturer can verify the operating environment of the payment device. The payment device manufacturer uses the first public key to verify the signature, obtains the device information of the payment device, and after determining that the payment device is a secure device, sends the legitimate message of the payment device to the token service center. During the token registration process, an aggregated token can be generated for multiple cards, or multiple registered tokens can be merged into one aggregated token. The token service center generates an aggregated authorization factor based on at least one of the following information: the hash value of the multiple card numbers, the PIN, and the authorization policy.

8. The method as described in claim 7, characterized in that, The payment receiving device obtains the card information and the authorization factor information in the following ways: The payment device obtains the card information via Near Field Communication (NFC) technology to generate the payment request, and obtains the authorization factor information via NFC technology based on the payment request; or The payment device obtains the card information and the authorization factor information through NFC technology.

9. A transaction processing method, characterized in that, include: The authorization factor generating entity receives card information and authorization factor information for any card sent by the payment receiving device; The authorization factor generating entity decrypts the authorization factor information to obtain the authorization factor; The authorization factor generating entity verifies whether the authorization factor matches the card information and obtains a first verification result; The authorization factor generating entity sends the first verification result to the payment receiving device; The operating environment of the payment device is a trusted execution environment. Users activate the payment device through biometric identification and interact with the payment device through a trusted user interface. If the authorization factor generating entity is a token service center, the first key is used to sign the payment device information. The first key is the payment device trust root key pre-injected when the payment device leaves the factory, so that the payment device manufacturer can verify the operating environment of the payment device. The payment device manufacturer uses the first public key to verify the signature, obtains the device information of the payment device, and after determining that the payment device is a secure device, sends the legitimate message of the payment device to the token service center. During the token registration process, an aggregated token can be generated for multiple cards, or multiple registered tokens can be merged into one aggregated token. The token service center generates an aggregated authorization factor based on at least one of the following information: the hash value of the multiple card numbers, the PIN, and the authorization policy.

10. The method as described in claim 9, characterized in that, Also includes: The authorization factor generating entity receives a token registration request for the card, the token registration request including the PIN of the card; The PIN ciphertext is generated based on the PIN; The authorization factor generating entity generates the authorization factor for the card after the PIN is verified by the card issuing institution; The authorization factor generating entity sends the authorization factor to the payment device.

11. The method as described in claim 9, characterized in that, After the authorization factor generating entity decrypts the authorization factor information to obtain the authorization factor, and before obtaining the first verification result, the following steps are also included: The authorization factor generating entity obtains the authorization strategy of the authorization factor based on the authorization factor; the authorization strategy is used to characterize the payment device's usage rights of the authorization factor; The payment device is determined to have permission to use the authorization factor based on the authorization policy.

12. The method as described in claim 11, characterized in that, Also includes: If the authorization factor generating entity determines, based on the authorization policy, that the payment device does not have permission to use the authorization factor, then it obtains the updated authorization policy of the payment device. An updated authorization factor ciphertext is generated according to the updated authorization policy, and the updated authorization factor ciphertext is sent to the payment device.

13. The method according to any one of claims 9-12, characterized in that, The authorization factor information corresponds to multiple cards.

14. A transaction processing apparatus, characterized in that, include: The acquisition unit is used to acquire the authorization factor information corresponding to the card used for payment; The authorization factor information is obtained based on the authorization factors generated by the authorization factor generating entity. The authorization factor is generated by the authorization factor generating entity after the card's personal identification code (PIN) has been verified by the card issuing institution; the PIN is provided to the authorization factor generating entity by the payment device when registering the card with a token. The first sending unit is used to send the authorization factor information to the payment receiving device; the payment receiving device is used to obtain the card information of the card, and send the card information and the authorization factor information to the authorization factor generating entity; The authorization factor generating entity is used to verify the authorization factor information and the card information to obtain a first verification result, so that the payment device can complete the payment task based on the first verification result; The operating environment of the payment device is a trusted execution environment. Users activate the payment device through biometric identification and interact with the payment device through a trusted user interface. If the authorization factor generating entity is a token service center, the first key is used to sign the payment device information. The first key is the payment device trust root key pre-injected when the payment device leaves the factory, so that the payment device manufacturer can verify the operating environment of the payment device. The payment device manufacturer uses the first public key to verify the signature, obtains the device information of the payment device, and after determining that the payment device is a secure device, sends the legitimate message of the payment device to the token service center. During the token registration process, an aggregated token can be generated for multiple cards, or multiple registered tokens can be merged into one aggregated token. The token service center generates an aggregated authorization factor based on at least one of the following information: the hash value of the multiple card numbers, the PIN, and the authorization policy.

15. A transaction processing apparatus, characterized in that, include: The second sending unit is used to initiate a payment request for any card, obtain the card information of the card, and send the card information and the authorization factor information of the card obtained through the payment device to the authorization factor generation entity; the authorization factor generation entity is used to decrypt the authorization factor information to obtain the authorization factor, verify whether the authorization factor matches the card information, and obtain a first verification result; The first processing unit is used to generate a first verification result sent by the subject based on the authorization factor, and complete the payment collection task of the payment collection device. The operating environment of the payment device is a trusted execution environment. Users activate the payment device through biometric identification and interact with the payment device through a trusted user interface. If the authorization factor generating entity is a token service center, the first key is used to sign the payment device information. The first key is the payment device trust root key pre-injected when the payment device leaves the factory, so that the payment device manufacturer can verify the operating environment of the payment device. The payment device manufacturer uses the first public key to verify the signature, obtains the device information of the payment device, and after determining that the payment device is a secure device, sends the legitimate message of the payment device to the token service center. During the token registration process, an aggregated token can be generated for multiple cards, or multiple registered tokens can be merged into one aggregated token. The token service center generates an aggregated authorization factor based on at least one of the following information: the hash value of the multiple card numbers, the PIN, and the authorization policy.

16. A transaction processing apparatus, characterized in that, include: The second receiving unit is used to receive card information and authorization factor information of any card sent by the payment device; The second processing unit is used to decrypt the authorization factor information to obtain the authorization factor; The matching between the authorization factor and the card information is verified to obtain a first verification result; The third sending unit is used to send the first verification result to the payment receiving device; The operating environment of the payment device is a trusted execution environment. Users activate the payment device through biometric identification and interact with the payment device through a trusted user interface. If the authorization factor generating entity is a token service center, the first key is used to sign the payment device information. The first key is the payment device trust root key pre-injected when the payment device leaves the factory, so that the payment device manufacturer can verify the operating environment of the payment device. The payment device manufacturer uses the first public key to verify the signature, obtains the device information of the payment device, and after determining that the payment device is a secure device, sends the legitimate message of the payment device to the token service center. During the token registration process, an aggregated token can be generated for multiple cards, or multiple registered tokens can be merged into one aggregated token. The token service center generates an aggregated authorization factor based on at least one of the following information: the hash value of the multiple card numbers, the PIN, and the authorization policy.

17. A computing device, characterized in that, include: Memory, used to store computer programs; A processor is configured to invoke a computer program stored in the memory and execute the method according to any one of claims 1 to 13 in accordance with the obtained program.

18. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer-executable program for causing a computer to perform the method according to any one of claims 1 to 13.

Images