Transaction processing method and device

Abstract

The embodiment of the present invention provides a transaction processing method and device. The method includes: sending a payment request to a payment device, and obtaining a first time point for sending the payment request; receiving a payment password sent by the payment device, and obtaining a second time point for receiving the payment password; determining the target distance between the payment device and the payment device according to the first time point and the second time point; if the target distance is less than a preset threshold, sending the payment password to the payment backend, so that the payment backend executes the corresponding transaction according to the payment password. If the target distance is less than the preset threshold, it means that the payment device processing the payment request is not another payment device that is far away from the payment device and may be attacked by relays, and the current transaction environment is safe, and then the payment password is sent to the payment backend for transaction processing. In this way, the risk of the payment device being attacked by relays is reduced.

Description

Technical Field

[0001] Embodiments of the present invention relate to the field of secure payment technology, and in particular, to a transaction processing method, apparatus, computing device, and computer-readable storage medium. Background Art

[0002] With the rapid development of Internet technology, more and more people choose electronic payment when shopping. Existing electronic payment methods include scanning QR code payment, NFC (Near Field Communication) payment, etc., but these payment methods are vulnerable to relay attacks, thus affecting the security of transactions.

[0003] Take NFC payment as an example. Figure 1 As shown, the payment receiving device sends a payment request to payment device A, and payment device A sends the payment request to payment device B. Since payment device B is set to password-free payment, payment device B will directly respond to payment device A, and then payment device A will send the response of payment device B to the payment receiving device. The payment receiving device will directly deduct money from payment device B, thereby causing property loss to the user on the payment device B side.

[0004] In summary, the embodiments of the present invention provide a transaction processing method to reduce the risk of relay attacks and improve the security of transactions. Summary of the invention

[0005] The embodiment of the present invention provides a transaction processing method, which is used to reduce the risk of a payment device being attacked by relays and improve the security of transactions.

[0006] In a first aspect, an embodiment of the present invention provides a transaction processing method, including:

[0007] Sending a payment request to a payment device, and obtaining a first time point when the payment request is sent;

[0008] receiving a payment password sent by the payment device, and obtaining a second time point at which the payment password is received;

[0009] Determining a target distance between a payment receiving device and a payment device according to the first time point and the second time point;

[0010] If the target distance is less than a preset threshold, the payment password is sent to the payment backend, so that the payment backend executes a corresponding transaction according to the payment password.

[0011] In the embodiment of the present application, the payment device can determine the target distance between the payment device and the payment device by obtaining the first time point of sending the payment request and the second time point of receiving the payment password. If the target distance is less than the preset threshold, it means that the payment device processing the payment request is close to the payment device, that is, the payment device processing the payment request is not another payment device that is far away from the payment device and may be attacked by relays. The current transaction environment is safe, and then the payment password is sent to the payment backend for transaction processing. In this way, the risk of the payment device being attacked by relays is reduced, and the security of the transaction is improved.

[0012] Optionally, the method further comprises:

[0013] Receiving the time taken to generate the payment password sent by the payment device;

[0014] The determining, according to the first time point and the second time point, a target distance between the payment device and the payment device includes:

[0015] A target distance between the payment device and the payment device is determined according to the first time point, the second time point, and the elapsed time.

[0016] Optionally, determining a target distance between the payment device and the payment device according to the first time point, the second time point, and the elapsed time includes:

[0017] Determine the transmission time of the payment password from the payment device to the payment receiving device according to the first time point, the second time point and the elapsed time;

[0018] The target distance between the payment device and the payment receiving device is determined according to the transmission duration and the transmission speed of the payment password.

[0019] Optionally, the payment request carries an encryption factor, so that the payment device generates the payment password based on the encryption factor;

[0020] If the target distance is less than a preset threshold, the payment password is sent to a payment backend, so that the payment backend executes a corresponding transaction according to the payment password, including:

[0021] If the target distance is less than a preset threshold, the payment password, the encryption factor and the payment bill will be sent to the payment backend, so that the payment backend will verify the payment password based on the encryption factor, and after the verification is passed, perform the corresponding deduction operation according to the payment bill and the payment password.

[0022] Optionally, sending a payment request to a payment device and obtaining a first time point of sending the payment request includes:

[0023] Sending a payment request to a payment device via a first ultra-wideband UWB message, and acquiring the first time point from a MAC layer data frame of the first UWB message;

[0024] The receiving the payment password sent by the payment device and obtaining the second time point of receiving the payment password includes:

[0025] The payment password sent by the payment device is received through a second UWB message, and the second time point is obtained from the MAC layer data frame of the second UWB message.

[0026] In a second aspect, an embodiment of the present invention further provides a transaction processing method, including:

[0027] Receive a payment request sent by a payment device;

[0028] Generate a payment password according to the payment request;

[0029] The payment password is sent to the payment receiving device, so that the payment receiving device determines the target distance between the payment receiving device and the payment device based on the first time point of sending the payment request and the second time point of receiving the payment password, and when it is determined that the target distance is less than a preset threshold, the payment password is sent to the payment backend, and the payment backend is used to execute the corresponding transaction according to the payment password.

[0030] Optionally, it also includes:

[0031] Obtaining a third time point at which the payment request is received;

[0032] Obtaining a fourth time point at which the payment password is sent;

[0033] Based on the third time point and the fourth time point, the time taken to generate the payment password is determined, and the time taken is sent to the payment device, so that the payment device determines the target distance between the payment device and the payment device based on the first time point of sending the payment request, the second time point of receiving the payment password and the time taken.

[0034] Optionally, the payment request carries an encryption factor;

[0035] Generating a payment password according to the payment request includes:

[0036] generating a session key based on the encryption factor and the identification of the payment device;

[0037] Encrypting the identification of the payment device by using the session key to obtain a payment ciphertext;

[0038] The payment password is generated based on the identification of the payment device and the payment ciphertext.

[0039] Optionally, encrypting the identifier of the payment device by using the session key to obtain the payment ciphertext includes:

[0040] The identification of the payment device and the payment account information corresponding to the payment device are encrypted by using the session key to obtain a payment ciphertext.

[0041] Optionally, obtaining the third time point of receiving the payment request includes:

[0042] Receiving the payment request through a third UWB message, and acquiring the third time point from a MAC layer data frame of the third UWB message;

[0043] The obtaining of the fourth time point for sending the payment password comprises:

[0044] The payment password is sent via a fourth UWB message, and the fourth time point is obtained from a MAC layer data frame of the fourth UWB message.

[0045] In a third aspect, an embodiment of the present invention further provides a transaction processing method, including:

[0046] Receive a payment password sent by a payment receiving device, wherein the payment password is generated by the payment device and sent to the payment receiving device after receiving a payment request sent by the payment receiving device, and is sent to the payment backend by the payment receiving device when it is determined that a target distance between the payment receiving device and the payment device is less than a preset threshold, wherein the target distance is determined by the payment receiving device according to a first time point of sending the payment request and a second time point of receiving the payment password;

[0047] Execute corresponding transactions according to the payment password.

[0048] Optionally, the target distance is determined by the payment receiving device according to a first time point of sending the payment request and a second time point of receiving the payment password, including:

[0049] The target distance is determined by the payment device according to a first time point of sending the payment request, a second time point of receiving the payment password, and a time duration of generating the payment password.

[0050] Optionally, executing a corresponding transaction according to the payment password includes:

[0051] Receiving the encryption factor and payment bill sent by the payment receiving device;

[0052] The payment password is verified based on the encryption factor, and after the verification is passed, a corresponding deduction operation is performed according to the payment bill and the payment password.

[0053] Optionally, the payment password includes a plain text identifier and a payment ciphertext;

[0054] The payment password is verified based on the encryption factor, and after the verification is passed, a corresponding deduction operation is performed according to the payment bill and the payment password, including:

[0055] generating a session key according to the encryption factor and the plaintext identifier;

[0056] Decrypting the payment ciphertext using the session key to obtain the identification of the payment device;

[0057] If the plain text identifier matches the identifier of the payment device, the payment backend performs a corresponding deduction operation based on the identifier of the payment device and the payment bill.

[0058] Optionally, decrypting the payment ciphertext by using the session key to obtain the identifier of the payment device includes:

[0059] Decrypting the payment ciphertext using the session key to obtain the identification of the payment device and the payment account information;

[0060] If the plain text identifier matches the identifier of the payment device, the payment backend performs a corresponding deduction operation based on the identifier of the payment device, the payment account information and the payment bill.

[0061] Optionally, the payment bill includes a scenario domain and an identification of the payment device;

[0062] Before executing the corresponding deduction operation according to the payment bill and the payment password, the method further includes:

[0063] It is determined that the association relationship between the scenario domain and the identifier of the payment device meets a preset condition.

[0064] Optionally, before executing a corresponding transaction according to the payment password, the method further includes:

[0065] Receiving the first time point and the second time point sent by the payment receiving device;

[0066] According to the first time point and the second time point, a target distance between the payment device and the payment device is determined, and it is determined that the target distance is less than a preset threshold.

[0067] Optionally, it also includes:

[0068] Receiving the time duration sent by the payment receiving device;

[0069] Determining a target distance between the payment device and the payment device according to the first time point and the second time point includes:

[0070] A target distance between the payment device and the payment device is determined according to the first time point, the second time point, and the elapsed time.

[0071] In a fourth aspect, an embodiment of the present invention further provides a transaction processing device, including:

[0072] A sending unit, configured to send a payment request to a payment device and obtain a first time point when the payment request is sent;

[0073] A first receiving unit, configured to receive a payment password sent by the payment device, and obtain a second time point at which the payment password is received;

[0074] The first processing unit is used to determine the target distance between the payment device and the payment device according to the first time point and the second time point; if the target distance is less than a preset threshold, the payment password is sent to the payment background, so that the payment background executes the corresponding transaction according to the payment password.

[0075] In a fifth aspect, an embodiment of the present invention further provides a transaction processing device, including:

[0076] A second receiving unit, used to receive a payment request sent by a payment receiving device;

[0077] The second processing unit is used to generate a payment password according to the payment request; send the payment password to the payment device, so that the payment device determines the target distance between the payment device and the payment device according to the first time point of sending the payment request and the second time point of receiving the payment password, and when it is determined that the target distance is less than a preset threshold, sends the payment password to the payment background, and the payment background is used to execute the corresponding transaction according to the payment password.

[0078] In a sixth aspect, an embodiment of the present invention further provides a transaction processing device, including:

[0079] A third receiving unit is configured to receive a payment password sent by a payment receiving device, wherein the payment password is generated by the payment device and sent to the payment receiving device after receiving a payment request sent by the payment receiving device, and is sent to the payment backend by the payment receiving device when determining that a target distance between the payment receiving device and the payment device is less than a preset threshold, wherein the target distance is determined by the payment receiving terminal according to a first time point of sending the payment request and a second time point of receiving the payment password;

[0080] The third processing unit is used to execute corresponding transactions according to the payment password.

[0081] In a seventh aspect, an embodiment of the present invention further provides a computer device, including:

[0082] Memory for storing computer programs;

[0083] The processor is used to call the computer program stored in the memory and execute the transaction processing method listed in any of the above-mentioned ways according to the obtained program.

[0084] In an eighth aspect, an embodiment of the present invention further provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer-executable program, and the computer-executable program is used to enable a computer to execute a transaction processing method listed in any of the above-mentioned ways.

[0085] In the embodiment of the present application, the payment device can determine the target distance between the payment device and the payment device by obtaining the first time point of sending the payment request and the second time point of receiving the payment password. If the target distance is less than the preset threshold, it means that the payment device processing the payment request is close to the payment device, that is, the payment device processing the payment request is not another payment device that is far away from the payment device and may be attacked by relays. The current transaction environment is safe, and then the payment password is sent to the payment backend for transaction processing. In this way, the risk of the payment device being attacked by relays is reduced and the security of the transaction is improved. The payment backend verifies the payment password again and recalculates the target distance between the payment device and the payment device to determine whether the transaction is safe. In this way, the risk of the payment device being attacked by relays is reduced and the security of the transaction is improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0086] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0087] Figure 1A schematic diagram of a payment device being attacked by a relay provided by an embodiment of the present invention;

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

[0089] Figure 3 A schematic diagram of a possible interface displayed by a payment device after a user successfully pays, provided in an embodiment of the present invention;

[0090] Figure 4 A flowchart of a transaction processing method provided by an embodiment of the present invention;

[0091] Figure 5 A UWB physical layer message structure provided by an embodiment of the present invention;

[0092] Figure 6 A schematic diagram of the structure of a UWB tag and a payment device provided by an embodiment of the present invention;

[0093] Figure 7 A schematic diagram of the structure of a transaction processing device provided by an embodiment of the present invention;

[0094] Figure 8 A schematic diagram of the structure of a transaction processing device provided by an embodiment of the present invention;

[0095] Fig. 9 A schematic diagram of the structure of a transaction processing device provided by an embodiment of the present invention;

[0096] Fig.10 A schematic diagram of the structure of a computer device provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0097] In order to make the purpose, implementation mode and advantages of the present application clearer, the exemplary implementation mode of the present application will be clearly and completely described below in conjunction with the drawings in the exemplary embodiments of the present application. Obviously, the described exemplary embodiments are only part of the embodiments of the present application, rather than all the embodiments.

[0098] Based on the exemplary embodiments described in this application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the claims attached to this application. In addition, although the disclosure in this application is introduced according to one or several exemplary examples, it should be understood that each aspect of the disclosure can also constitute a complete implementation method separately.

[0099] It should be noted that the brief description of terms in this application is only for the convenience of understanding the embodiments described below, and is not intended to limit the embodiments of this application. Unless otherwise specified, these terms should be understood according to their common and usual meanings.

[0100] The terms "first", "second", "third", etc. in the specification and claims of this application and the above drawings are used to distinguish similar or similar objects or entities, and do not necessarily mean to limit a specific order or sequence, unless otherwise indicated. It should be understood that the terms used in this way can be interchangeable under appropriate circumstances, for example, they can be implemented according to orders other than those given in the diagrams or descriptions of the embodiments of this application.

[0101] In addition, the terms "include" and "have" and any variations thereof are intended to cover but not exclude inclusion, for example, a product or device comprising a list of components is not necessarily limited to those components expressly listed but may include other components not expressly listed or inherent to such products or devices.

[0102] Figure 2 A system architecture applicable to an embodiment of the present invention is shown. The system architecture may include a payment device 201 , a payment collection device 202 , and a payment backend 203 .

[0103] The payment device 201 may be pre-installed with a payment application, wherein the payment application may be a client application, a web application, a mini-program, etc. The payment device 201 may be a mobile phone, a tablet computer, a laptop computer, a wearable device, etc. It is used to respond to a payment request sent by the payment receiving device 202 and send the identification of the payment device 201 and the corresponding payment account information to the payment receiving device 202.

[0104] The payment device 202 is used to initiate a payment request or automatically initiate a payment request according to the merchant's operation, interact with the payment device 201, obtain a payment response message corresponding to the payment request, and send the payment response message to the payment backend 203 for processing. The payment device 202 can be Figure 2 The scanning window, scanning gun, etc. shown in FIG. The payment device 201 and the payment receiving device 202 can be directly or indirectly connected via wired or wireless communication, and this application does not limit this.

[0105] The payment backend 203 is a backend server that provides corresponding services for payment, and is used to receive the payment response message sent by the payment collection device 202, and execute the corresponding transaction based on the payment response message. The payment backend 203 can 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 such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content delivery networks (Content Delivery Network, CDN), and big data and artificial intelligence platforms. The payment collection device 202 and the payment backend 203 can be directly or indirectly connected by wired or wireless communication, and this application does not limit this.

[0106] For example, when the user finishes shopping and checks out, the merchant enters the total amount that the user needs to pay, such as 100 yuan, into the payment device 202, and the payment device 202 sends a payment request and obtains the first time point when the payment request is sent. The user holds the payment device 201 close to the payment device 202, and the payment device 201 receives the payment request and obtains the third time point when the payment request is received. The payment device 201 generates a payment password according to the payment request. The payment password includes the identification of the payment device 201 and the payment account information, such as the China Bank savings card bound to the mobile phone C, and the account number is 1234××××. The payment device 201 sends the payment password to the payment device 202 and obtains the fourth time point when the payment password is sent. The payment device 201 calculates the time taken to generate the payment password in combination with the third time point and the fourth time point, and sends the time taken to the payment device 202. The payment device 202 receives the payment password sent by the payment device 201, and obtains the second time point of receiving the payment password. The payment device 202 also receives the elapsed time sent by the payment device 201. The payment device 202 determines the target distance between the payment device 202 and the payment device 201 based on the first time point, the second time point and the elapsed time. If the target distance is determined to be less than the preset threshold, it means that the payment device 201 processing the payment request of the payment device 202 is closer to the payment device 202, that is, the payment device 201 processing the payment request is not another payment device that is far away from the payment device 202 and may be attacked by relay, and the current transaction environment is safe. The payment device 202 uploads the payment password to the payment backend 203. After the payment backend 203 verifies the password, it determines the deduction method based on the identifier in the payment password and the payment account information, deducts the corresponding amount from the China Bank savings card with account number 1234××××, and adds the corresponding amount to the merchant's pre-set payment account, such as the China Industrial and Commercial Bank savings card with account number 4321××××. The payment backend 203 sends a successful payment message to the payment device 202, and the payment device 202 sends a prompt message to the merchant that "You have 100 yuan in your account". The payment backend 203 also sends a successful deduction message to the payment device 201, and the payment device 201 sends a prompt message to the user that "100 yuan has been paid successfully". Figure 3 FIG. 2 shows a schematic diagram of an interface displayed by the payment device 201 after a user has successfully paid.

[0107] The embodiment of the present invention provides a transaction processing method. Figure 4 As shown, the following steps are included:

[0108] Step 401: The payment receiving device sends a payment request to the payment device, and obtains the first time point when the payment request is sent.

[0109] The payment request may be sent in the form of a UWB (Ultra Wide Band) message. Specifically, the payment request is sent to the payment device via a first ultra wide band UWB message, and the first time point is obtained from a MAC layer data frame of the first UWB message. Figure 5 A UWB physical layer message structure is shown, such as Figure 5 As shown, the first time point T1 when the payment device sends the payment request is extracted through the "timestamp" field in the message.

[0110] The payment request may also carry an encryption factor, which includes at least one of the following data: characters, random numbers, or a combination of characters and random numbers. The encryption factor is used to identify the payment request message to ensure the uniqueness of the message, and also allows subsequent payment devices to generate a payment password based on the encryption factor.

[0111] Step 402: The payment device receives a payment request sent by the payment receiving device.

[0112] The payment device may receive the payment request via the third UWB message, and obtain the third time point T3 from the MAC layer data frame of the third UWB message.

[0113] Step 403: The payment device generates a payment password according to the payment request.

[0114] The embodiments of the present invention provide the following two methods for generating a payment password.

[0115] Method 1

[0116] The payment request carries an encryption factor, and the payment device generates a session key based on the encryption factor and the payment device's ID. The payment device's ID is encrypted with the session key to obtain the payment ciphertext, and then the payment password is generated based on the payment device's ID and the payment ciphertext.

[0117] Method 2

[0118] The payment request carries an encryption factor, and the payment device generates a session key based on the encryption factor and the payment device's ID. The payment device's ID and the payment account information corresponding to the payment device are encrypted using the session key to obtain the payment ciphertext. Then, based on the payment device's ID and the payment ciphertext, a payment password is generated.

[0119] The payment account information may be a payment account pre-set by the user, or may be the payment account most frequently used by the user when making payments, or the payment account most recently used by the user, etc. The payment ciphertext may also include other information, and the embodiments of the present invention do not limit the content of the payment ciphertext.

[0120] Based on the payment device identification and payment ciphertext, the payment device generates a payment password in the format of: payment device identification + payment ciphertext.

[0121] For example, the payment device receives a payment request sent by the payment device, extracts an encryption factor, such as a random number 5, from the payment request message, and forms a session key based on the payment device's identification and encryption factor through random number dispersion. The payment device uses the session key to encrypt the payment device's identification (such as payment device C) and payment account information (such as "Bank of China savings card, account number is 1234××××") to generate a payment ciphertext: payment device C + Bank of China savings card·account number is 1234××××. The payment device generates a payment password based on the payment device's identification and payment ciphertext: payment device C (payment device identification) + (payment device C + Bank of China savings card·account number is 1234××××) (payment ciphertext).

[0122] Step 404: The payment device sends the payment password to the payment receiving device.

[0123] The payment device sends the payment password via a fourth UWB message, and obtains a fourth time point T4 from a MAC layer data frame of the fourth UWB message.

[0124] Optionally, the payment device determines how long it takes to generate the payment password based on the third time point and the fourth time point, and sends the time taken to the payment device.

[0125] It takes a certain amount of time for the payment device to send the payment password after receiving the payment request. The time required for the series of processing from the payment device receiving the payment request to sending the payment password is called the time consuming length t of generating the payment password. The time consuming length t can be obtained by subtracting the fourth time point from the third time point, that is, t=T4-T3. The payment device sends the time consuming length t to the payment device.

[0126] Step 405: The payment receiving device receives the payment password sent by the payment device, and obtains a second time point when the payment password is received.

[0127] The payment receiving device receives the payment password sent by the payment device through the second UWB message, and obtains the second time point T2 from the MAC layer data frame of the second UWB message.

[0128] Optionally, the payment receiving device may also receive the time consuming duration t sent by the payment device, wherein the payment password and the time consuming duration are not sent simultaneously by the payment device, and thus the payment receiving device does not receive the payment password and the time consuming duration simultaneously.

[0129] Step 406: The payment device determines the target distance between the payment device and the payment device according to the first time point and the second time point.

[0130] The embodiment of the present invention provides two methods for determining the target distance.

[0131] Method 1

[0132] The difference between the second time point and the first time point is the time difference between the payment receiving device receiving the payment password and the payment receiving device sending the payment request, which time difference includes the first transmission time of the payment request from the payment receiving device to the payment device, the time for the payment device to respond to the payment request, and the second transmission time of the payment password from the payment device to the payment receiving device. Subtract the first time point and the time-consuming time from the second time point, that is, T2-T1-t, to obtain the sum of the first transmission time of the payment request from the payment receiving device to the payment device and the second transmission time of the payment password from the payment device to the payment receiving device. Since the transmission distances corresponding to the first transmission time and the second transmission time are both the distances between the payment receiving device and the payment device, and the transmission speed is the same, the first transmission time and the second transmission time are the same, so the second transmission time of the payment password from the payment device to the payment receiving device can be obtained as T=(T2-T1-t) / 2. Combined with the transmission speed of the payment password, the distance that the payment password travels from the payment device to the payment receiving device can be determined, that is, the target distance between the payment device and the payment receiving device.

[0133] Taking the use of UWB technology to send messages as an example, the first time point T1 extracted from the UWB message of the payment collection device sending the payment request is 0ns, the second time point T2 extracted from the UWB message of the payment collection device receiving the payment password is 374ns, the third time point T3 extracted from the UWB message of the payment collection request by the payment device is 128ns, and the fourth time point T4 extracted from the UWB message of the payment password sent by the payment device is 256ns. The payment device obtains the time consuming duration t = 256ns-128ns = 128ns for generating the payment password based on T3 and T4. The payment device sends the time consuming duration t to the payment collection device, and the payment collection device calculates the transmission duration T of the payment password from the payment device to the payment collection device = (T2-T1-t) / 2 = (374ns-0ns-128ns) / 2 = 123ns. Combined with the transmission speed c (speed of light) of the UWB message, the target distance between the two is s=T*c=0.37m.

[0134] Method 2

[0135] The time it takes for the payment device to generate the payment password can be ignored, that is, the transmission time of the payment password from the payment device to the payment device is T = (T2-T1) / 2 = (374ns-0ns) / 2 = 187ns. Combined with the transmission speed c (speed of light) of the UWB message, the target distance between the two is s = T*c = 0.56m.

[0136] It can be found that the target distance calculated by method 2 is larger than the target distance calculated by method 1. Since method 2 does not take the time duration into account, the error is relatively large. Therefore, the preset threshold corresponding to the target distance determined by method 2 can be distinguished from the preset threshold corresponding to the target distance determined by method 1. For example, the preset threshold corresponding to the target distance determined by method 1 is 0.3m, and the preset threshold corresponding to the target distance determined by method 2 is 0.5m.

[0137] Step 407: If the payment device determines that the target distance is less than the preset threshold, the payment password is sent to the payment backend.

[0138] After the target distance determined as 0.37m by the method 1 in step 406 is adopted, the target distance is compared with the corresponding preset threshold value 0.3m. The preset threshold value can be set by the technicians before the payment device leaves the factory, or it can be set by the merchant who collects the payment. The larger the preset threshold value, the more convenient it is for the user to complete the payment even if he / she stands at a farther distance from the payment device, making the payment process more convenient for the user, but it will also increase the risk of the payment device being attacked by relays; the smaller the preset threshold value, the stronger the ability to reduce the risk of relay attacks.

[0139] In this example, the target distance of 0.37m is greater than the preset threshold of 0.3m, so it is considered that the payment device is more likely to be a device attacked by a relay. In order to ensure the security of the transaction process, the payment device marks it as an "unsafe transaction" and terminates the transaction.

[0140] However, if the target distance between the payment device and the payment device calculated by the payment device is 0.2m, which is less than the preset threshold of 0.3m, the transaction process is considered safe, and the payment device sends the encryption factor it generates, the payment password received from the payment device, and the payment bill to the payment backend. The payment bill may include the scene domain, the identification of the payment device, the payment amount, etc.

[0141] Optionally, the payment device may also send the original message of sending the payment request, the original message of receiving the payment password, and the original message of receiving the time taken to the payment backend, so that the payment backend can recalculate the target distance between the payment device and the payment device to ensure the security of the transaction process.

[0142] Step 408: the payment backend receives the payment password sent by the payment device.

[0143] In addition to the payment password, the payment backend may also receive an encryption factor and a payment bill sent by the payment device. The above is only an example and is not limited in this embodiment of the present invention.

[0144] Step 409: the payment backend executes the corresponding transaction according to the payment password.

[0145] Specifically, it includes the following two steps.

[0146] Step 1: The payment backend verifies the payment password.

[0147] The format of the payment password received by the payment backend is: plain text identifier + payment ciphertext. The payment backend uses the plain text identifier and encryption factor to form a session key, and uses the session key to decrypt the payment ciphertext in the payment password.

[0148] In the process where the payment device sends the payment password to the payment receiving device, and then the payment receiving device sends the payment password to the payment backend, the plaintext identifier in the payment password is easily tampered with maliciously. For example, the payment device C in the plaintext identifier is tampered with to the payment device E. When the plaintext identifier in the payment password is maliciously tampered with, the payment backend uses the received plaintext identifier and encryption factor to generate a session key. At this time, the session key cannot decrypt the payment ciphertext. The payment backend can also determine based on this that a malicious attack has occurred during the payment process, the payment fails, and the payment process ends. If the payment backend uses the session key formed by the plaintext identifier and the encryption factor to decrypt the payment ciphertext, and obtains the identifier of the payment device carried in the payment ciphertext, it means that the plaintext identifier has not been tampered with. At this time, it can be further verified whether the plaintext identifier and the identifier of the payment device carried in the payment ciphertext match. If they match, it means that the plaintext identifier in the payment password and the payment ciphertext have not been tampered with.

[0149] Optionally, the payment bill includes the scene domain and the identification of the payment device. In order to further improve the security of the transaction, before executing the corresponding deduction operation, the payment backend can first determine whether the association between the scene domain and the identification of the payment device meets the preset conditions.

[0150] Specifically, the payment backend pre-saves the association relationship between each scenario domain and the corresponding payment device identifier. After obtaining the scenario domain and the payment device identifier in the payment bill, the payment backend determines whether the association relationship between the scenario domain and the payment device identifier in the payment bill matches the saved association relationship. If so, the corresponding deduction operation is performed, otherwise the payment process is terminated.

[0151] For example, the scenario domain is a refueling scenario, the identifier of the payment device is D, and the payment amount is 100 yuan. The payment backend determines whether the association between the refueling scenario and the identifier D matches the saved association, that is, whether the payment device identified as D is used in the refueling scenario. If so, 100 yuan is deducted from the payment account information of the payment device in the payment password according to the payment bill, and the deducted money is added to the payment account corresponding to the payment device.

[0152] Optionally, the payment backend also stores the binding relationship between the identification of each payment device and the payment account information, and the payment ciphertext may also carry the payment account information. Therefore, the payment backend can also verify whether the binding relationship between the identification of the payment device and the payment account information in the payment ciphertext is correct. If the verification is successful, the possibility of malicious attacks during the payment process is further reduced. Through multiple verifications, the security of the transaction is improved.

[0153] Optionally, the payment device may send the original message of the payment request, the original message of the payment password, and the original message of the reception time to the payment backend, and the payment backend extracts the first time point T1 from the original message of the payment request sent by the payment device, extracts the second time point T2 from the original message of the payment password received by the payment device, and extracts the time consuming time t from the original message of the payment device receiving the time consuming time.

[0154] The payment device may also send the original message of the payment request and the original message of the payment password to the payment backend, and the payment backend extracts the first time point T1 from the original message of the payment request sent by the payment device, and extracts the second time point T2 from the original message of the payment password received by the payment device. The payment device sends the original message of the payment request and the original message of the payment password to the payment device, and the payment device sends them to the payment backend, and the payment backend extracts the third time point T3 from the original message of the payment request received by the payment device, and extracts the fourth time point T4 from the original message of the payment password sent by the payment device. The payment backend calculates the time consuming duration t based on T3 and T4.

[0155] The payment device can also directly send the first time point T1, the second time point T2 and the elapsed time t to the payment backend. Of course, the payment backend can also obtain the first time point T1, the second time point T2 and the elapsed time t in other ways, which will not be repeated here.

[0156] The payment backend calculates the target distance between the payment device and the payment receiving device through T1, T2 and t, and compares it with the preset threshold. If the target distance is less than the preset threshold, the verification is passed. The payment backend calculates the target distance between the payment device and the payment receiving device again and compares it with the preset threshold to verify whether the transaction process is safe again. In this way, the security of the transaction can be improved.

[0157] Step 2: The payment backend performs the corresponding deduction operation based on the payment bill and payment password.

[0158] In one possible implementation, the payment ciphertext is decrypted using the session key to obtain the identification of the payment device. If the plaintext identification matches the identification of the payment device, the payment backend performs the corresponding deduction operation based on the identification of the payment device and the payment bill.

[0159] Specifically, the payment backend obtains the payment account information bound to the payment device based on the identification of the payment device, and then performs the corresponding deduction operation according to the payment account information and the payment bill. The payment account information bound to the payment device can be the default payment account information pre-set by the user, the payment account information of the most recent deduction by the payment device, or the payment account information with the highest deduction frequency, etc.

[0160] In one possible implementation, the payment ciphertext is decrypted using the session key to obtain the payment device identification and payment account information. If the plaintext identification matches the payment device identification, the payment backend performs the corresponding deduction operation based on the payment device identification, payment account information and payment bill.

[0161] Specifically, the payment password can directly carry the payment account information, which is obtained by decrypting the payment password, and then the corresponding deduction operation is performed based on the payment device identification, payment account information and payment bill. The payment account information carried in the payment password can be the payment account information selected by the user during the current deduction process, the default payment account information pre-set by the user, the payment account information of the most recent deduction by the payment device, or the payment account information with the highest deduction frequency, etc.

[0162] It should be noted that in the above two implementations, before the payment backend performs the corresponding deduction operation based on the payment device's identification, payment account information and payment bill, verifying whether the plain text identification and the payment device's identification match is merely an example. The embodiments of the present application are not limited to this verification method, and any one or more of the various verification methods described in step 1 may be adopted. This application does not make any specific limitations on this.

[0163] Furthermore, the payment backend obtains the identification of the payment device according to the payment bill, and adds the amount deducted from the deduction account to the payment account according to the payment account information corresponding to the identification of the payment device. The correspondence between the identification of the payment device and the payment account information can be set by the merchant, or the payment backend can automatically determine the merchant's last payment account as the current payment account, or determine the merchant's most frequently used account as the payment account information. The embodiments of the present invention do not limit this.

[0164] For example, the payment backend determines the payment account information as China Bank savings card account number 1234×××× based on the payment password, and determines the payment amount as RMB 100 based on the payment bill. Then, RMB 100 is deducted from the savings card with account number 1234×××× through the China Bank server.

[0165] The payment backend determines that the payment device is payment device D based on the payment bill. The payment account information corresponding to payment device D is: Industrial and Commercial Bank of China savings card account number 4321××××. Then, an amount of 100 yuan is added to the savings card with account number 4321×××× through the server of Industrial and Commercial Bank of China.

[0166] After the transaction is completed, the payment background will send the payment success information to the payment device and the payment device. After receiving the payment success information, the payment device will send a "payment successful" prompt to the merchant. After receiving the payment success information, the payment device will display the "payment successful" prompt on the display interface.

[0167] In the embodiment of the present application, the payment device can determine the target distance between the payment device and the payment device by obtaining the first time point of sending the payment request, the second time point of receiving the payment password, and the time taken by the payment device to generate the payment password. If the target distance is less than the preset threshold, it means that the payment device processing the payment request is close to the payment device, that is, the payment device processing the payment request is not another payment device that is far away from the payment device and may be attacked by relays. The current transaction environment is safe, and then the payment password is sent to the payment backend for transaction processing. In this way, the risk of the payment device being attacked by relays is reduced, and the security of the transaction is improved.

[0168] The payment backend verifies the payment password again and recalculates the target distance between the payment device and the payment device to determine whether the transaction is safe. This reduces the risk of the payment device being attacked by relays and improves the security of the transaction.

[0169] In order to better explain the embodiments of the present invention, a transaction processing method in an embodiment of the present application will be introduced below by taking payment through a UWB tag as an example. The transaction processing method is interactively executed by a payment device equipped with a UWB tag, a payment collection device and a payment background.

[0170] First, the structure of the UWB tag is introduced. Figure 6 As shown:

[0171] The UWB tag 601 can be set on any device such as a mobile terminal, a vehicle-mounted terminal, a wearable device, etc. The embodiment of the present invention does not limit the setting position of the UWB tag 601, and any device equipped with the UWB tag 601 can be used as a payment device.

[0172] The UWB tag 601 includes a first MCU (Microcontroller Unit) module, a first UWB communication module, a storage unit and a magnetic induction coil.

[0173] Specifically, the first MCU module is the main control chip of the UWB tag, which is responsible for regulating and controlling peripheral components such as the first UWB communication module, the storage unit and the magnetic induction coil.

[0174] The first UWB communication module is responsible for communicating with the payment collection device 602 .

[0175] The storage unit is responsible for storing encryption keys and payment account information. The encryption keys can be common algorithms at home and abroad, including SM2, SM3, SM4, AES, RSA, etc., which are used to generate session keys. The payment account information and encryption keys are written uniformly and securely in the payment backend and cannot be stolen or tampered with.

[0176] Since the UWB tag 601 needs power to perform the above functions, it can be installed on a mobile terminal that can provide power, or the UWB tag 601 can be placed in contact with the payment device 602 to obtain power when the UWB tag 601 is used for payment. The embodiment of the present invention also provides another method, in which a magnetic induction coil is installed on the UWB tag 601 to generate induction power, or a button battery is installed to provide power, so that the UWB tag 601 can be installed anywhere.

[0177] Next, the structure of the payment collection device 602 is introduced. Figure 6 As shown:

[0178] The payment device 602 mainly includes a second MCU module, a second UWB communication module, a payment module, a random number generator and a 4G communication module.

[0179] The second MCU module is the main control chip of the payment device 602, responsible for regulating peripheral components such as the second UWB communication module, the payment module random number generator and the 4G communication module.

[0180] The second UWB communication module is responsible for communicating with the UWB tag 601 .

[0181] The random number generator is used to generate random numbers.

[0182] The payment module is used to form payment bills.

[0183] The 4G communication module is used to communicate with the payment backend.

[0184] The following describes a transaction processing method in an embodiment of the present application in combination with the structure of the UWB tag 601 and the structure of the payment device 602. The method specifically includes:

[0185] The payment device 602 generates a random number through a random number generator, generates a payment request through the second MCU module, and sends the payment request to the first UWB communication module of the UWB tag 601, and extracts the first time point T1 of sending the payment request from the message of sending the payment request through the second UWB communication module.

[0186] The UWB tag 601 receives the payment request through the first UWB communication module, and extracts the third time point T3 of receiving the payment request from the message of receiving the payment request through the first UWB communication module. The UWB tag 601 generates a payment password according to the payment request through the first MCU module, and sends the payment password to the second UWB communication module of the payment collection device 602 through the first UWB communication module. The UWB tag 601 extracts the fourth time point T4 of sending the payment password from the message of sending the payment password through the first UWB communication module. The first MCU module of the UWB tag 601 calculates the time t of generating the payment password according to the third time point T3 and the fourth time point T4, and sends the time t to the second UWB communication module of the payment collection device 602 through the first UWB communication module.

[0187] The second UWB communication module of the payment device 602 receives the payment password and extracts the second time point T2 from the message of the received payment password. The second MCU module of the payment device 602 calculates the target distance between the UWB tag 601 and the payment device 602 according to T1, T2 and t, and compares it with the preset threshold. If it is determined that the target distance is greater than the preset threshold, the payment process is terminated; if it is determined that the target distance is less than the preset threshold, the random number generated by the random number generator and the payment password are sent to the payment background 603 through the 4G communication module. The payment device 602 generates a payment bill through the payment module, including the current payment scenario domain, the amount to be paid, the identification of the payment device 602, etc. The payment device 602 sends the payment bill to the payment background 603 through the 4G communication module.

[0188] The payment backend 603 verifies the security of the payment password. If the verification is successful, the corresponding deduction operation is performed according to the payment bill and the payment password.

[0189] In the embodiment of the present application, the payment device can determine the target distance between the payment device and the payment device by obtaining the first time point of sending the payment request, the second time point of receiving the payment password, and the time taken by the payment device to generate the payment password. If the target distance is less than the preset threshold, it means that the payment device processing the payment request is close to the payment device, that is, the payment device processing the payment request is not another payment device that is far away from the payment device and may be attacked by relays. The current transaction environment is safe, and then the payment password is sent to the payment backend for transaction processing. In this way, the risk of the payment device being attacked by relays is reduced, and the security of the transaction is improved.

[0190] The payment backend verifies the payment password again and recalculates the target distance between the payment device and the payment device to determine whether the transaction is safe. This reduces the risk of the payment device being attacked by relays and improves the security of the transaction.

[0191] Based on the same technical concept, Figure 7 The structure of a transaction processing device provided by an embodiment of the present invention is exemplarily shown, and the structure can execute the process of transaction processing by a payment device.

[0192] like Figure 7 As shown, the device specifically includes:

[0193] The sending unit 701 is used to send a payment request to a payment device and obtain a first time point when the payment request is sent;

[0194] The first receiving unit 702 is used to receive the payment password sent by the payment device and obtain a second time point when the payment password is received;

[0195] The first processing unit 703 is used to determine the target distance between the payment device and the payment device according to the first time point and the second time point; if the target distance is less than a preset threshold, the payment password is sent to the payment backend, so that the payment backend executes the corresponding transaction according to the payment password.

[0196] Optionally, the first receiving unit 702 is specifically configured to:

[0197] Receiving the time taken to generate the payment password sent by the payment device;

[0198] The first processing unit 703 is specifically configured to:

[0199] A target distance between the payment device and the payment device is determined according to the first time point, the second time point, and the elapsed time.

[0200] Optionally, the first processing unit 703 is specifically configured to:

[0201] Determine the transmission time of the payment password from the payment device to the payment receiving device according to the first time point, the second time point and the elapsed time;

[0202] The target distance between the payment device and the payment receiving device is determined according to the transmission duration and the transmission speed of the payment password.

[0203] Optionally, the payment request carries an encryption factor, so that the payment device generates the payment password based on the encryption factor;

[0204] The first receiving unit 702 is specifically configured to:

[0205] If the target distance is less than a preset threshold, the payment password, the encryption factor and the payment bill will be sent to the payment backend, so that the payment backend will verify the payment password based on the encryption factor, and after the verification is passed, perform the corresponding deduction operation according to the payment bill and the payment password.

[0206] Optionally, the sending unit 701 is specifically configured to:

[0207] Sending a payment request to a payment device via a first ultra-wideband UWB message, and acquiring the first time point from a MAC layer data frame of the first UWB message;

[0208] The first receiving unit 702 is specifically configured to:

[0209] The payment password sent by the payment device is received through a second UWB message, and the second time point is obtained from the MAC layer data frame of the second UWB message.

[0210] In the embodiment of the present application, the payment device can determine the target distance between the payment device and the payment device by obtaining the first time point of sending the payment request and the second time point of receiving the payment password. If the target distance is less than the preset threshold, it means that the payment device processing the payment request is close to the payment device, that is, the payment device processing the payment request is not another payment device that is far away from the payment device and may be attacked by relay. The current transaction environment is safe, and then the payment password is sent to the payment backend for transaction processing. In this way, the risk of the payment device being attacked by relay is reduced, and the security of the transaction is improved.

[0211] The payment backend verifies the payment password again and recalculates the target distance between the payment device and the payment device to determine whether the transaction is safe. This reduces the risk of the payment device being attacked by relays and improves the security of the transaction.

[0212] Based on the same technical concept, Figure 8 The structure of a transaction processing device provided by an embodiment of the present invention is exemplarily shown, and the structure can execute the process of transaction processing by a payment device.

[0213] like Figure 8 As shown, the device specifically includes:

[0214] The second receiving unit 801 is used to receive a payment request sent by a payment receiving device;

[0215] The second processing unit 802 is used to generate a payment password according to the payment request; send the payment password to the payment device, so that the payment device determines the target distance between the payment device and the payment device according to the first time point of sending the payment request and the second time point of receiving the payment password, and when it is determined that the target distance is less than a preset threshold, sends the payment password to the payment backend, and the payment backend is used to execute the corresponding transaction according to the payment password.

[0216] Optionally, the second receiving unit 801 is specifically configured to:

[0217] Obtaining a third time point at which the payment request is received;

[0218] Obtaining a fourth time point at which the payment password is sent;

[0219] Based on the third time point and the fourth time point, the time taken to generate the payment password is determined, and the time taken is sent to the payment device, so that the payment device determines the target distance between the payment device and the payment device based on the first time point of sending the payment request, the second time point of receiving the payment password and the time taken.

[0220] Optionally, the payment request carries an encryption factor;

[0221] The second processing unit 802 is specifically configured to:

[0222] generating a session key based on the encryption factor and the identification of the payment device;

[0223] Encrypting the identification of the payment device by using the session key to obtain a payment ciphertext;

[0224] The payment password is generated based on the identification of the payment device and the payment ciphertext.

[0225] Optionally, the second processing unit 802 is specifically configured to:

[0226] The identification of the payment device and the payment account information corresponding to the payment device are encrypted by using the session key to obtain a payment ciphertext.

[0227] Optionally, the second receiving unit 801 is specifically configured to:

[0228] Receiving the payment request through a third UWB message, and acquiring the third time point from a MAC layer data frame of the third UWB message;

[0229] The payment password is sent via a fourth UWB message, and the fourth time point is obtained from a MAC layer data frame of the fourth UWB message.

[0230] In the embodiment of the present application, the payment device can determine the target distance between the payment device and the payment device by obtaining the first time point of sending the payment request and the second time point of receiving the payment password. If the target distance is less than the preset threshold, it means that the payment device processing the payment request is close to the payment device, that is, the payment device processing the payment request is not another payment device that is far away from the payment device and may be attacked by relay. The current transaction environment is safe, and then the payment password is sent to the payment backend for transaction processing. In this way, the risk of the payment device being attacked by relay is reduced, and the security of the transaction is improved.

[0231] The payment backend verifies the payment password again and recalculates the target distance between the payment device and the payment device to determine whether the transaction is safe. This reduces the risk of the payment device being attacked by relays and improves the security of the transaction.

[0232] Based on the same technical concept, Fig. 9 The structure of a transaction processing device provided by an embodiment of the present invention is exemplarily shown, and the structure can execute the process of transaction processing in the payment background.

[0233] like Fig. 9 As shown, the device specifically includes:

[0234] The third receiving unit 901 is used to receive a payment password sent by a payment receiving device, wherein the payment password is generated by the payment device and sent to the payment receiving device after receiving a payment request sent by the payment receiving device, and is sent to the payment backend by the payment receiving device when determining that a target distance between the payment receiving device and the payment device is less than a preset threshold, wherein the target distance is determined by the payment receiving terminal according to a first time point of sending the payment request and a second time point of receiving the payment password;

[0235] The third processing unit 902 is used to execute corresponding transactions according to the payment password.

[0236] Optionally, the third receiving unit 901 is specifically configured to:

[0237] The target distance is determined by the payment device according to a first time point of sending the payment request, a second time point of receiving the payment password, and a time duration of generating the payment password.

[0238] Optionally, the third processing unit 902 is specifically configured to:

[0239] Receiving the encryption factor and payment bill sent by the payment receiving device;

[0240] The payment password is verified based on the encryption factor, and after the verification is passed, a corresponding deduction operation is performed according to the payment bill and the payment password.

[0241] Optionally, the payment password includes a plain text identifier and a payment ciphertext;

[0242] The third processing unit 902 is specifically configured to:

[0243] generating a session key according to the encryption factor and the plaintext identifier;

[0244] Decrypting the payment ciphertext using the session key to obtain the identification of the payment device;

[0245] If the plain text identifier matches the identifier of the payment device, the payment backend performs a corresponding deduction operation based on the identifier of the payment device and the payment bill.

[0246] Optionally, the third processing unit 902 is specifically configured to:

[0247] Decrypting the payment ciphertext using the session key to obtain the identification of the payment device and the payment account information;

[0248] If the plain text identifier matches the identifier of the payment device, the payment backend performs a corresponding deduction operation based on the identifier of the payment device, the payment account information and the payment bill.

[0249] Optionally, the payment bill includes a scenario domain and an identification of the payment device;

[0250] The third processing unit 902 is specifically configured to:

[0251] It is determined that the association relationship between the scenario domain and the identifier of the payment device meets a preset condition.

[0252] Optionally, the third processing unit 902 is specifically configured to:

[0253] Receiving the first time point and the second time point sent by the payment receiving device;

[0254] According to the first time point and the second time point, a target distance between the payment device and the payment device is determined, and it is determined that the target distance is less than a preset threshold.

[0255] Optionally, the third processing unit 902 is specifically configured to:

[0256] Receiving the time duration sent by the payment receiving device;

[0257] A target distance between the payment device and the payment device is determined according to the first time point, the second time point, and the elapsed time.

[0258] In the embodiment of the present application, the payment device can determine the target distance between the payment device and the payment device by obtaining the first time point of sending the payment request and the second time point of receiving the payment password. If the target distance is less than the preset threshold, it means that the payment device processing the payment request is close to the payment device, that is, the payment device processing the payment request is not another payment device that is far away from the payment device and may be attacked by relay. The current transaction environment is safe, and then the payment password is sent to the payment backend for transaction processing. In this way, the risk of the payment device being attacked by relay is reduced, and the security of the transaction is improved.

[0259] The payment backend verifies the payment password again and recalculates the target distance between the payment device and the payment device to determine whether the transaction is safe. This reduces the risk of the payment device being attacked by relays and improves the security of the transaction.

[0260] Based on the same technical concept, the embodiment of the present application provides a computer device, such as Fig.10 As shown, it includes at least one processor 1001 and a memory 1002 connected to the at least one processor. The specific connection medium between the processor 1001 and the memory 1002 is not limited in the embodiment of the present application. Fig.10 For example, the processor 1001 and the memory 1002 are connected via a bus. The bus can be divided into an address bus, a data bus, a control bus, etc.

[0261] In the embodiment of the present application, the memory 1002 stores instructions that can be executed by at least one processor 1001, and the at least one processor 1001 can execute the steps of the above-mentioned transaction processing method by executing the instructions stored in the memory 1002.

[0262] The processor 1001 is the control center of the computer device, and can use various interfaces and lines to connect various parts of the computer device, and perform transaction processing by running or executing instructions stored in the memory 1002 and calling data stored in the memory 1002. Optionally, the processor 1001 may include one or more processing units, and the processor 1001 may integrate an application processor and a modem processor, wherein the application processor mainly processes the operating system, user interface, and application programs, and the modem processor mainly processes wireless communications. It is understandable that the above-mentioned modem processor may not be integrated into the processor 1001. In some embodiments, the processor 1001 and the memory 1002 may be implemented on the same chip, and in some embodiments, they may also be implemented separately on independent chips.

[0263] Processor 1001 can be a general-purpose processor, such as a central processing unit (CPU), a digital signal processor, an application-specific integrated circuit (ASIC), a field programmable gate array or other programmable logic device, a discrete gate or transistor logic device, a discrete hardware component, and can implement or execute the various methods, steps and logic block diagrams disclosed in the embodiments of the present application. A general-purpose processor can be a microprocessor or any conventional processor, etc. The steps of the method disclosed in the embodiments of the present application can be directly embodied as a hardware processor to be executed, or can be executed by a combination of hardware and software modules in the processor.

[0264] The memory 1002 is a non-volatile computer-readable storage medium that can be used to store non-volatile software programs, non-volatile computer executable programs and modules. The memory 1002 may include at least one type of storage medium, such as a flash memory, a hard disk, a multimedia card, a card-type memory, a random access memory (Random Access Memory, RAM), a static random access memory (Static Random Access Memory, SRAM), a programmable read-only memory (Programmable Read Only Memory, PROM), a read-only memory (Read Only Memory, ROM), an electrically erasable programmable read-only memory (Electrically Erasable Programmable Read-Only Memory, EEPROM), a magnetic memory, a disk, an optical disk, etc. The memory 1002 is any other medium that can be used to carry or store a desired program code in the form of an instruction or data structure and can be accessed by a computer, but is not limited thereto. The memory 1002 in the embodiment of the present application can also be a circuit or any other device that can realize a storage function, for storing program instructions and / or data.

[0265] Based on the same technical concept, an embodiment of the present invention further provides a computer-readable storage medium, which stores a computer-executable program, and the computer-executable program is used to enable a computer to execute a transaction processing method listed in any of the above-mentioned ways.

[0266] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented in one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that include computer-usable program code.

[0267] The present application is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0268] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0269] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0270] Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the spirit and scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include these modifications and variations.

Claims

1. A transaction processing method, characterized in that: include: Sending a payment request to a payment device via a first UWB message, and acquiring a first time point from a MAC layer data frame of the first UWB message; The payment request carries an encryption factor, so that the payment device generates a session key according to the encryption factor and the identifier of the payment device; The identification of the payment device and the payment account information corresponding to the payment device are encrypted by the session key to obtain a payment ciphertext; a payment password is generated based on the identification of the payment device and the payment ciphertext; the encryption factor is also used to identify the payment request; Receiving, through a second UWB message, a payment password sent by the payment device and a time duration for generating the payment password sent by the payment device, and acquiring a second time point from a MAC layer data frame of the second UWB message; Determine a target distance between the payment device and the payment device according to the first time point, the second time point, and the elapsed time; If the target distance is less than a preset threshold, the payment password, the encryption factor, and the payment bill are sent to the payment backend; the payment bill includes the scene domain and the identifier of the payment device, so that the payment backend performs the following operations: Determine whether the association between the scenario domain in the payment bill and the identifier of the payment device matches the pre-saved association; the payment backend pre-saves the association between each scenario domain and the identifier of the corresponding payment device; if it matches, generate a session key based on the plaintext identifier in the payment password and the encryption factor, and use the session key to decrypt the payment ciphertext in the payment password. If the decryption is successful, verify whether the binding relationship between the identifier of the payment device and the payment account information in the payment ciphertext is correct based on the binding relationship between the identifier of each payment device and the payment account information stored in the payment backend; if the verification is successful, obtain the first time point, the second time point and the elapsed time, and determine the target distance between the payment device and the payment device again based on the first time point, the second time point and the elapsed time; when it is determined that the target distance is less than the preset threshold, execute the corresponding transaction according to the payment bill and the payment password.

2. The method according to claim 1, characterized in that Determining a target distance between the payment device and the payment device according to the first time point, the second time point, and the elapsed time includes: Determine the transmission time of the payment password from the payment device to the payment receiving device according to the first time point, the second time point and the elapsed time; The target distance between the payment device and the payment receiving device is determined according to the transmission duration and the transmission speed of the payment password.

3. A transaction processing method, characterized in that: include: Receive a payment request sent by a payment device; The payment request carries an encryption factor, so that the payment device generates a session key according to the encryption factor and the identification of the payment device; The identification of the payment device and the payment account information corresponding to the payment device are encrypted by the session key to obtain a payment ciphertext; a payment password is generated based on the identification of the payment device and the payment ciphertext; the encryption factor is also used to identify the payment request; Generating a payment password according to the payment request and the time taken to generate the payment password; The payment password and the time taken to generate the payment password are sent to the payment receiving device, so that the payment receiving device determines the target distance between the payment receiving device and the payment device according to the first time point of sending the payment request and the second time point of receiving the payment password and the time taken, and when it is determined that the target distance is less than a preset threshold, the payment password, the encryption factor and the payment bill are sent to the payment backend; the payment bill includes the scene domain and the identifier of the payment receiving device, so that the payment backend performs the following operations: Determine whether the association relationship between the scenario domain and the identifier of the payment device in the payment bill matches the association relationship between the scenario domain and the identifier of the corresponding payment device that is stored in advance; If there is a match, a session key is generated based on the plaintext identifier in the payment password and the encryption factor, and the payment ciphertext in the payment password is decrypted using the session key. If the decryption is successful, based on the binding relationship between the identifiers of each payment device and the payment account information stored in the payment backend, it is verified whether the binding relationship between the identifier of the payment device and the payment account information in the payment ciphertext is correct; if the verification is successful, the first time point, the second time point and the elapsed time are obtained, and based on the first time point, the second time point and the elapsed time, the target distance between the payment device and the payment device is determined; when it is determined that the target distance is less than the preset threshold, the corresponding transaction is executed according to the payment bill and the payment password; the payment backend pre-saves the association relationship between each scenario domain and the identifier of the corresponding payment device.

4. The method according to claim 3, characterized in that Also includes: Obtaining a third time point at which the payment request is received; Obtaining a fourth time point at which the payment password is sent; Based on the third time point and the fourth time point, the time taken to generate the payment password is determined, and the time taken is sent to the payment device, so that the payment device determines the target distance between the payment device and the payment device based on the first time point of sending the payment request, the second time point of receiving the payment password and the time taken.

5. The method according to claim 4, characterized in that The obtaining of the third time point of receiving the payment request includes: Receiving the payment request through a third UWB message, and acquiring the third time point from a MAC layer data frame of the third UWB message; The obtaining of the fourth time point for sending the payment password comprises: The payment password is sent via a fourth UWB message, and the fourth time point is obtained from a MAC layer data frame of the fourth UWB message.

6. A transaction processing method, characterized in that: include: Receive a payment password, an encryption factor, and a payment bill sent by a payment receiving device, wherein the payment password, the encryption factor, and the payment bill are generated by the payment device after receiving a payment request sent by the payment receiving device and sent to the payment receiving device, and are sent to the payment backend by the payment receiving device when determining that the target distance between the payment receiving device and the payment device is less than a preset threshold, wherein the payment password is generated by the payment device in the following manner: generating a session key according to the encryption factor and the identifier of the payment device; encrypting the identifier of the payment device and the payment account information corresponding to the payment device by using the session key to obtain a payment ciphertext; and generating a payment password based on the identifier of the payment device and the payment ciphertext; The encryption factor is also used to identify the payment request; the target distance is determined by the payment device according to the first time point of sending the payment request, the time taken to generate the payment password, and the second time point of receiving the payment password; the payment bill includes the scene domain and the identification of the payment device; the payment backend performs the following operations: Determine whether the association relationship between the scenario domain and the identifier of the payment device in the payment bill matches the association relationship between the scenario domain and the identifier of the corresponding payment device that is pre-saved; if it matches, generate a session key based on the plaintext identifier in the payment password and the encryption factor, and use the session key to decrypt the payment ciphertext in the payment password. If the decryption is successful, verify whether the binding relationship between the identifier of the payment device and the payment account information in the payment ciphertext is correct based on the binding relationship between the identifier of each payment device and the payment account information stored in the payment backend; if the verification is successful, obtain the first time point, the second time point and the elapsed time, and determine the target distance between the payment device and the payment device based on the first time point, the second time point and the elapsed time; when it is determined that the target distance is less than the preset threshold, execute the corresponding transaction according to the payment bill and the payment password; the payment backend pre-saves the association relationship between each scenario domain and the identifier of the corresponding payment device.

7. The method according to claim 6, characterized in that The using the session key to decrypt the payment ciphertext in the payment password includes: Decrypting the payment ciphertext using the session key to obtain the identification of the payment device; If the plaintext identifier and the identifier of the payment device match, it is determined that the decryption is successful.

8. The method according to claim 7, characterized in that The decrypting the payment ciphertext by using the session key to obtain the identification of the payment device includes: The payment ciphertext is decrypted by the session key to obtain the identification of the payment device and the payment account information.

9. A transaction processing device, characterized in that: include: A sending unit, configured to send a payment request to a payment device via a first UWB message, and obtain a first time point from a MAC layer data frame of the first UWB message; The payment request carries an encryption factor, so that the payment device generates a session key according to the encryption factor and the identifier of the payment device; The identification of the payment device and the payment account information corresponding to the payment device are encrypted by the session key to obtain a payment ciphertext; a payment password is generated based on the identification of the payment device and the payment ciphertext; the encryption factor is also used to identify the payment request; A first receiving unit is configured to receive, through a second UWB message, a payment password sent by the payment device and a time duration for generating the payment password sent by the payment device, and obtain a second time point from a MAC layer data frame of the second UWB message; A first processing unit, configured to determine a target distance between a payment device and a payment device according to the first time point, the second time point, and the elapsed time; If the target distance is less than a preset threshold, the payment password, the encryption factor, and the payment bill are sent to the payment backend; the payment bill includes the scene domain and the identifier of the payment device, so that the payment backend performs the following operations: Determine whether the association between the scenario domain in the payment bill and the identifier of the payment device matches the pre-saved association; the payment backend pre-saves the association between each scenario domain and the identifier of the corresponding payment device; if it matches, generate a session key based on the plaintext identifier in the payment password and the encryption factor, and use the session key to decrypt the payment ciphertext in the payment password. If the decryption is successful, verify whether the binding relationship between the identifier of the payment device and the payment account information in the payment ciphertext is correct based on the binding relationship between the identifier of each payment device and the payment account information stored in the payment backend; if the verification is successful, obtain the first time point, the second time point and the elapsed time, and determine the target distance between the payment device and the payment device again based on the first time point, the second time point and the elapsed time; when it is determined that the target distance is less than the preset threshold, execute the corresponding transaction according to the payment bill and the payment password.

10. A transaction processing device, characterized in that: include: A second receiving unit, used to receive a payment request sent by a payment receiving device; The payment request carries an encryption factor, so that the payment device generates a session key according to the encryption factor and the identification of the payment device; The identification of the payment device and the payment account information corresponding to the payment device are encrypted by the session key to obtain a payment ciphertext; a payment password is generated based on the identification of the payment device and the payment ciphertext; the encryption factor is also used to identify the payment request; A second processing unit, configured to generate a payment password according to the payment request and the time taken to generate the payment password; The payment password and the time taken to generate the payment password are sent to the payment receiving device, so that the payment receiving device determines the target distance between the payment receiving device and the payment device according to the first time point of sending the payment request and the second time point of receiving the payment password and the time taken, and when it is determined that the target distance is less than a preset threshold, the payment password, the encryption factor and the payment bill are sent to the payment backend; the payment bill includes the scene domain and the identifier of the payment receiving device, so that the payment backend performs the following operations: Determine whether the association relationship between the scenario domain and the identifier of the payment device in the payment bill matches the association relationship between the scenario domain and the identifier of the corresponding payment device that is stored in advance; If there is a match, a session key is generated based on the plaintext identifier in the payment password and the encryption factor, and the payment ciphertext in the payment password is decrypted using the session key. If the decryption is successful, based on the binding relationship between the identifiers of each payment device and the payment account information stored in the payment backend, it is verified whether the binding relationship between the identifier of the payment device and the payment account information in the payment ciphertext is correct; if the verification is successful, the first time point, the second time point and the elapsed time are obtained, and based on the first time point, the second time point and the elapsed time, the target distance between the payment device and the payment device is determined; when it is determined that the target distance is less than the preset threshold, the corresponding transaction is executed according to the payment bill and the payment password; the payment backend pre-saves the association relationship between each scenario domain and the identifier of the corresponding payment device.

11. A transaction processing device, characterized in that: include: a third receiving unit, configured to receive a payment password, an encryption factor, and a payment bill sent by a payment receiving device, wherein the payment password, encryption factor, and payment bill are generated by the payment device after receiving a payment request sent by the payment receiving device and sent to the payment receiving device, and are sent to the payment backend by the payment receiving device when determining that the target distance between the payment receiving device and the payment device is less than a preset threshold, wherein the payment password is generated by the payment device in the following manner: generating a session key according to the encryption factor and an identifier of the payment device; encrypting the identifier of the payment device and the payment account information corresponding to the payment device by using the session key to obtain a payment ciphertext; and generating a payment password based on the identifier of the payment device and the payment ciphertext; The encryption factor is also used to identify the payment request; the target distance is determined by the payment device according to the first time point of sending the payment request, the time taken to generate the payment password, and the second time point of receiving the payment password; the payment bill includes the scene domain and the identification of the payment device; so that the payment backend performs the following operations: determining whether the association relationship between the scene domain in the payment bill and the identification of the payment device matches the association relationship between the scene domain and the identification of the corresponding payment device that is pre-saved; The third processing unit is used to generate a session key based on the plaintext identifier in the payment password and the encryption factor if a match is found, and use the session key to decrypt the payment ciphertext in the payment password; if the decryption is successful, based on the binding relationship between the identifiers of each payment device and the payment account information stored in the payment backend, verify whether the binding relationship between the identifier of the payment device and the payment account information in the payment ciphertext is correct; if the verification is successful, obtain the first time point, the second time point and the elapsed time, and determine the target distance between the payment device and the payment device based on the first time point, the second time point and the elapsed time; when it is determined that the target distance is less than the preset threshold, execute the corresponding transaction according to the payment bill and the payment password; the payment backend pre-saves the association relationship between each scenario domain and the identifier of the corresponding payment device.

12. A computer device, characterized in that: include: Memory for storing computer programs; A processor, configured to call a computer program stored in the memory, and execute the method according to any one of claims 1 to 8 according to the obtained program.

13. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer-executable program, and the computer-executable program is used to enable a computer to execute the method according to any one of claims 1 to 8.

Images