Payment method, account configuration method, system, device, equipment and medium

Abstract

The present application discloses a payment method, account configuration method, system, apparatus, device and medium, which relate to the field of electronic payment technology, and more specifically, to the field of offline payment security technology. One payment method is applied to a payment-end server, and the method includes: obtaining first payment information and payment verification information sent by a payment device; the payment verification information is generated by the payment device performing signature processing or signature encryption processing on the second payment information from the payment device; the first payment information and the second payment information are payment information for the target transaction; the first payment information is verified based on the payment verification information to obtain a verification result; if the verification result is passed, the virtual wallet bound to the payment device is processed for transaction according to the first payment information to obtain the transaction result of the target transaction. This can improve the convenience and security of using the payment device.

Description

Technical Field

[0001] The present application generally relates to the field of electronic payment technology, specifically to the field of offline payment security technology, and in particular to a payment method, account configuration method, system, device, equipment and medium. Background Art

[0002] In the digital economy era, the innovative value and competitiveness driven by technology are rapidly spawning a wide range of innovative product forms and service capabilities. As electronic currency circulates, hardware wallets are increasingly influencing every aspect of people's daily lives, and their offline payment capabilities are increasingly popular among users.

[0003] In the prior art, before using a hardware wallet, it is necessary to recharge the hardware wallet (such as a bus card) before it can be used. However, this method of pre-charging is not only very troublesome, but also has very low payment security. Summary of the Invention

[0004] In view of the above-mentioned defects or deficiencies in the prior art, it is desirable to provide a payment method, account configuration method, system, apparatus, device and medium that can improve the convenience and security of using payment devices.

[0005] In a first aspect, the present application provides a payment method, which is applied to a payment-end server, and the method includes: obtaining first payment information and payment verification information sent by a payment device; the payment verification information is generated by the payment device performing signature processing or signature encryption processing on the second payment information from the payment device; the first payment information and the second payment information are the payment information of the target transaction; verifying the first payment information based on the payment verification information to obtain a verification result; if the verification result is passed, performing transaction processing on the virtual wallet bound to the payment device according to the first payment information to obtain the transaction result of the target transaction.

[0006] In a second aspect, the present application provides an account configuration method, which is applied to a virtual wallet client, the method comprising: displaying at least one configuration item of a payment device; receiving a configuration operation of at least one configuration item, and determining configuration information of the payment device based on the configuration operation; and sending the configuration information to a payment-end server, where the configuration information is used by the payment-end server to generate a binding relationship between the virtual wallet and the payment device.

[0007] In a third aspect, the present application provides a payment method, which is applied to a virtual wallet client, and the method includes: receiving second payment information from a payment device; performing signature processing or signature encryption processing on the second payment information to generate payment verification information; transmitting the payment verification information to the payment device, and the payment verification information is used by the payment device to send to the server, so that the payment-end server verifies the first payment information based on the payment verification information to obtain a verification result, and if the verification result is passed, the virtual wallet bound to the payment device is processed according to the first payment information to obtain a transaction result of the target transaction; the first payment information is sent by the payment device to the server, and the first payment information and the second payment information are the payment information of the target transaction.

[0008] In a fourth aspect, the present application provides a payment system, which includes: a payment device for receiving second payment information from a payment receiving device; the payment device is also used to sign or encrypt the second payment information, generate payment verification information, and transmit the payment verification information to the payment receiving device; the payment receiving device is used to send the payment verification information and the first payment information to a payment-end server; the first payment information and the second payment information are the payment information of the target transaction; the payment-end server is used to verify the first payment information based on the payment verification information to obtain a verification result; if the verification result is passed, the virtual wallet bound to the payment device is processed according to the first payment information to obtain the transaction result of the target transaction.

[0009] In a fifth aspect, the present application provides a payment device, which is applied to a payment-end server, and the payment device includes: an acquisition unit, which is used to obtain first payment information and payment verification information sent by a payment device; the payment verification information is generated by the payment device performing signature processing or signature encryption processing on the second payment information from the payment device; the first payment information and the second payment information are the payment information of the target transaction; a verification unit, which is used to verify the first payment information based on the payment verification information to obtain a verification result; a transaction processing unit, which is used to perform transaction processing on the virtual wallet bound to the payment device according to the first payment information if the verification result is passed, and obtain the transaction result of the target transaction.

[0010] In a sixth aspect, the present application provides an account configuration device, which is applied to a virtual wallet client, and the account configuration device includes: a display unit, which is used to display at least one configuration item of a payment device; a receiving unit, which is used to receive a configuration operation of at least one configuration item; a processing unit, which is used to determine the configuration information of the payment device according to the configuration operation; and a sending unit, which is used to send the configuration information to the payment end server, and the configuration information is used by the payment end server to generate a binding relationship between the virtual wallet and the payment device.

[0011] In the seventh aspect, the present application provides a payment device, which is applied to a payment device, and the payment device includes: a receiving unit, which is used to receive second payment information from the payment device; a signing unit, which is used to sign or encrypt the second payment information to generate payment verification information; a transmission unit, which is used to transmit the payment verification information to the payment device, and the payment verification information is used for the payment device to send to the server, so that the payment-end server verifies the first payment information based on the payment verification information to obtain a verification result, and when the verification result is passed, the virtual wallet bound to the payment device is processed according to the first payment information to obtain the transaction result of the target transaction; the first payment information is sent by the payment device to the server, and the first payment information and the second payment information are the payment information of the target transaction.

[0012] In an eighth aspect, an embodiment of the present application provides a computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the method described in the embodiment of the present application when executing the program.

[0013] In a ninth aspect, an embodiment of the present application provides a computer-readable storage medium on which a computer program is stored, which, when executed by a processor, implements the method described in the embodiment of the present application.

[0014] In a tenth aspect, an embodiment of the present application provides a computer program product, which includes instructions. When the instructions are executed, the method described in the embodiment of the present application is executed.

[0015] The payment method, account configuration method, system, apparatus, equipment and medium proposed in this application are as follows: when a user uses a payment device to conduct a transaction, the payment device sends the payment information of the transaction to the payment device and the payment end server respectively; the payment device performs signature processing or signature encryption processing on the received payment information (i.e., the second payment information) to generate payment verification information; and the payment verification information is then transmitted to the payment end server through the payment device. The payment end server uses the payment verification information to verify the payment information (i.e., the first payment information) from the payment device. Since the first payment information and the second payment information both correspond to the same transaction (i.e., the target transaction); therefore, through the above-mentioned verification method, not only can it be determined whether the payment device has authorized the payment of the first payment information, but it can also be identified whether the first payment information has been maliciously tampered with during the transmission process, thereby ensuring the authenticity of the payment information and avoiding the situation of erroneous deductions.

[0016] Furthermore, if the first payment information is verified, the payment server processes the transaction in the virtual wallet associated with the payment device based on the first payment information and obtains the transaction result. This allows users to conduct transactions on-site through the payment device and process the transaction (i.e., debit the payment) in the virtual wallet, eliminating the need to pre-charge the payment device and ensuring the security of the payment device.

[0017] Additional aspects and advantages of the present application will be given in part in the description below, and in part will become apparent from the description below, or will be learned through practice of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Other features, objects and advantages of the present application will become more apparent upon reading the detailed description of non-limiting embodiments made with reference to the following drawings:

[0019] Figure 1 A schematic diagram of the structure of the payment system provided in an embodiment of the present application;

[0020] Figure 2 A flowchart of the payment method provided in the embodiment of the present application;

[0021] Figure 3 A schematic diagram of the key configuration interface provided in this embodiment of the present application;

[0022] Figure 4 A flowchart of the account configuration method provided in an embodiment of the present application;

[0023] Figure 5a A schematic diagram of the effect of the virtual wallet client provided in an embodiment of the present application;

[0024] Figure 5b A schematic diagram of the configuration interface provided in this embodiment of the present application;

[0025] Figure 6 A schematic diagram of the effect of another configuration interface provided in an embodiment of the present application;

[0026] Figure 7 Another schematic diagram of the payment method provided in the embodiment of the present application;

[0027] Figure 8 A schematic diagram of the payment system architecture provided in an embodiment of the present application;

[0028] Figure 9 A schematic diagram of the structure of a payment device provided in an embodiment of the present application;

[0029] Figure 10 A schematic diagram of the structure of the account configuration device provided in an embodiment of the present application;

[0030] Figure 11 A schematic diagram of the structure of another payment device provided in an embodiment of the present application;

[0031] Figure 12 A schematic diagram of the structure of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0032] The present application will be further described in detail below with reference to the accompanying drawings and examples. It should be understood that the specific embodiments described herein are merely for the purpose of explaining the relevant invention and are not intended to limit the invention. It should also be noted that, for ease of description, only the portions relevant to the invention are shown in the accompanying drawings.

[0033] It should be noted that, in the absence of conflict, the embodiments and features of the embodiments in this application can be combined with each other. The present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0034] In recent years, hardware wallets have been one of the main wallets for electronic currency. This is because hardware wallets are more resistant to most known network-mediated attacks and have become the "gold standard" for electronic currency wallet security.

[0035] In the prior art, before using a hardware wallet, it is necessary to recharge the hardware wallet (such as a bus card) before it can be used. However, this method of pre-charging is not only very troublesome, but also has very low payment security.

[0036] Based on this, embodiments of the present application provide a payment method, account configuration method, system, apparatus, device, and medium. The main principles of these methods are as follows: a user can authorize the binding of a payment device in a virtual wallet client. Specifically, this can be done by performing configuration operations on at least one configuration item of the payment device displayed in the virtual wallet client to obtain configuration information, which is then sent to a payment server. The payment server then generates a binding relationship between the virtual wallet and the payment device, as well as transaction restriction rules for the payment device, based on the configuration information. When a user uses the payment device to conduct a transaction, the payment device sends the corresponding payment information to the payment device and the payment server, respectively. The payment device performs a signature operation or a signature encryption operation based on the received payment information to generate payment verification information. This payment verification information is then transmitted to the payment server via the payment device. The payment server uses the payment verification information to verify the payment information from the payment device. If the payment verification information passes verification, the payment server processes the transaction on the virtual wallet bound to the payment device based on the payment information, obtaining a transaction result for the transaction. The methods provided in embodiments of the present application ensure the authenticity of the payment information and avoid erroneous deductions.

[0037] Figure 1 This is a schematic diagram of the structure of a payment system provided in an embodiment of the present application. The payment method provided in an embodiment of the present application can be applied to the payment system 100. Figure 1 The payment system 100 includes a payment device 101, a virtual wallet client 102, a payment subsystem 103, and a payment server 104. The payment subsystem 103 includes at least a payment device 1031 and may also include a payment server 1032. When the payment device 1031 is capable of direct communication with the payment server 104, the payment subsystem 103 may not include the payment server 1032. For example, when the backend server of the payment device 1031 is the payment server 104, the payment device 1031 can communicate directly with the payment server 104. In this case, the payment server 1032 is not required. For another example, when the backend server of the payment device 1031 is not the payment server 104, the payment device 1031 needs to communicate indirectly with the payment server 104 through the payment server 1032.

[0038] In one embodiment, the payment device 101 is a payment tool based on the currency circulation system, which can store user identity authentication information (such as an identifier or private key), and has a certain computing power. It is a hardware product with a unique identifiable number, specifically a hardware wallet, which includes but is not limited to IC cards in the form of bus cards or access cards, or a module installed in an IC card or terminal device. The payment device 101 and the payment device 1031 can use a near-field communication (NFC) network to transmit data. The data between the payment device 101 and the virtual wallet client 102 can be transmitted through a near-field communication network, wired data transmission technology, or by driving a third-party transmission device such as a hardware device. The data transmission method between the payment device 101 and the payment server 104 is similar and will not be repeated here.

[0039] In another embodiment, the virtual wallet client 102 is an application in a terminal device.

[0040] For example, the terminal device may include, but is not limited to, a personal computer, a platform computer, a smart phone, an in-vehicle terminal, and the like, and is not limited to this embodiment of the present application. The payment server 104 and the payment server 1032 may each be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services for payment technology.

[0041] The following will be combined Figure 1The following specific embodiments are used to describe in detail the technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments.

[0042] like Figure 2 As shown, the embodiment of the present application provides a payment method, which is applied to the above-mentioned payment terminal server 102. The method specifically includes the following steps:

[0043] 201. Obtain first payment information and payment verification information sent by a payment device; the payment verification information is generated by the payment device performing signature processing or signature encryption processing on the second payment information from the payment device; the first payment information and the second payment information are payment information of the target transaction.

[0044] It can be understood that the first payment information and the second payment information are payment information of the same transaction (ie, the target transaction).

[0045] It should be noted that, if the first payment information is not changed during the transmission process, the first payment information and the second payment information can be understood as the same payment information, that is, the payment information of the target transaction.

[0046] As an example, the payment information may include basic information of the transaction, and the basic information may include at least one of the following information: payee information, transaction amount, transaction identifier, transaction type, transaction currency, and transaction time. The payee information may be, for example, the identifier of the payment device and the account name corresponding to the payment device (such as the merchant name). The transaction amount is the variable amount of this transaction. The transaction identifier is the identifier of the transaction and is unique. Transaction types include but are not limited to payment, collection, and refund. The transaction currency may include but is not limited to RMB, US dollars, euros, etc. The identifier of the payment device is unique and can uniquely identify the payment device. The identity of the payee can be clarified through the account name of the payment device. In an embodiment of the present application, when obtaining the payment information, the payment-end server also needs to obtain the consent or permission of the payment device and the payment device, and the payment information obtained by the payment-end server also needs to comply with laws, regulations and relevant rules and standards.

[0047] Furthermore, the payment receiving device needs to transmit the payment device identifier sent by the payment device along with the first payment information to the payment-end server. The payment device identifier can be used by the payment-end server to obtain the payment device's public key and determine the virtual wallet bound to the payment device. Furthermore, when the payment device generates payment verification information, in addition to using the second payment information, it also uses the payment device identifier. The payment-end server can then use the payment device's public key to sign the first payment information and the payment device representation to obtain the information to be verified, so that the payment verification information can verify whether the information to be verified is correct.

[0048] In one implementation, the payment device generates payment verification information based on the second payment information from the payment receiving device in combination with the payment device's identification and / or authorization signature salt.

[0049] 202. Verify the first payment information based on the payment verification information and obtain a verification result.

[0050] It should be noted that when the payment server uses the payment verification information to verify the first payment information, it must use the same algorithm as the payment device used to generate the payment verification information. For example, if the payment device uses the signature process in the RSA (Rivest-Shamir-Adleman) algorithm to generate the payment verification information, the payment server uses the signature decryption process in the RSA algorithm to verify the first payment information. For another example, if the payment device uses the signature encryption process in the RSA algorithm to generate the payment verification information, the payment server uses the signature decryption process in the RSA algorithm to verify the first payment information.

[0051] Furthermore, when the payment device generates payment verification information, it uses the payment device's identification and the second payment information. Correspondingly, when the payment server uses the payment verification information to verify the first payment information, it needs to be based on the payment device's identification and the first payment information.

[0052] Optionally, when the payment verification information is obtained by signing and encrypting the first payment information, the payment server can obtain the public key of the payment device through the identification of the payment device when receiving the payment verification information, decrypt the payment verification information through the public key of the payment device to obtain the summary information h corresponding to the second payment information, and perform summary extraction on the received first payment information based on the summary extraction algorithm used by the above-mentioned payment device, so as to obtain the summary information H of the first payment information, and then compare the obtained summary information h with the summary information H obtained by hash calculation to obtain the verification result.

[0053] In one possible implementation, if the digest information h matches the digest information H, the verification result is passed; if the digest information h does not match the digest information H, the verification result is failed. It is understood that if the verification result is failed, the payment server may refuse to conduct the target transaction with the payment device; if the verification result is passed, the payment server may perform subsequent transaction processing on the target transaction.

[0054] In a preferred embodiment, if the digest information h is identical to the digest information H, the verification result is a pass; if the digest information h is different from the digest information H, the verification result is a fail. It is understood that if the verification result is a fail, the payment server may refuse to conduct the target transaction with the payment device; if the verification result is a pass, the payment server may proceed with subsequent transaction processing for the target transaction.

[0055] 203. If the verification result is passed, the transaction is processed on the virtual wallet bound to the payment device according to the first payment information to obtain a transaction result of the target transaction.

[0056] Optionally, the transaction result of the target transaction includes two results: successful transaction and failed transaction. In the event of a transaction failure, the reason for the transaction failure may be sent to the payment device or to the virtual wallet client, although this embodiment of the application is not limited thereto. The reason for the transaction failure may be, for example, insufficient account balance or failure to meet transaction restriction rules.

[0057] Specifically, processing a transaction on a virtual wallet bound to a payment device according to the first payment information includes the following two implementation methods:

[0058] In one implementation, the payment server determines the virtual wallet bound to the payment device based on its identifier, and determines whether the balance in the virtual wallet is greater than or equal to the transaction amount in the first payment information; if so, the transaction amount in the virtual wallet can be directly deducted and the transaction amount can be transferred to the payment device; if not, feedback information of the transaction failure is returned to the payment device. The feedback information may carry the reason for the transaction failure (such as insufficient balance) or may not carry it. This embodiment of the present application does not impose any restrictions on this.

[0059] In another implementation, the payment server determines the virtual wallet bound to the payment device based on the identifier of the payment device, and directly deducts the transaction amount from the balance in the virtual wallet based on the transaction amount in the first payment information. If the balance in the virtual wallet is greater than or equal to the transaction amount, the deduction is successful and the deducted transaction amount is transferred to the payment device. If the balance in the virtual wallet is less than the transaction amount, the deduction fails and feedback information indicating the transaction failure is returned to the payment device. The feedback information may or may not include the reason for the transaction failure (such as insufficient balance), and this embodiment of the application does not impose any restrictions on this. It should be noted that if the reason for the transaction failure carried in the feedback information involves user privacy issues, the user needs to authorize it before the reason for the transaction failure involving user privacy can be carried in the feedback information.

[0060] In the payment method proposed in the embodiment of the present application, when a user uses a payment device to conduct a transaction, the payment device sends the payment information of the transaction to the payment device and the payment end server respectively; the payment device performs signature processing or signature encryption processing on the received payment information (i.e., the second payment information) to generate payment verification information; and the payment verification information is then transmitted to the payment end server through the payment device. The payment end server uses the payment verification information to verify the payment information (i.e., the first payment information) from the payment device. Since the first payment information and the second payment information both correspond to the same transaction (i.e., the target transaction); therefore, through the above-mentioned verification method, not only can it be determined whether the payment device has authorized the payment of the first payment information, but it can also be identified whether the first payment information has been maliciously tampered with during the transmission process, thereby ensuring the authenticity of the payment information and avoiding the situation of erroneous deductions.

[0061] Furthermore, if the first payment information is verified, the payment server processes the transaction in the virtual wallet associated with the payment device based on the first payment information and obtains the transaction result. This allows users to conduct transactions on-site through the payment device and process the transaction (i.e., debit the payment) in the virtual wallet, eliminating the need to pre-charge the payment device and ensuring the security of the payment device.

[0062] In another embodiment of the present application, when the payment device and the payment-end server agree on a signature method for generating payment verification information, a verification result can be obtained by signing the first payment receipt information and verifying the signature information based on the payment verification information. Specifically, the payment verification information is obtained by the payment device signing the second payment receipt information from the payment receipt device, and the first payment receipt information is verified based on the payment verification information to obtain a verification result, including: signing the first payment receipt information using the public key of the payment device to obtain information to be verified; verifying the information to be verified based on the payment verification information, and determining the verification result.

[0063] It is understood that in this embodiment, verifying the information to be verified based on the payment verification information is actually matching the payment verification information with the information to be verified. The specific matching method can be determined according to the selected signature algorithm, and this embodiment of the application does not limit this.

[0064] In a preferred solution, the following matching method can be used for the selected signature algorithm: when the information to be verified is the same as the payment verification information, the verification result is passed; when the information to be verified is different from the payment verification information, the verification result is failed or not passed.

[0065] Optionally, a first predetermined signature algorithm may be used to generate the payment verification information and the information to be verified. The first predetermined signature algorithm may be a first predetermined asymmetric signature algorithm or a first predetermined symmetric signature algorithm. To further ensure the security of the signature information, an asymmetric signature algorithm is preferably used to generate the payment verification information and the information to be verified.

[0066] Specifically, the payment device uses a first preset signature algorithm to sign the second payment information to obtain payment verification information. The payment-end server uses the same signature algorithm as the payment device and uses the public key of the payment device to sign the first summary information to obtain information to be verified. The payment-end server obtains the corresponding verification result by determining whether the payment verification information is the same as the information to be verified. The private key and public key of the payment device can be obtained according to the first preset asymmetric signature algorithm. In the embodiment of the present application, when obtaining the public key of the payment device, the payment-end server also needs to obtain the consent or permission of the payment device and the payment device, and the public key of the payment device obtained by the payment-end server must also comply with laws, regulations and relevant rules and standards.

[0067] Furthermore, the parameters for calculating the payment verification information are not limited to the first payment information, but may also include the payment device's identifier and / or the authorization signature salt. Similarly, the parameters for calculating the information to be verified are not limited to the second payment information, but may also include the payment device's identifier and / or the authorization signature salt. This embodiment of the present application does not impose any limitations on this, and it is sufficient that the parameters for calculating the payment verification information and the information to be verified are identical.

[0068] As an example, assume that the parameters used in calculating both the payment verification information and the information to be verified include the payment information, the payment device's identifier, and the authorization signature salt. Then, the payment device uses its private key (i.e., the authorization private key certificate) to calculate the payment verification information, which can be signed with the authorization private key certificate on the payment device's identifier, the second payment information, and the authorization signature salt to obtain the payment verification information, i.e., payment verification information = signature sign (payment device identifier + second payment information + authorization signature salt, authorization private key certificate); the payment-end server uses the payment device's public key (i.e., the authorization public key certificate) to calculate the information to be verified, which can be signed with the authorization public key certificate on the payment device's identifier, the first payment information, and the authorization signature to obtain the information to be verified, i.e., information to be verified = signature sign (payment device identifier + first payment information + authorization signature salt, authorization public key certificate); finally, the payment-end server determines whether the "payment verification information" is equal to the "information to be verified" to determine the legitimacy of the signature and obtain the verification result, i.e., verification result = verification signature checksign (information to be verified, payment verification information).

[0069] Exemplarily, the first preset signature algorithm may be a DSA (digital signature algorithm) algorithm or an RSA algorithm.

[0070] In this embodiment, the verification result is determined by judging the information to be verified and the payment verification information obtained by signing the first payment information using the public key of the payment device. This can verify the integrity of the information during the transmission process, so as to identify whether the first payment information has been maliciously tampered with during the transmission process, thereby ensuring the authenticity of the payment information and avoiding erroneous deductions.

[0071] In one embodiment of the present application, when the payment verification information generation method agreed upon by the payment device and the payment-end server is a signature encryption method, the payment-end server may also obtain summary information during the payment verification process and compare it with the summary information corresponding to the first payment information to determine the verification result. Therefore, in one implementation, the payment verification information is obtained by the payment device signing and encrypting the second payment information from the payment device, and the first payment information is verified based on the payment verification information to obtain a verification result, including: decrypting the payment verification information using the public key of the payment device to obtain the second summary information; extracting the summary of the first payment information to obtain the first summary information; and verifying the first summary information based on the second summary information to determine the verification result.

[0072] It is understood that in this embodiment, verifying the first summary information based on the second summary information actually means matching the first summary information with the second summary information. The specific matching method can be determined according to the selected signature algorithm and is not limited in this embodiment of the application.

[0073] In a preferred solution, when the first digest information and the second digest information are the same, the verification result is passed; when the first digest information and the second digest information are different, the verification result is failed or not passed.

[0074] Optionally, a second preset digest extraction algorithm can be combined with a second preset signature algorithm to implement signature encryption and signature verification. Specifically, the payment device uses its private key to extract the digest of the first payment information (i.e., sign it) to obtain the first summary information, and uses the private key to encrypt the first summary information to obtain the payment verification information. The payment-end server uses the public key of the payment device to decrypt the payment verification information to obtain the first summary information; then, the second payment information is digested (i.e., signed) to obtain the second summary information. The payment-end server obtains the corresponding verification result by determining whether the first summary information and the second summary information are the same. The private key and public key of the payment device can be obtained according to the second preset asymmetric signature algorithm.

[0075] Furthermore, embodiments of the present application are not limited to extracting the first digest information from the first payment information. The first digest information may also be extracted from the first payment information and / or the payment device's identifier and / or the authorization signature salt. Similarly, the second digest information is not limited to extracting the second digest information from the second payment information. The second digest information may also be extracted from the second payment information and / or the payment device's identifier and / or the authorization signature salt. Embodiments of the present application do not impose any restrictions on this. It is sufficient that the parameters of the first and second digest information are identical.

[0076] As an example, assume that the parameter composition when extracting the first summary information or the second summary information includes the payment information, the identification of the payment device, and the authorization signature salt. Then, the payment device uses its private key (i.e., the authorization private key certificate) to calculate the payment verification information, which can be the identification of the payment device and the second payment information. Salt (i.e., the authorization signature salt) is added to the summary of the second payment information to extract (i.e., sign) to obtain the second summary information, i.e., the second summary information = signature sign (identity of the payment device + second payment information + authorization signature salt), and the second summary information is signed using the authorization private key certificate to obtain the payment verification information, i.e., the payment verification information = encryption encrypt (second summary information, authorization private key certificate); the payment server uses the public key of the payment device (i.e., the authorization public key certificate) to decrypt the payment verification information to obtain the second summary information, i.e., the second summary information = decryption decrypt (payment verification information, authorization public key certificate). The payment device's identification and the first payment information are then salted and digested (i.e., signed) to obtain the first summary information, i.e., first summary information = signature sign (payment device identification + first payment information + authorization signature salt); finally, the payment server determines whether the "payment verification information" is equal to the "information to be verified" to judge the legitimacy of the signature and obtain the verification result, i.e., verification result = verification summary (first summary information, second summary information).

[0077] Exemplarily, the second preset signature algorithm may be the national secret algorithm SM2 or the RSA algorithm. The first preset digest extraction algorithm may be a digest extraction algorithm such as message digest algorithm 5 (MD5), secure hash algorithm 1 (SHA-1), or secure hash algorithm 256 (SHA-256).

[0078] In this embodiment, the payment verification information is decrypted using the public key of the payment device to obtain the second summary information, and the first payment information is digested to obtain the first summary information. The verification result is determined by judging the first summary information and the second summary information. This can verify the integrity of the information during transmission, so as to identify whether the first payment information has been maliciously tampered with during transmission, thereby ensuring the authenticity of the payment information and avoiding erroneous deductions.

[0079] In one embodiment of the present application, before using a payment device for an on-site transaction, it is necessary to configure the payment device information through a virtual wallet client. Therefore, the payment method provided in this embodiment of the present application further includes: the payment server receiving configuration information from the virtual wallet client and configuring the virtual wallet based on the configuration information; the configuration information is used to configure the payment device for the virtual wallet.

[0080] In one implementation, the configuration information can be used to establish a binding relationship between the payment device and the virtual wallet, and / or set the payment authority of the payment device (such as transaction restriction rules), and / or other information settings, which are not limited in the embodiments of the present application. Among them, the payment authority is used to characterize the restriction conditions for using the payment device to conduct transactions. For example, the payment authority can limit the payee whitelist, the transaction type, the interval time between consecutive transactions, the transaction amount, and the number of transactions; the transaction type restriction can include restrictions on merchant type transactions such as restaurants and supermarkets; the transaction amount restriction can include a single transaction amount restriction, a daily transaction amount restriction, a monthly transaction amount restriction, etc.; the number of transactions can be a daily transaction amount restriction, etc.; by establishing a binding relationship between the payment device and the virtual wallet or setting payment authority, the payment device can have a certain limit of payment authority, so that the user holding the payment device can independently complete the payment within a certain authority range, thereby improving payment efficiency, and at the same time providing a more convenient payment and management solution for the user holding the payment device (such as a child or the elderly) and the user of the designated mobile terminal (such as a parent). In an embodiment of the present application, when the payment server obtains the configuration information of the virtual wallet client, it also needs to obtain the consent or permission of the virtual wallet client first, and the configuration information obtained by the payment server must also comply with laws, regulations and relevant rules and standards.

[0081] Furthermore, the configuration information also includes information such as modification or deletion of a target item in the transaction restriction rules of the payment device. Specifically, when the configuration information received by the payment server is modification information or deletion information for a target item in the transaction restriction rules, the target item is modified according to the modification information, or deleted according to the deletion information. Modifying the target item according to the modification information may include replacing the current information in the target item with the modification information.

[0082] For example, the identifier of the payment device and the identifier of the virtual wallet may be stored in a key-value pair to form a binding relationship between the payment device and the virtual wallet.

[0083] Optionally, the virtual wallet client can be a separate application (APP) in the terminal device, or a small program in a certain application, or a web browser. This embodiment of the application does not impose any limitation on this.

[0084] In this embodiment, the virtual wallet is configured by configuring the configuration information from the virtual wallet client, thereby achieving the purpose of configuring the payment device for the virtual wallet, so as to provide a more convenient payment function for the holder of the payment device.

[0085] In another embodiment of the present application, configuring the virtual wallet according to the configuration information includes: the payment server generating a binding relationship between the virtual wallet and the payment device, and transaction restriction rules of the payment device according to the configuration information.

[0086] In actual applications, the correspondence between virtual wallets and payment devices can be one-to-one or one-to-many. In other words, a virtual wallet can be bound to at least one payment device, and the holder of the virtual wallet can configure it according to the actual number of payment devices required.

[0087] In one possible implementation, after generating the transaction restriction rules for the payment device, the payment server can store them locally. When the payment device performs a transaction, the payment server can match the payment information generated by the transaction based on the locally stored transaction restriction rules to determine whether the payment information meets the set transaction restriction rules.

[0088] In another possible implementation, after generating the transaction restriction rules for the payment device, the payment server may transmit part or all of the transaction restriction rules to the payment device.

[0089] For example, assume that the payment server transmits some transaction restriction rules to the payment device. The transaction restriction rules are divided into first and second transaction restriction rules. The payment server transmits the first transaction restriction rules to the payment device and stores the second transaction restriction rules locally. When the payment device performs a transaction, the payment device matches the payment information generated by the transaction against the received first transaction restriction rules to determine whether the second payment information satisfies the first transaction restriction rules. If not, the payment device directly rejects the transaction, thereby reducing the computational burden on the payment server. If so, the second payment information is signed and encrypted to generate payment verification information, which the payment device then sends along with the first payment information to the payment server. The payment server verifies the first payment information based on the payment verification information. If verification is successful, it matches the first payment information against the second transaction restriction rules to determine whether the first payment information satisfies the second transaction restriction rules.

[0090] For another example, assume that the payment server transmits all transaction restriction rules to the payment device. When the payment device performs a transaction, the payment device can match the payment information generated by the transaction based on the received transaction restriction rules to determine whether its second payment information meets the transaction restriction rules. If not, the payment device directly rejects the transaction, thereby reducing the computing pressure on the payment server. If it meets the requirements, the second payment information is signed and encrypted to generate payment verification information, so that the payment device can send the payment verification information and the first payment information to the payment server. The payment server verifies the first payment information based on the payment verification information, and if the verification is successful, it performs transaction processing on the virtual wallet bound to the payment device according to the first payment information, thereby obtaining the transaction result of the target transaction.

[0091] Of course, in order to further ensure the security of payment, transaction restriction rules can also be stored in the payment server and the payment device at the same time. After the transaction occurs on the payment device, the payment server and the payment device will respectively match the rules on the payment information generated by the transaction. The embodiment of this application does not impose any restrictions on this.

[0092] In the embodiments of the present application, by generating a binding relationship between a virtual wallet and a payment device and transaction restriction rules for the payment device, the payment device can be given a certain limit of payment authority, allowing the holder of the payment device to independently complete payments within the scope of certain authority, thereby improving payment efficiency, providing the holder of the payment device with a more convenient payment and management solution, and reducing the risk of malicious transactions.

[0093] In one embodiment of the present application, payment information can be matched against configured transaction restriction rules, thereby further ensuring payment security for the payment device. Therefore, in one implementation, a transaction is processed for a virtual wallet bound to the payment device based on the first payment information: if the first payment information meets the transaction restriction rules, the payment server deducts funds from the virtual wallet based on the first payment information; if it does not meet the transaction restriction rules, the payment server refuses to deduct funds from the virtual wallet.

[0094] Here, the fact that the first payment information does not satisfy at least one of the transaction restriction rules can be understood as the first payment information not satisfying the transaction restriction rules.

[0095] Transaction restriction rules may include at least one of the following: whether the recipient is on the payee whitelist, whether the transaction type is preset, whether the interval between consecutive transactions meets the preset interval, whether the transaction amount is greater than the preset transaction amount, and whether the number of transactions is less than the preset number. Preset transaction types may include hotels, restaurants, entertainment, jewelry, arts and crafts, etc.; preset transaction amounts may include one or more of a single transaction limit, a daily total transaction limit, and a monthly total transaction limit; and the number of transactions may include a daily limit.

[0096] In one implementation scenario, when the amount of a single transaction exceeds the single transaction limit, the payment server refuses to process the transaction and sends a transaction failure message to the charging terminal. At the same time, it can also prompt the charging terminal that the reason for the transaction failure is that the single transaction limit is exceeded.

[0097] In another implementation scenario, the payment server verifies whether the merchant name corresponding to the charging terminal belongs to the merchants in the whitelist. If not, it refuses to process the transaction and sends a transaction failure message to the charging terminal. At the same time, it can also prompt the charging terminal that the reason for the transaction failure is that the merchant is not on the whitelist.

[0098] In this embodiment, to ensure the security and reliability of transactions, the payment information is matched according to the transaction restriction rules of the payment device. For payment information that meets the transaction restriction rules, the payment server deducts the funds from the virtual wallet; for payment information that does not meet the transaction restriction rules, the payment server refuses to deduct the funds from the virtual wallet. By limiting and restricting the scale of offline transactions conducted by the payment device, the risk of malicious transactions is reduced.

[0099] In one embodiment of the present application, in order to reduce the computing pressure of the payment device and the virtual wallet client, the public key and private key of the payment device can be generated by the payment-end server. Therefore, the payment method provided in the embodiment of the present application also includes: the payment-end server generates the public key and private key of the payment device, and sends the private key to the payment device. The private key is used by the payment device to generate payment verification information based on the second payment information, and the public key is used to verify the first payment information.

[0100] Specifically, the payment server uses a preset signature algorithm to generate the private key and public key of the payment device. The preset signature algorithm can be the first preset signature algorithm or the second preset signature algorithm described above. For the relevant embodiments of the first preset signature algorithm or the second preset signature algorithm, reference can be made to the above and will not be repeated here.

[0101] Furthermore, the payment server uses a preset signature algorithm to generate a private key and a public key of the payment device, which may specifically include: the payment server generates a private key and a public key of the payment device according to a threshold cryptographic algorithm based on the preset signature algorithm.

[0102] In an exemplary solution, users can configure key information such as signature algorithm type through the key configuration interface of the virtual wallet client. Figure 3 As shown, Figure 3 Schematic diagram of the key configuration interface of a virtual wallet client in one embodiment. When a user needs to generate a key, the user can obtain part of the key information configured by the user through the key configuration interface 301 of the virtual wallet client, for example, Figure 3 The key name, key description information, and key algorithm type shown in the virtual wallet client can generate a key generation request carrying the key information and transmit the key generation request to the payment server. The payment server can generate the payment device's private key (i.e., authorized private key certificate), public key (i.e., authorized public key certificate), and authorized signature salt based on the key algorithm type selected in the key information configured by the user, and transmit the private key and authorized signature salt to the payment device. To ensure the security of the payment device's private key, the payment server can also delete the local private key of the payment device after the private key and authorized signature salt are transmitted to the payment device.

[0103] In a preferred solution, a (t,n) secret sharing or (t,n) threshold cryptographic algorithm can be used to generate multiple payment device private key components. For example, if (t,n) secret sharing is used, the payment device private key is first generated and then split into n parts. At least t+1 of these parts are required to recover the original payment device private key. Alternatively, if a (t,n) threshold cryptographic algorithm is used, n payment device private key components are directly generated as the payment device private key. At least t+1 of these parts can participate in cryptographic operations based on the payment device private key. During this process, the payment device private key is neither generated nor recovered when used. That is, the payment device private key never appears in full plaintext, but rather exists in the form of key components. Clearly, using the (t,n) threshold cryptographic algorithm to generate the payment device private key is more secure. In this embodiment of the present application, the (t,n) threshold cryptographic algorithm is preferably used to directly generate the payment device private key components as the payment device private key.

[0104] In this embodiment, the payment server generates the public and private keys of the payment device and sends the private key to the payment device. This allows the payment device to perform a signature encryption operation on the second payment information using the private key to obtain payment verification information, thereby ensuring the security of the information transmission process. Furthermore, the payment server can use the public key and payment verification information to verify the first payment information, identifying whether the first payment information has been maliciously tampered with during transmission, thereby ensuring the authenticity of the payment information and avoiding erroneous deductions.

[0105] In another embodiment of the present application, in order to ensure the security of the private key of the payment device, the payment device can generate its private key and public key, and transmit the public key to the payment-end server. Therefore, the payment method provided in the embodiment of the present application also includes: the payment-end server receives the public key sent by the payment device; the public key is used to verify the first payment information; the public key corresponds to the private key of the payment device, and the private key is used by the payment device to generate payment verification information based on the second payment information.

[0106] For the payment server, it only needs to store the public key of the payment device received. When receiving the payment verification information signed by the payment device using the private key, it can directly use the public key of the payment device to verify the payment verification information. There is no need to calculate the public key and private key of the payment device by itself, which reduces the calculation amount of the payment server. At the same time, it avoids the circulation of the private key of the payment device between various devices, thereby further ensuring the security of the private key of the payment device.

[0107] In another embodiment of the present application, considering that a user may lose a payment device or not want to use the payment device for payment during use, the payment method provided in the embodiment of the present application further includes: the payment server receiving an unbinding instruction from the virtual wallet client; and deleting the binding relationship between the virtual wallet and the payment device in response to the unbinding instruction.

[0108] Optionally, in response to the unbinding instruction, the binding relationship between the virtual wallet and the payment device and other configuration information about the payment device (such as transaction restrictions) are deleted. Specifically, the unbinding instruction may include the identification of the payment device, and the binding relationship between the payment device and the virtual wallet and other configuration information about the payment device may be searched based on the identification of the payment device.

[0109] As an example, if a payment device is lost or the user no longer wants to use the payment device to make payments, the user can perform an unbinding operation through the virtual wallet client to generate a corresponding unbinding instruction, and transmit the unbinding instruction to the payment server. The payment server can search for the virtual wallet and the corresponding payment device pointed to by the unbinding instruction, for example, search for the binding relationship between the virtual wallet and the payment device and other configuration information about the payment device based on the identifier of the payment device carried in the unbinding instruction; and release or delete the binding relationship between the virtual wallet and the payment device and other configuration information about the payment device.

[0110] In the event that the payment device is lost, even if other users pick up the payment device and use it to make payments, the payment server cannot find the virtual wallet bound to the payment device and thus cannot make payments, thus ensuring the security of the funds in the virtual wallet.

[0111] It should be noted that, in practice, a single payment account can be bound to one or more payment devices. This means a user can own multiple payment devices, each with a unique identifier. If a payment device is lost, the user can unbind it from the virtual wallet based on the device's identifier and other information. This prevents the loss of funds in the virtual wallet due to the loss of the payment device, ensuring the security of funds while maintaining the usability of other payment devices.

[0112] In this embodiment, the payment server deletes the binding relationship between the virtual wallet and the payment device according to the unbinding instruction from the virtual wallet client, so as to stop the subsequent payment function of the payment device.

[0113] Reference Figure 4 The embodiment of the present application also provides an account configuration method, which is applied to a virtual wallet client, and the method includes:

[0114] 401. The virtual wallet client displays at least one configuration item of the payment device.

[0115] At least one configuration item may be a selection item and / or an input item.

[0116] As an example, a configuration item can be a selection item. A selection item allows a user to select configuration content from a drop-down menu based on actual rule configuration requirements (e.g., a rule configuration requirement for a preset daily transaction count). The rule configuration requirement selected by the user can be a preset daily transaction count, which represents the maximum number of transactions a user can make daily using a payment device.

[0117] In a specific implementation, after the user selects the daily preset number of transactions through the selection item in the configuration interface, the payment server can obtain the daily preset number of transactions selected by the user through the selection item and determine the configuration information based on the daily preset number of transactions selected by the user.

[0118] As another example, a configuration item can be an input item. The input item allows the user to enter configuration details based on actual rule configuration requirements (e.g., a rule configuration requirement for a preset daily transaction count). The rule configuration requirement entered by the user can be a preset daily transaction count, which represents the maximum number of transactions a user can make daily using a payment device.

[0119] In a specific implementation, after the user enters the daily preset number of transactions through the input item of the configuration interface, the payment server can obtain the daily preset number of transactions entered by the user through the input item and determine the configuration information based on the daily preset number of transactions entered by the user.

[0120] Of course, configuration items can also include both selection items and input items. If the user does not select the configuration content they want, they can enter the required configuration content. For example, for the daily preset number of transactions, the drop-down menu may only display the conventional number of times [1, 2, 3, 4, 5], but the user requires 10 times. In this case, the user can enter 10 times in the input item to obtain the desired daily preset number of transactions.

[0121] For example, it is assumed that the virtual wallet client is a separate application (APP) in a smart phone, and the name of the application is set to virtual wallet. Figure 5a , the user can enter (i.e. display) by triggering the identification control 51 of the virtual wallet Figure 5b The configuration interface 52 of the virtual wallet shown in FIG. 5 shows at least one configuration item about the payment device. The configuration item may include: Figure 5b The configuration item 521 of the identification of the payment device and the configuration item 522 of the transaction restriction rule of the payment device are shown, wherein: Figure 5b The configuration item 522 of the transaction restriction rule of the payment device is shown in FIG, including the preset transaction type 5221, the preset number of daily transactions 5222, and the preset transaction amount 5223. It should be noted that, Figure 5bThe configuration items of three transaction restriction rules are only shown as examples, and do not serve as a specific limitation on the configuration items of transaction restriction rules in the embodiments of the present application. When configuring transaction restriction rules, configuration items can be added or existing configuration items can be deleted according to actual needs. At least one configuration item for the payment device can include selection items and / or input items. For example, the configuration item 521 for the identification of the payment device can only have an input item. The preset transaction type 5221, the preset number of daily transactions 5222, and the preset transaction amount 5223 can have both selection items and input items. When the drop-down menu of the selection item contains the configuration content that the user needs to select, the user can obtain the selection for the selection item by selecting the configuration content in the drop-down menu.

[0122] It should be noted that, given the uniqueness of the payment device identifier, multiple unique options can be automatically generated for the user to select when configuring the payment device identifier, or the user can enter the identifier themselves. The virtual wallet client can also verify the uniqueness of the payment device identifier entered by the user. If the payment device identifier entered by the user is not unique, the user can be prompted to enter a new payment device identifier or select one of the options as the payment device identifier.

[0123] 402. The virtual wallet client receives a configuration operation of at least one configuration item and determines configuration information of the payment device according to the configuration operation.

[0124] Specifically, the configuration operation can be an input operation or a selection operation for the configuration item. Here, the input operation can be a character input operation or a voice input operation. When the input operation is a character input operation, the input character can be directly determined through the character input operation; when the input operation is a voice input operation, after obtaining the input voice information, the voice information can be converted into text to obtain the input character.

[0125] The aforementioned selection operation may refer to a touch operation or a cursor operation. A touch operation may be a touch-click operation, a touch-press operation, or a touch-slide operation on a target option. A touch operation may also be a single-touch operation or a multi-touch operation on a target option. A cursor operation may be an operation of controlling a cursor to click on a target option or an operation of controlling a cursor to press a target option. A key operation may be an operation of operating a virtual key or a physical key corresponding to a target option.

[0126] 403. The virtual wallet client sends configuration information to the payment server. The configuration information is used by the payment server to generate a binding relationship between the virtual wallet and the payment device.

[0127] Furthermore, the configuration information is also used to generate transaction restriction rules for the payment device.

[0128] In one implementation, the configuration operation also includes a modification or deletion operation on at least one target item. Correspondingly, the configuration information also includes information such as modification or deletion of each target item in the transaction restriction rules of the payment device. Specifically, the virtual wallet client receives the user's modification or deletion operation on the target item in the transaction restriction items, generates corresponding modification information or deletion information based on the modification or deletion operation, and transmits the modification information or deletion information to the payment server. This allows the payment server to modify the target item according to the modification information, or delete the target item according to the deletion information. Modifying the target item according to the modification information may be replacing the current information in the target item with the modification information. In this embodiment of the present application, when obtaining configuration information, the virtual wallet client also needs to obtain the user's consent or permission first, and the configuration information obtained by the wallet client must also comply with laws, regulations and relevant rules and standards.

[0129] For other embodiments of transaction restriction rules, please refer to the above and will not be described in detail here.

[0130] In the account configuration method proposed in the embodiments of this application, a virtual wallet client displays at least one configuration item of a payment device, allowing the user to configure the payment device according to each configuration item. In response to the user's configuration operation on each configuration item, the virtual wallet client generates configuration information for the payment device and transmits this configuration information to the payment server. The payment server then generates a binding relationship between the virtual wallet and the payment device based on this configuration information, thereby enabling on-site transactions through the payment device. Furthermore, this configuration information is used to generate transaction restriction rules for the payment device, providing users with a more trusted payment environment and ensuring payment security for the payment device.

[0131] In one embodiment of the present application, considering that a user may lose a payment device or no longer wish to use it for payment, the user can directly unbind the device through the virtual wallet client, generating a corresponding unbinding instruction. Specifically, in one implementation, the payment method provided in this embodiment of the present application further includes: the virtual wallet client receiving an unbinding operation for the payment device; generating an unbinding instruction in response to the unbinding operation; and sending the unbinding instruction to the payment server, wherein the unbinding instruction is used to instruct the payment server to delete the binding relationship between the virtual wallet and the payment device.

[0132] For example, assuming that the virtual wallet client is a separate application in a smartphone, refer to Figure 6 , the user can trigger the unbinding control 53 in the configuration interface 52 of the virtual wallet. It is understandable that the specific location of the unbinding control 53 is not limited to Figure 6The configuration interface 52 of the virtual wallet shown in FIG can also be located in other interfaces, such as a separate unbinding interface.

[0133] It should be noted that the virtual wallet client adds the payment device identifier in the unbinding instruction so that the payment server can use the payment device identifier to find the binding relationship between the payment device and the virtual wallet and other configuration information about the payment device.

[0134] In this embodiment, the virtual wallet client provides an unbinding function. If the payment device is lost or the user no longer wishes to use it for payment, the user can simply unbind the payment device from the virtual wallet client. This ensures the security of funds in the software wallet and provides a simple and convenient operation, enhancing the user experience.

[0135] Reference Figure 7 , an embodiment of the present application further provides a payment method, applied to a payment device, the method comprising:

[0136] 701. Receive second payment information from a payment device.

[0137] 702. Perform signature processing or signature encryption processing on the second payment information to generate payment verification information; transmit the payment verification information to the payment device, and the payment verification information is used by the payment device to send to the server, so that the payment server verifies the first payment information based on the payment verification information to obtain a verification result, and if the verification result is passed, perform transaction processing on the virtual wallet bound to the payment device based on the first payment information to obtain a transaction result of the target transaction; the first payment information is sent by the payment device to the server, and the first payment information and the second payment information are the payment information of the target transaction.

[0138] Furthermore, the payment device generates its private key and public key, and transmits its public key to the payment server, so that the payment server uses its public key and payment verification information to verify the first payment information. The specific verification process can refer to the above embodiment and will not be repeated here.

[0139] Specifically, the payment device uses a preset signature algorithm to generate the private key and public key of the payment device. The preset signature algorithm can be the first preset signature algorithm or the second preset signature algorithm described above. For the relevant embodiments of the first preset signature algorithm or the second preset signature algorithm, reference is made to the above and will not be repeated here.

[0140] Furthermore, the payment device uses a preset signature algorithm to generate a private key for the payment device. Specifically, this may include: the payment device generates the private key and public key for the payment device according to a threshold cryptographic algorithm based on the preset signature algorithm. It should be noted that the embodiment of the threshold signature algorithm can refer to the above embodiment of the payment server generating the private key and public key for the payment device, and will not be repeated here.

[0141] In the payment method proposed in the embodiment of the present application, when a user uses a payment device to conduct a transaction, the payment device sends the payment information of the transaction to the payment device and the payment end server respectively; the payment device performs signature processing or signature encryption processing on the received payment information (i.e., the second payment information) to generate payment verification information; and the payment verification information is then transmitted to the payment end server through the payment device. The payment end server uses the payment verification information to verify the payment information (i.e., the first payment information) from the payment device. Since the first payment information and the second payment information both correspond to the same transaction (i.e., the target transaction); therefore, through the above-mentioned verification method, not only can it be determined whether the payment device has authorized the payment of the first payment information, but it can also be identified whether the first payment information has been maliciously tampered with during the transmission process, thereby ensuring the authenticity of the payment information and avoiding the situation of erroneous deductions.

[0142] Furthermore, if the first payment information is verified, the payment server processes the transaction in the virtual wallet associated with the payment device based on the first payment information and obtains the transaction result. This allows users to conduct transactions on-site through the payment device and process the transaction (i.e., debit the payment) in the virtual wallet, eliminating the need to pre-charge the payment device and ensuring the security of the payment device.

[0143] Reference Figure 8 , an embodiment of the present application further provides a payment system, the system comprising:

[0144] The payment device 101 is configured to receive second payment information from the payment receiving device 1031 .

[0145] The payment device 101 is further configured to perform signature processing or signature encryption processing on the second payment information, generate payment verification information, and transmit the payment verification information to the payment device 1031 .

[0146] The payment device 1031 is used to send the payment verification information and the first payment information to the payment end server 104; the first payment information and the second payment information are the payment information of the target transaction.

[0147] The payment server 104 is configured to verify the first payment information based on the payment verification information and obtain a verification result; if the verification result is passed, the payment server 104 performs transaction processing on the virtual wallet bound to the payment device 101 according to the first payment information to obtain a transaction result of the target transaction.

[0148] In one embodiment of the present application, the virtual wallet client 102 is configured to display at least one configuration item of the payment device 101 .

[0149] The virtual wallet client 102 is further configured to receive a configuration operation of at least one configuration item and determine configuration information of the payment device 101 according to the configuration operation.

[0150] The virtual wallet client 102 is further configured to send configuration information to the payment server 104 .

[0151] The payment server 104 is configured to generate a binding relationship between the virtual wallet and the payment device 101 according to the configuration information.

[0152] It should be noted that other steps and related embodiments of the payment device, virtual wallet, virtual wallet client, payment device and payment server in the payment system can refer to the above method and will not be repeated here.

[0153] for Figure 8 The payment system architecture diagram shown in also includes a payment receiving server 1032. When the payment receiving device 1301 cannot communicate directly with the payment receiving server 104, data can be transmitted between the payment receiving server 1032 and the payment receiving server 104.

[0154] It should be noted that although the operations of the method of the present application are described in a particular order in the drawings, this does not require or imply that these operations must be performed in this particular order, or that all illustrated operations must be performed to achieve the desired results.

[0155] Figure 9 This is a block diagram of a payment device according to an embodiment of the present application, which is provided in a payment-end server.

[0156] like Figure 9 As shown, the payment device includes: an acquisition unit 901, a verification unit 902, a transaction processing unit 903, and an information configuration unit 904.

[0157] An acquiring unit 901 is configured to acquire first payment information and payment verification information sent by a payment receiving device; the payment verification information is generated by the paying device performing signature processing or signature encryption processing on the second payment information from the payment receiving device; the first payment information and the second payment information are payment information for the target transaction;

[0158] A verification unit 902, configured to verify the first payment information based on the payment verification information and obtain a verification result;

[0159] The transaction processing unit 903 is configured to, if the verification result is passed, perform transaction processing on the virtual wallet bound to the payment device according to the first payment information to obtain a transaction result of the target transaction.

[0160] In one embodiment, the payment verification information is obtained by the payment device signing the second payment information from the payment device. The verification unit 902 is specifically used to use the public key of the payment device to sign the first payment information to obtain the information to be verified; verify the information to be verified according to the payment verification information to determine the verification result.

[0161] In one embodiment, the payment verification information is obtained by the payment device signing and encrypting the second payment information from the payment device, and the verification unit 902 is specifically used to

[0162] The payment verification information is decrypted using the public key of the payment device to obtain the second summary information; the first payment information is abstracted to obtain the first summary information; the first summary information is verified based on the second summary information to determine the verification result.

[0163] In one embodiment, the obtaining unit 901 is further configured to receive configuration information from a virtual wallet client.

[0164] The information configuration unit 904 is used to configure the virtual wallet according to the configuration information; the configuration information is at least used to configure a payment device for the virtual wallet.

[0165] In one embodiment, the information configuration unit 904 is specifically configured to generate a binding relationship between the virtual wallet and the payment device, and transaction restriction rules of the payment device according to the configuration information.

[0166] In one embodiment, the transaction processing unit 903 is specifically configured to deduct funds from the virtual wallet according to the first payment information if the first payment information satisfies the transaction restriction rules; and refuse to deduct funds from the virtual wallet if the first payment information does not satisfy the transaction restriction rules.

[0167] In one embodiment, the information configuration unit 904 is further configured to generate a public key and a private key of the payment device.

[0168] The sending unit is configured to send a private key to the payment device, where the private key is used by the payment device to generate the payment verification information based on the second payment information, and the public key is used to verify the first payment information.

[0169] In one embodiment, the acquisition unit 901 is further used to receive a public key sent by a payment device; the public key is used to verify the first payment information; the public key corresponds to a private key of the payment device, and the private key is used by the payment device to generate the payment verification information based on the second payment information.

[0170] In one embodiment, the obtaining unit 901 is further configured to receive an unbinding instruction from a virtual wallet client.

[0171] The information configuration unit 904 is configured to delete the binding relationship between the virtual wallet and the payment device in response to the unbinding instruction.

[0172] The payment device proposed in the embodiment of the present application is that when a user uses a payment device to conduct a transaction, the payment device sends the payment information of the transaction to the payment device and the payment device respectively; the payment device performs signature processing or signature encryption processing on the received payment information (i.e., the second payment information) to generate payment verification information; and the payment verification information is then transmitted to the payment device through the payment device. The payment device uses the payment verification information to verify the payment information (i.e., the first payment information) from the payment device. Since the first payment information and the second payment information both correspond to the same transaction (i.e., the target transaction); therefore, through the above-mentioned verification method, not only can it be determined whether the payment device has authorized the payment of the first payment information, but it can also be identified whether the first payment information has been maliciously tampered with during the transmission process, thereby ensuring the authenticity of the payment information and avoiding the situation of erroneous deductions.

[0173] Furthermore, if the first payment information is verified successfully, the payment device processes the transaction in the virtual wallet associated with the payment device based on the first payment information and obtains the transaction result. This allows the user to conduct transactions on-site through the payment device and process the transaction (i.e., debit the payment) in the virtual wallet, eliminating the need to pre-charge the payment device and ensuring the security of the payment device.

[0174] It should be understood that the units recorded in the payment device and the reference Figure 2 The steps in the described method correspond to each other. Therefore, the operations and features described above for the method are also applicable to the payment device and the units contained therein, and will not be repeated here. The payment device can be pre-implemented in the browser or other security application of the computer device, or loaded into the browser or its security application of the computer device through downloading or other means. The corresponding units in the payment device can cooperate with the units in the computer device to implement the solutions of the embodiments of the present application.

[0175] Figure 10This is a block diagram of an account configuration device according to an embodiment of the present application, which is provided in a virtual wallet client.

[0176] like Figure 10 As shown, the account configuration device includes: a display unit 1001, a receiving unit 1002, a processing unit 1003, and a sending unit 1004.

[0177] The display unit 1001 is configured to display at least one configuration item of the payment device.

[0178] The receiving unit 1002 is configured to receive a configuration operation of at least one configuration item.

[0179] The processing unit 1003 is configured to determine configuration information of the payment device according to the configuration operation.

[0180] The sending unit 1004 is used to send configuration information to the payment end server, where the configuration information is used by the payment end server to generate a binding relationship between the virtual wallet and the payment device.

[0181] In one embodiment, the configuration information is further used to generate transaction restriction rules for the payment device.

[0182] In one embodiment, the receiving unit 1002 is further configured to receive an unbinding operation for the payment device.

[0183] The processing unit 1003 is configured to generate an unbinding instruction in response to the unbinding operation.

[0184] The sending unit 1004 is used to send an unbinding instruction to the payment end server, where the unbinding instruction is used to instruct the payment end server to delete the binding relationship between the virtual wallet and the payment device.

[0185] The account configuration device provided in the embodiments of the present application can display at least one configuration item of a payment device, allowing the user to configure the payment device according to each configuration item. The account configuration device generates configuration information for the payment device based on the configuration operation of each configuration item. This configuration information is then transmitted to the payment server, which then generates a binding relationship between the virtual wallet and the payment device based on the configuration information, thereby enabling on-site transactions through the payment device. Furthermore, this configuration information is used to generate transaction restriction rules for the payment device, providing users with a more trusted payment environment and ensuring payment security using the payment device.

[0186] It should be understood that the units recorded in the account configuration device are Figure 4The steps in the method described above correspond to each other. Therefore, the operations and features described above for the method are also applicable to the account configuration device and the units contained therein, and will not be repeated here. The account configuration device can be pre-implemented in the browser or other security application of the computer device, or loaded into the browser or its security application of the computer device through downloading or other means. The corresponding units in the account configuration device can cooperate with the units in the computer device to implement the solutions of the embodiments of the present application.

[0187] Figure 11 This is a block diagram of a payment device according to an embodiment of the present application, which is provided in a payment device.

[0188] like Figure 11 As shown, the payment device includes: a receiving unit 1101, a signature unit 1102, and a transmission unit 1103.

[0189] The receiving unit 1101 is configured to receive second payment information from a payment device.

[0190] The signature unit 1102 is used to perform signature processing or signature encryption processing on the second payment information to generate payment verification information.

[0191] Transmission unit 1103 is used to transmit payment verification information to the payment receiving device. The payment verification information is used for the payment receiving device to send to the server, so that the payment-end server verifies the first payment information based on the payment verification information to obtain a verification result. If the verification result is passed, the payment server performs transaction processing on the virtual wallet bound to the payment device based on the first payment information to obtain a transaction result of the target transaction; the first payment information is sent by the payment receiving device to the server, and the first payment information and the second payment information correspond to the target transaction.

[0192] The payment device proposed in the embodiment of the present application, when a user uses the payment device to conduct a transaction, the payment device sends the payment information of the transaction to the payment device and the payment end server respectively; the payment device performs signature processing or signature encryption processing on the received payment information (i.e., the second payment information) to generate payment verification information; and the payment verification information is then transmitted to the payment device through the payment device. The payment end server uses the payment verification information to verify the payment information (i.e., the first payment information) from the payment device. Since the first payment information and the second payment information both correspond to the same transaction (i.e., the target transaction); therefore, through the above-mentioned verification method, not only can it be determined whether the payment device has authorized the payment of the first payment information, but it can also be identified whether the first payment information has been maliciously tampered with during the transmission process, thereby ensuring the authenticity of the payment information and avoiding the situation of erroneous deductions.

[0193] Furthermore, if the first payment information is verified, the payment device processes the transaction in the virtual wallet associated with the payment device based on the first payment information and obtains the transaction result. This allows users to conduct transactions on-site through the payment device and process the transaction (i.e., debit the payment) in the virtual wallet, eliminating the need to pre-charge the payment device and ensuring the security of the payment device.

[0194] It should be understood that the units recorded in the payment device and the reference Figure 7 The steps in the described method correspond to each other. Therefore, the operations and features described above for the method are also applicable to the payment device and the units contained therein, and will not be repeated here. The payment device can be pre-implemented in the browser or other security application of the computer device, or loaded into the browser or its security application of the computer device through downloading or other means. The corresponding units in the payment device can cooperate with the units in the computer device to implement the solutions of the embodiments of the present application.

[0195] The several modules or units mentioned in the detailed description above are not necessarily divided into a single module or unit. In fact, according to the embodiments of the present application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided into multiple modules or units to be embodied.

[0196] It should be noted that for details not disclosed in the payment device of the embodiment of the present application, please refer to the details disclosed in the above embodiments of the present application, which will not be repeated here.

[0197] Reference below Figure 12 , Figure 12 A schematic diagram of the structure of a computer device suitable for implementing the embodiments of the present application is shown in FIG. Figure 12 As shown, computer system 1200 includes a central processing unit (CPU) 1201, which can perform various appropriate actions and processes according to programs stored in read-only memory (ROM) 1202 or programs loaded from storage unit 12012 into random access memory (RAM) 1203. Various programs and data required for the operation instructions of the system are also stored in RAM 1203. CPU 1201, ROM 1202, and RAM 1203 are connected to each other via bus 1204. Input / output (I / O) interface 1205 is also connected to bus 1204.

[0198] The following components are connected to the I / O interface 1205: an input section 1206 including a keyboard, a mouse, and the like; an output section 1207 including components such as a cathode ray tube (CRT), a liquid crystal display (LCD), and a speaker; a storage section 12012 including components such as a hard disk; and a communication section 12012 including a network interface card such as a LAN card or a modem. The communication section 12012 performs communication processing via a network such as the Internet. A drive 1210 is also connected to the I / O interface 1205 as needed. A removable medium 1211, such as a magnetic disk, an optical disk, a magneto-optical disk, or a semiconductor memory, is installed in the drive 1210 as needed, so that computer programs read therefrom can be installed in the storage section 12012 as needed.

[0199] In particular, according to the embodiment of the present application, the above reference flow chart Figure 2 、 Figure 4 and Figure 7 The described process can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes program code for executing the method shown in the flowchart. In such an embodiment, the computer program includes program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via the communication part 12012, and / or installed from a removable medium 1211. When the computer program is executed by the central processing unit (CPU) 1201, the above-mentioned functions defined in the system of the present application are executed.

[0200] It should be noted that the computer-readable medium described in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or device, or any combination of the above. More specific examples of computer-readable storage media can include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this application, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, device, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, which carries computer-readable program code. This propagated data signal can take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transfer a program for use by or in conjunction with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wire, optical cable, RF, or any suitable combination thereof.

[0201] The flowcharts and block diagrams in the accompanying drawings illustrate the possible implementation architecture, functions and operating instructions of the systems, methods and computer program products according to various embodiments of the present application. In this regard, each box in the flowchart or block diagram can represent a module, program segment, or a part of code, and the aforementioned module, program segment, or a part of code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order than the order marked in the accompanying drawings. For example, the boxes represented by two connections can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, and the combination of the boxes in the block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or operating instruction, or can be implemented using a combination of dedicated hardware and computer instructions.

[0202] The units or modules described in the embodiments of this application may be implemented in software or hardware. The units or modules described may also be provided in a processor. For example, a processor may be described as including an illegal person detection unit, a multimodal detection unit, and an identification unit. The names of these units or modules do not, in certain circumstances, limit the units or modules themselves.

[0203] As another aspect, the present application further provides a computer-readable storage medium, which may be included in the computer device described in the above embodiment, or may exist independently without being assembled into the computer device. The above computer-readable storage medium stores one or more programs, and when the above programs are used by one or more processors to execute the payment method described in the present application. For example, Figure 2 The steps of the payment method shown, or you can perform Figure 4 The steps of the account configuration method shown, or you can execute Figure 7 The steps of the payment method are shown.

[0204] The present application embodiment provides a computer program product, which includes instructions. When the instructions are executed, the method described in the embodiment of the present application is executed. For example, you can execute Figure 2 The steps of the payment method shown, or you can perform Figure 4 The steps of the account configuration method shown, or you can execute Figure 7 The steps of the payment method are shown.

[0205] The above description is merely a preferred embodiment of the present application and an illustration of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this application is not limited to the technical solutions formed by a specific combination of the above-mentioned technical features, but also encompasses other technical solutions formed by any combination of the above-mentioned technical features or their equivalents without departing from the aforementioned disclosed concepts. For example, a technical solution formed by replacing the above-mentioned features with (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. A payment method, applied to a payment server, characterized in that: The method comprises: Obtaining first payment information and payment verification information sent by a payment receiving device; the payment verification information is generated by the paying device performing signature processing or signature encryption processing on the second payment information from the payment receiving device; the first payment information and the second payment information are the same payment information for the target transaction; Verifying the first payment information based on the payment verification information to obtain a verification result; wherein, if the payment verification information is obtained by the payment device signing and encrypting second payment information from the payment device, verifying the first payment information based on the payment verification information to obtain a verification result includes: decrypting the payment verification information using a public key of the payment device to obtain second summary information, where the public key of the payment device is generated by the payment server or the payment device; extracting a summary of the first payment information to obtain first summary information; and verifying the first summary information based on the second summary information to determine the verification result; If the verification result is passed and the first payment information satisfies the transaction restriction rules of the payment device, deducting the funds from the virtual wallet bound to the payment device according to the first payment information; the binding relationship between the virtual wallet and the payment device and the transaction restriction rules are generated by the payment server based on the configuration information sent by the virtual wallet client; The virtual wallet client is used to display at least one configuration item of the payment device, receive a configuration operation for the at least one configuration item, and determine configuration information of the payment device based on the configuration operation. The payment device is a hardware wallet and does not require pre-charge.

2. The payment method according to claim 1, wherein: The payment verification information is obtained by the paying device signing the second payment information from the payment receiving device, and the verifying the first payment information based on the payment verification information to obtain the verification result includes: Signing the first payment information using the public key of the payment device to obtain information to be verified; The information to be verified is verified according to the payment verification information to determine the verification result.

3. The payment method according to claim 1, wherein: The method further comprises: If the transaction restriction rules are not met, the deduction process for the virtual wallet will be rejected.

4. The payment method according to any one of claims 1 to 3, characterized in that: The method further comprises: Generate a public key and a private key for the payment device, and send the private key to the payment device. The private key is used by the payment device to generate the payment verification information based on the second payment information, and the public key is used to verify the first payment information. The public key and the private key are generated by the payment end server.

5. The payment method according to any one of claims 1 to 3, characterized in that: The method further comprises: Receive a public key sent by the payment device; the public key is used to verify the first payment information; the public key corresponds to the private key of the payment device, the private key is used by the payment device to generate the payment verification information based on the second payment information, and the public key and the private key are generated by the payment device.

6. The payment method according to any one of claims 1 to 3, characterized in that: The method further comprises: Receiving an unbinding instruction from the virtual wallet client; In response to the unbinding instruction, the binding relationship between the virtual wallet and the payment device is deleted.

7. An account configuration method, applied to a virtual wallet client, characterized in that: The method comprises: displaying at least one configuration item of a payment device; receiving a configuration operation of the at least one configuration item, and determining configuration information of the payment device according to the configuration operation; The configuration information is sent to the payment end server so that the payment end server generates the binding relationship between the virtual wallet and the payment device and the transaction restriction rules of the payment device according to the configuration information; and the payment end server deducts the virtual wallet bound to the payment device according to the first payment information when the verification result is passed and the first payment information meets the transaction restriction rules of the payment device; the verification result is obtained by verifying the first payment information based on the payment verification information, the first payment information and the payment verification information are sent to the payment end server by the payment device, and the payment verification information is the payment device deducting the second payment information from the payment device. generated by signature processing or signature encryption processing; the first payment information and the second payment information are the same payment information for the target transaction; when the payment verification information is obtained by the payment device signing and encrypting the second payment information from the payment device, the verification result is determined by the payment-end server verifying the first summary information based on the second summary information, the first summary information is obtained by the payment-end server extracting the summary of the first payment information, and the second summary information is obtained by the payment-end server decrypting the payment verification information using the public key of the payment device; the public key of the payment device is generated by the payment-end server or by the payment device; Wherein, the payment device is a hardware wallet, and the payment device does not need to be recharged in advance.

8. The account configuration method according to claim 7, characterized in that: The method further comprises: receiving an unbinding operation for the payment device; In response to the unbinding operation, generating an unbinding instruction; The unbinding instruction is sent to the payment server, where the unbinding instruction is used to instruct the payment server to delete the binding relationship between the virtual wallet and the payment device.

9. A payment system, characterized in that: include: a payment device, configured to receive second payment information from a payment receiving device; The payment device is further configured to perform signature processing or signature encryption processing on the second payment information to generate payment verification information, and transmit the payment verification information to the payment device; The payment receiving device is used to send the payment verification information and the first payment receiving information to the payment end server; The first payment information and the second payment information are the same payment information of the target transaction; The payment server is configured to verify the first payment information based on the payment verification information to obtain a verification result; if the verification result is positive and the first payment information satisfies the transaction restriction rules of the payment device, deduct the payment from the virtual wallet bound to the payment device based on the first payment information; the binding relationship between the virtual wallet and the payment device and the transaction restriction rules are generated by the payment server based on the configuration information sent by the virtual wallet client; In a case where the payment verification information is obtained by signing and encrypting second payment information from the payment receiving device by the payment device, the verifying the first payment information based on the payment verification information to obtain a verification result includes: decrypting the payment verification information using a public key of the payment device to obtain second summary information; the public key of the payment device is generated by the payment server or the payment device; extracting a summary of the first payment information to obtain first summary information; and verifying the first summary information based on the second summary information to determine the verification result. The virtual wallet client is configured to display at least one configuration item of the payment device, receive a configuration operation for the at least one configuration item, and determine configuration information of the payment device according to the configuration operation. Wherein, the payment device is a hardware wallet, and the payment device does not need to be recharged in advance.

10. A payment device, characterized in that: Applied to the payment server, the payment device includes: an acquiring unit, configured to acquire first payment information and payment verification information sent by a payment receiving device; the payment verification information is generated by the paying device performing signature processing or signature encryption processing on second payment information from the payment receiving device; the first payment information and the second payment information are the same payment information for a target transaction; a verification unit configured to verify the first payment information based on the payment verification information to obtain a verification result; if the payment verification information is obtained by the payment device signing and encrypting second payment information from the payment device, the verification unit is configured to: decrypt the payment verification information using a public key of the payment device to obtain second summary information, where the public key of the payment device is generated by the payment server or the payment device; extract a summary of the first payment information to obtain first summary information; and verify the first summary information based on the second summary information to determine the verification result; a transaction processing unit, configured to, if the verification result is passed and the first payment information satisfies the transaction restriction rules of the payment device, deduct funds from the virtual wallet bound to the payment device based on the first payment information; the binding relationship between the virtual wallet and the payment device and the transaction restriction rules are generated by the information configuration unit based on configuration information sent by the virtual wallet client; The virtual wallet client is used to display at least one configuration item of the payment device, receive a configuration operation for the at least one configuration item, and determine configuration information of the payment device based on the configuration operation. The payment device is a hardware wallet and does not require pre-charge.

11. The payment device according to claim 10, characterized in that: The payment verification information is obtained by the payment device signing the second payment information from the payment device. The verification unit is specifically used to: use the public key of the payment device to sign the first payment information to obtain the information to be verified; verify the information to be verified according to the payment verification information, and determine the verification result.

12. The payment device according to claim 10, characterized in that: The transaction processing unit is further configured to: If the transaction restriction rules are not met, the deduction process for the virtual wallet will be rejected.

13. The payment device according to any one of claims 10 to 12, characterized in that: The payment device further includes an information configuration unit and a sending unit, wherein the information configuration unit is further configured to generate a public key and a private key of the payment device; A sending unit is used to send the private key to the payment device, where the private key is used by the payment device to generate the payment verification information based on the second payment information, and the public key is used to verify the first payment information.

14. The payment device according to any one of claims 10 to 12, characterized in that: The acquisition unit is further used to receive a public key sent by the payment device; the public key is used to verify the first payment information; the public key corresponds to the private key of the payment device, and the private key is used by the payment device to generate the payment verification information based on the second payment information. The public key and the private key are generated by the payment device.

15. The payment device according to any one of claims 10 to 12, characterized in that: The payment device further includes an information configuration unit, and the acquisition unit is further configured to receive an unbinding instruction from the virtual wallet client; An information configuration unit is configured to delete the binding relationship between the virtual wallet and the payment device in response to the unbinding instruction.

16. An account configuration device, applied to a virtual wallet client, characterized in that: The account configuration device includes: a display unit, configured to display at least one configuration item of the payment device; a receiving unit, configured to receive a configuration operation of the at least one configuration item; a processing unit, configured to determine configuration information of the payment device according to the configuration operation; The sending unit is configured to send the configuration information to the payment end server, so that the payment end server generates a binding relationship between the virtual wallet and the payment device and a transaction restriction rule of the payment device according to the configuration information; and so that the payment end server deducts the virtual wallet bound to the payment device according to the first payment information when the verification result is passed and the first payment information meets the transaction restriction rule of the payment device; the verification result is obtained by verifying the first payment information based on the payment verification information, the first payment information and the payment verification information are sent to the payment end server by the payment device, and the payment verification information is the payment device's response to the second payment information from the payment device. the first payment information and the second payment information are the same payment information for the target transaction; if the payment verification information is obtained by the payment device signing and encrypting the second payment information from the payment device, the verification result is determined by the payment-end server verifying the first summary information based on the second summary information; the first summary information is obtained by the payment-end server extracting the summary of the first payment information, and the second summary information is obtained by the payment-end server decrypting the payment verification information using the public key of the payment device; the public key of the payment device is generated by the payment-end server or the payment device; Wherein, the payment device is a hardware wallet, and the payment device does not need to be recharged in advance.

17. The account configuration device according to claim 16, characterized in that: The receiving unit is further configured to receive an unbinding operation for the payment device; a processing unit, configured to generate an unbinding instruction in response to the unbinding operation; A sending unit is used to send the unbinding instruction to the payment end server, where the unbinding instruction is used to instruct the payment end server to delete the binding relationship between the virtual wallet and the payment device.

18. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the program, the method according to any one of claims 1 to 8 is implemented.

19. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method according to any one of claims 1 to 8 is implemented.

20. A computer program product, characterized in that The computer program product comprises instructions, which, when executed, cause the method according to any one of claims 1 to 8 to be performed.

Images