Dynamic routing non-contact card transaction method, server, merchant side and system

Abstract

The invention discloses a dynamic routing non-contact card transaction method, a server, a merchant side and a system, and the method comprises the steps: searching a current transaction gateway corresponding to a current region of a merchant according to the current region information of the merchant and the relation between the region and the transaction gateway; the transaction data is sent after a preset encryption key is encrypted at a merchant end, and the preset encryption key is obtained from a transaction prepositive server in advance; decrypting the encrypted transaction data by using a preset encryption key; determining an encryption key corresponding to the current transaction gateway according to the current transaction gateway and the relationship between the transaction gateway and the encryption key distributed for the merchant; re-encrypting the decrypted transaction data by using the encryption key corresponding to the current transaction gateway; and sending the re-encrypted transaction data to the current transaction gateway to complete subsequent transaction processing. According to the invention, non-contact card transaction of dynamic routing can be realized, the method is safe, flexible and convenient, and the user experience is improved.

Description

Technical Field

[0001] The present invention relates to the field of mobile payment technology, and in particular to a dynamic routing contactless card transaction method, a server, a merchant terminal and a system. Background Art

[0002] This section is intended to provide a background or context to the embodiments of the invention recited in the claims. No admission is made that the description herein is prior art by inclusion in this section.

[0003] In recent years, the development of mobile terminal-based contactless bank card transaction solutions has been changing with each passing day. Merchants' traditional POS payment devices have gradually turned to mobile terminal APPs (SoftPOS or mobile terminal POS). During contactless bank card transactions, consumers' bank card data needs to be collected by POS terminals or mobile phone APPs and sent to the transaction backend for processing. The transaction front-end server sends the transaction request to different transaction gateways (Payment Gateway) or acquiring banks (Acquirer) for processing.

[0004] In the existing mobile payment technology solutions, independent transaction front-end servers are mainly deployed in each region. The cross-regional operation of the same merchant requires the use of multiple different accounts for differentiation and configuration management. For merchants in the same region, the transaction front-end server generally only realizes fixed docking with the same transaction gateway. Therefore, the existing contactless card transaction routing solution is not safe, flexible and convenient, which affects the user experience. Summary of the invention

[0005] An embodiment of the present invention provides a contactless card transaction method for dynamic routing applied to a transaction front-end server, for implementing a secure dynamic routing contactless card transaction, the method comprising:

[0006] When receiving a contactless card transaction request, searching for the current transaction gateway corresponding to the merchant's current area according to the merchant's current area information and the relationship between the pre-configured area and the transaction gateway; the contactless card transaction request includes transaction data and the merchant's current area information, the transaction data is encrypted by a preset encryption key at the merchant end and then sent, and the preset encryption key is obtained in advance from the transaction front-end server;

[0007] Decrypting the encrypted transaction data using the preset encryption key to obtain decrypted transaction data;

[0008] Determining the encryption key corresponding to the current transaction gateway according to the current transaction gateway and the relationship between the pre-configured transaction gateway and the encryption key distributed to the merchant;

[0009] Re-encrypt the decrypted transaction data using the encryption key corresponding to the current transaction gateway to obtain re-encrypted transaction data;

[0010] The re-encrypted transaction data is sent to the current transaction gateway to complete the subsequent transaction processing, and the transaction processing result fed back by the current transaction gateway is returned to the merchant end.

[0011] The embodiment of the present invention also provides a contactless card transaction method for dynamic routing applied to a merchant end, for implementing a secure dynamic routing contactless card transaction, the method comprising:

[0012] Upon receiving a contactless card transaction request, identifying the merchant's current area information; the contactless card transaction request includes transaction data;

[0013] Encrypting transaction data according to a preset encryption key pre-obtained from a transaction front-end server;

[0014] The encrypted transaction data and the merchant's current area information are sent to the transaction front-end server; the transaction front-end server is used to find the current transaction gateway corresponding to the merchant's current area according to the merchant's current area information and the relationship between the pre-configured area and the transaction gateway; the encrypted transaction data is decrypted using the preset encryption key to obtain decrypted transaction data; the encryption key corresponding to the current transaction gateway is determined according to the current transaction gateway and the relationship between the pre-configured transaction gateway and the encryption key distributed to the merchant; the decrypted transaction data is re-encrypted using the encryption key corresponding to the current transaction gateway to obtain re-encrypted transaction data; the re-encrypted transaction data is sent to the current transaction gateway to complete the subsequent transaction processing, and the transaction processing result fed back by the current transaction gateway is returned to the merchant.

[0015] The embodiment of the present invention further provides a dynamic routing contactless card transaction front-end server for implementing secure dynamic routing contactless card transactions, the transaction front-end server comprising:

[0016] The area determination unit is used to find the current transaction gateway corresponding to the current area of ​​the merchant according to the merchant's current area information and the relationship between the pre-configured area and the transaction gateway when receiving the contactless card transaction request; the contactless card transaction request includes transaction data and the merchant's current area information, the transaction data is encrypted by a preset encryption key at the merchant end and then sent, and the preset encryption key is obtained in advance from the transaction front-end server;

[0017] A decryption unit, used to decrypt the encrypted transaction data using the preset encryption key to obtain decrypted transaction data;

[0018] An encryption key determination unit, configured to determine an encryption key corresponding to the current transaction gateway according to the current transaction gateway and a relationship between a pre-configured transaction gateway and an encryption key distributed to a merchant;

[0019] The re-encryption unit is used to re-encrypt the decrypted transaction data using the encryption key corresponding to the current transaction gateway to obtain the re-encrypted transaction data;

[0020] The feedback unit is used to send the re-encrypted transaction data to the current transaction gateway to complete the subsequent transaction processing, and return the transaction processing result fed back by the current transaction gateway to the merchant end.

[0021] The embodiment of the present invention further provides a dynamically routed contactless card transaction merchant terminal for implementing secure dynamically routed contactless card transactions, the merchant terminal comprising:

[0022] An identification unit, configured to identify the merchant's current area information when receiving a contactless card transaction request; the contactless card transaction request includes transaction data;

[0023] An encryption unit, used to encrypt transaction data according to a preset encryption key pre-acquired from a transaction front-end server;

[0024] A sending unit is used to send the encrypted transaction data and the merchant's current area information to the transaction front-end server; the transaction front-end server is used to find the current transaction gateway corresponding to the merchant's current area according to the merchant's current area information and the relationship between the pre-configured area and the transaction gateway; the encrypted transaction data is decrypted using the preset encryption key to obtain the decrypted transaction data; the encryption key corresponding to the current transaction gateway is determined according to the current transaction gateway and the relationship between the pre-configured transaction gateway and the encryption key distributed to the merchant; the decrypted transaction data is re-encrypted using the encryption key corresponding to the current transaction gateway to obtain the re-encrypted transaction data; the re-encrypted transaction data is sent to the current transaction gateway to complete the subsequent transaction processing, and the transaction processing result fed back by the current transaction gateway is returned to the merchant end.

[0025] The embodiment of the present invention further provides a dynamic routing contactless card transaction system for implementing secure dynamic routing contactless card transactions. The system includes: the merchant terminal as described above, and the transaction front-end server as described above.

[0026] An embodiment of the present invention further provides a computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the above-mentioned dynamic routing contactless card transaction method when executing the computer program.

[0027] An embodiment of the present invention further provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the above-mentioned dynamic routing contactless card transaction method is implemented.

[0028] An embodiment of the present invention further provides a computer program product, the computer program product comprising a computer program, and the computer program, when executed by a processor, implements the above-mentioned dynamic routing contactless card transaction method.

[0029] In an embodiment of the present invention, a dynamic routing contactless card transaction scheme works as follows: when a merchant receives a contactless card transaction request, the merchant's current area information is identified; the contactless card transaction request includes transaction data; the transaction data is encrypted according to a preset encryption key pre-acquired from a transaction front-end server; the encrypted transaction data and the merchant's current area information are sent to the transaction front-end server; the transaction front-end server searches for a current transaction gateway corresponding to the merchant's current area according to the merchant's current area information and a relationship between a pre-configured area and a transaction gateway; the preset encryption key is pre-acquired from the transaction front-end server; the encrypted transaction data is decrypted using the preset encryption key to obtain decrypted transaction data; the encryption key corresponding to the current transaction gateway is determined according to the current transaction gateway and the relationship between the pre-configured transaction gateway and the encryption key distributed to the merchant; the decrypted transaction data is re-encrypted using the encryption key corresponding to the current transaction gateway to obtain re-encrypted transaction data; the re-encrypted transaction data is sent to the current transaction gateway to complete the subsequent transaction processing, and the transaction processing result fed back by the current transaction gateway is returned to the merchant.

[0030] Compared with the technical solution in the prior art in which, for merchants in the same area, the transaction front-end server generally only realizes fixed docking with the same transaction gateway, resulting in the existing contactless card transaction routing solution being not safe, flexible and convenient, and affecting the user experience, in the dynamic routing contactless card transaction solution provided by the embodiment of the present invention, the relationship between the area and the transaction gateway is pre-configured, and the merchant's current transaction gateway can be dynamically and flexibly determined according to the merchant's current area. At the same time, the relationship between the transaction gateway and the encryption key distributed to the merchant is also pre-configured. According to the above-mentioned dynamically and flexibly determined current transaction gateway, and the relationship between the transaction gateway and the encryption key distributed to the merchant, the encryption key corresponding to the current transaction gateway can be determined, and the decrypted transaction data is re-encrypted according to the encryption key corresponding to the current transaction gateway, and the re-encrypted transaction data is sent to the current transaction gateway to complete the subsequent transaction processing, and the transaction processing result fed back by the current transaction gateway is returned to the merchant end, so that dynamic routing contactless card transactions can be realized, which is safe, flexible and convenient, and improves the user experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the prior art descriptions. 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. In the drawings:

[0032] Figure 1 A schematic diagram of components involved in a contactless card transaction with dynamic routing in an embodiment of the present invention;

[0033] Figure 2 A schematic diagram of contactless card transaction security detection for ensuring dynamic routing in an embodiment of the present invention;

[0034] Figure 3 It is a flowchart of a contactless card transaction method for dynamic routing applied to a merchant side in an embodiment of the present invention;

[0035] Figure 4 A schematic flow chart of a contactless card transaction method for dynamic routing applied to a transaction front-end server in an embodiment of the present invention;

[0036] Figure 5 A schematic diagram of the structure of a contactless card transaction merchant terminal with dynamic routing in an embodiment of the present invention;

[0037] Figure 6 A schematic diagram of the structure of a dynamic routing contactless card transaction front-end server in an embodiment of the present invention;

[0038] Figure 7 Schematic diagram of the structure of a contactless card transaction system with dynamic routing in an embodiment of the present invention. DETAILED DESCRIPTION

[0039] To make the purpose, technical solution and advantages of the embodiments of the present invention more clear, the embodiments of the present invention are further described in detail below in conjunction with the accompanying drawings. Here, the exemplary embodiments of the present invention and their descriptions are used to explain the present invention, but are not intended to limit the present invention.

[0040] The acquisition, storage, use, and processing of data in the technical solution of this application comply with the relevant provisions of laws and regulations.

[0041] The disadvantages of existing contactless card transaction routing technology solutions are: it is difficult to centrally manage transaction data of the same merchant in different areas; merchants deliberately jump zones and codes, which may lead to transaction risk behaviors; merchants cannot choose cooperative transaction gateways; merchants can only purchase POS built-in traffic cards and need to bear additional traffic costs; the machine has been modified without the merchant knowing, which easily leads to subsequent credit card theft. Considering the above disadvantages, the embodiment of the present invention provides a dynamic routing contactless card transaction solution. The following is a detailed introduction to the dynamic routing contactless card transaction solution.

[0042] Figure 4 FIG. 1 is a schematic diagram of a contactless card transaction method for dynamic routing applied to a transaction front-end server in an embodiment of the present invention. Figure 4 As shown, the method comprises the following steps:

[0043] Step 201: upon receiving a contactless card transaction request, searching for a current transaction gateway corresponding to the merchant's current area according to the merchant's current area information and the relationship between the pre-configured area and the transaction gateway; the contactless card transaction request includes transaction data and the merchant's current area information, the transaction data is encrypted by a preset encryption key at the merchant end and then sent, and the preset encryption key is obtained in advance from the transaction front-end server;

[0044] Step 202: decrypting the encrypted transaction data using the preset encryption key to obtain decrypted transaction data;

[0045] Step 203: Determine the encryption key corresponding to the current transaction gateway according to the current transaction gateway and the relationship between the pre-configured transaction gateway and the encryption key distributed to the merchant;

[0046] Step 204: re-encrypt the decrypted transaction data using the encryption key corresponding to the current transaction gateway to obtain re-encrypted transaction data;

[0047] Step 205: Send the re-encrypted transaction data to the current transaction gateway to complete the subsequent transaction processing, and return the transaction processing result fed back by the current transaction gateway to the merchant end.

[0048] In an embodiment of the present invention, a contactless card transaction method for dynamic routing, when working: when receiving a contactless card transaction request, the merchant side identifies the merchant's current area information; the contactless card transaction request includes transaction data; according to a preset encryption key pre-acquired from a transaction front-end server, the transaction data is encrypted; the encrypted transaction data and the merchant's current area information are sent to the transaction front-end server; the transaction front-end server searches for the current transaction gateway corresponding to the merchant's current area according to the merchant's current area information and the relationship between the pre-configured area and the transaction gateway; the preset encryption key is pre-acquired from the transaction front-end server; the encrypted transaction data is decrypted using the preset encryption key to obtain the decrypted transaction data; according to the current transaction gateway and the relationship between the pre-configured transaction gateway and the encryption key distributed to the merchant, the encryption key corresponding to the current transaction gateway is determined; the decrypted transaction data is re-encrypted using the encryption key corresponding to the current transaction gateway to obtain the re-encrypted transaction data; the re-encrypted transaction data is sent to the current transaction gateway to complete the subsequent transaction processing, and the transaction processing result fed back by the current transaction gateway is returned to the merchant side.

[0049] Compared with the prior art, in which for merchants in the same area, the transaction front-end server generally only realizes fixed docking with the same transaction gateway, resulting in the existing contactless card transaction routing scheme being not safe, flexible and convenient, and affecting the user experience, in the dynamic routing contactless card transaction method provided by the embodiment of the present invention, the relationship between the area and the transaction gateway is pre-configured, and the merchant's current transaction gateway can be dynamically and flexibly determined according to the merchant's current area. At the same time, the relationship between the transaction gateway and the encryption key distributed to the merchant is also pre-configured. According to the above-mentioned dynamically and flexibly determined current transaction gateway, and the relationship between the transaction gateway and the encryption key distributed to the merchant, the encryption key corresponding to the current transaction gateway can be determined, and the decrypted transaction data is re-encrypted according to the encryption key corresponding to the current transaction gateway, and the re-encrypted transaction data is sent to the current transaction gateway to complete the subsequent transaction processing, and the transaction processing result fed back by the current transaction gateway is returned to the merchant end, so that the dynamic routing contactless card transaction can be realized, which is safe, flexible and convenient, and improves the user experience. The following is a detailed introduction to the dynamic routing contactless card transaction method.

[0050] The embodiment of the present invention constructs a dynamic and highly secure transaction process, which specifically includes the following steps:

[0051] 1) The transaction front-end server implements unified key management for all SoftPOS APPs. Specifically, after the SoftPOS APP is installed in the merchant's handheld device (merchant terminal), it obtains a unique transaction data encryption key (IK_KEY, preset encryption key) from the transaction front-end server during the first initialization. The subkey derived from the key is used to encrypt the card data and PIN data (Personal Identification Number) of the contactless bank card. That is, in one embodiment, the transaction data includes the card data and PIN data of the contactless bank card; the preset encryption key is IK_KEY, and the subkey derived from the key is used to encrypt the card data and PIN data of the contactless bank card.

[0052] 2) Configure the transaction gateway selected by the merchant in different regions in the transaction front-end server, that is, pre-configure the relationship between the region and the transaction gateway, which can be stored in Figure 1 The transaction configuration database in the solves the problem that the transaction data of the same merchant in different regions is difficult to centrally manage. In this step, the transaction service administrator will send the encryption key (GW_KEY, such as Figure 1 The GW_KEY A and GW_KEY B shown in the figure are imported into the encryption machine (HSM, which can be as follows) of the transaction front-end server. Figure 1 The transaction encryption machine 2 (first transaction encryption machine) shown in the figure pre-configures the relationship between the transaction gateway and the encryption keys distributed to the merchants. These keys are used to encrypt the transaction data sent to the corresponding gateway and the merchant number information (Merchant ID) corresponding to the merchant in the gateway, solving the problem that the merchant cannot choose the transaction gateway to cooperate with.

[0053] 3) When the merchant uses the SoftPOS APP to make a transaction, the SoftPOS APP uses the IK_KEY derived key (the derivation method can also be: X9.24 2017 Part 3) to encrypt the card swipe data and PIN data respectively, and then sends the encrypted transaction data to the transaction front-end server, corresponding to Figure 1 In: "IK_KEY encryption processing", "Transaction processing software module".

[0054] 4) Find the transaction gateway corresponding to the merchant in the area according to the merchant information, that is, according to the merchant's current area information and the pre-configured relationship between the area and the transaction gateway (the relationship can be pre-configured in Figure 1), find the current transaction gateway corresponding to the merchant's current region. According to the current transaction gateway and the relationship between the pre-configured transaction gateway and the encryption key distributed to the merchant, determine the encryption key corresponding to the current transaction gateway; then the transaction server calls the HSM (which can be Figure 1 The transaction encryption machine 6 (the second transaction encryption machine, in which IK_KEY is preset) shown in the figure first uses IK_KEY (preset encryption key) to decrypt the transaction card swipe data and PIN data, that is, the encrypted transaction data is decrypted using the preset encryption key to obtain the decrypted transaction data, and then the transaction data is re-encrypted using the GW_KEY (encryption key corresponding to the current transaction gateway) used by the corresponding transaction gateway, that is, the decrypted transaction data is re-encrypted using the encryption key corresponding to the current transaction gateway to obtain the re-encrypted transaction data. The re-encryption step can be called Figure 1 In the specific implementation, the first transaction encryption machine and the second transaction encryption machine can be used to implement the present invention, and of course, the same transaction encryption machine can also be used to implement it.

[0055] 5) The transaction front-end server sends the re-encrypted data to the corresponding transaction gateway to complete the subsequent transaction processing. This step can be used Figure 1 The "post-transaction" in Figure 1 The transaction front-end server returns the transaction result to the SoftPOS APP.

[0056] At the same time, in order to achieve further secure transactions, the embodiment of the present invention constructs a risk prevention protection process, the specific process is as follows:

[0057] 1) Before the transaction occurs, the SoftPOS APP requests the risk prevention server to detect the mobile phone security consistency detection mechanism (reference patent a dynamic mobile phone security consistency detection mechanism). The risk prevention server will determine whether the current SoftPOS APP is safe and can be traded based on the information collected by the SoftPOS APP.

[0058] 2) When a merchant uses the SoftPOS APP to conduct a transaction, the transaction front-end server will access the risk prevention server again to determine whether the SoftPOS APP operating environment is safe before the transaction occurs, and that the environmental detection is within the validity period.

[0059] 3) When a merchant uses the SoftPOS APP to make a transaction, the transaction front-end server will access the risk prevention server again and submit the current merchant information to the risk prevention server, which will perform data strategy analysis.

[0060] From the above, it can be seen that in one embodiment, before sending the re-encrypted transaction data to the current transaction gateway to complete the subsequent transaction processing, it also includes: submitting the current merchant information to the risk prevention server for the risk prevention server to perform security data policy analysis to identify whether the current transaction is a risky transaction, thereby further ensuring the security of the transaction.

[0061] 4) The risk prevention server conducts strategic analysis based on the merchant information submitted by the user, historical transaction data, normal and abnormal list data, and the current geographical location of the environment. It determines whether the current transaction has code jumping, malicious transactions, etc. through transaction statistics and industry transaction median. It determines whether the current transaction is a known malicious behavior through the normal list (a list without transaction risks) and the abnormal list (a list with transaction risks). It determines whether the current SoftPOS APP has a zone jumping transaction through address information.

[0062] For example, industry categories can be divided into catering, retail, fresh food, amusement halls / KTVs, Internet cafes, cinema chains, performances and events, residents' life services, scenic spots / hotels, health care equipment / medical equipment / over-the-counter drugs, other private / private hospitals / clinics, leisure and entertainment / tourism services, travel agencies, religious organizations, cultural relics management / cultural relics replica sales, consulting / entertainment ticketing, other payments, training institutions (offline scenarios), parking payments, private / private dental and ophthalmology, medical beauty hospitals / clinics, clothing, shoes and bags, beauty and daily chemicals, and fitness services, etc. For example, if a merchant in a certain area is in the catering industry and the median of historical transactions is 50 yuan, when a single transaction of 1,000 yuan occurs, which obviously exceeds the median of historical transactions, it is a suspicious order.

[0063] From the above, it can be seen that in one embodiment, the current merchant information is submitted to the anti-risk server, and the anti-risk server performs a security data policy analysis to identify whether the current transaction is a risky transaction, including: submitting the current merchant information to the anti-risk server, and the anti-risk server performs a policy analysis based on the current merchant information, the current merchant's historical transaction data, and the current merchant's geographic location information to identify whether the current transaction is a risky transaction, thereby further ensuring the security of the transaction.

[0064] From the above, it can be seen that in one embodiment, the current merchant information is submitted to the risk prevention server, and the risk prevention server performs a security data policy analysis to identify whether the current transaction is a risky transaction, including: submitting the current merchant information to the risk prevention server, and the risk prevention server performs a policy analysis based on the current merchant information, the current merchant's historical transaction data, and a preset exception list data strategy to identify whether the current transaction is a risky transaction, thereby further ensuring the security of the transaction.

[0065] In specific implementation, the above-mentioned risk transactions may include zone-hopping and code-hopping transactions.

[0066] Regarding code hopping: card issuing banks have different fee rates for different merchant types:

[0067] Livelihood merchants: home appliances, supermarkets, gas stations, airline ticketing, water and electricity charges, etc. Rate: 0.38%;

[0068] Public welfare merchants: public hospitals, schools, charities, etc. Rate: 0%;

[0069] Standard merchants: such as catering, entertainment, jewelry, department stores, hardware, etc. Rate: 0.6%;

[0070] Then, code jumping means, for example, the merchant that originally swipes the money may end up paying for jewelry, but the merchant that issues the receipt is from a gas station. This is code jumping (also known as MCC jumping).

[0071] The purpose of code jumping is: because the handling fee for standard merchants is 0.6, while the handling fee for people's livelihood merchants is 0.38, if users want to swipe the card at standard merchants, the acquiring agency will give the user a people's livelihood merchant, and the acquiring agency can earn a difference of 22 yuan / 10,000 yuan.

[0072] In addition, regarding jumping regions: Generally, jumping regions means that the acquiring institution performs acquiring operations in order to jump codes or the acquiring institution does not have acquiring authority in this acquiring region. Not all acquiring institutions can acquire nationwide. For details, please refer to the acquiring region on the payment license.

[0073] 5) The risk prevention server will feed back the analysis results to the transaction front-end server, which will make a decision based on the feedback results. If the current transaction is a malicious attack or fraudulent behavior, the transaction will be prohibited. If the current transaction behavior has suspicious risks but no decision can be made, it will be transferred to risk observation and an email will be sent to relevant personnel for further investigation. If the current transaction is normal, the re-encrypted data will be sent to the corresponding transaction gateway to complete the subsequent transaction processing.

[0074] As can be seen from the above, in one embodiment, the above-mentioned dynamic routing contactless card transaction method may further include: when the current transaction is identified as a risky transaction, prohibiting the processing of the current transaction to further ensure the security of the transaction.

[0075] In specific implementation, the risk prevention protection process constructed above solves the problem of merchants deliberately jumping zones and codes, which may lead to transaction risk behaviors.

[0076] In order to facilitate understanding of how to implement the present invention, the components and transaction processes involved in the embodiments of the present invention are described in detail below.

[0077] like Figure 1 As shown, the components involved in the embodiment of the present invention are shown in the following Table 1.

[0078]

[0079] Table 1

[0080] The transaction process involved in the embodiment of the present invention is shown in Table 2 below.

[0081]

[0082] Table 2

[0083] like Figure 2 The risk prevention process involved in the embodiment of the present invention is shown in Table 3 below. In the risk prevention process implemented by the transaction front-end server, Figure 2 The various steps in can represent:

[0084]

[0085]

[0086] Table 3

[0087] When implemented specifically, the above technical solution also solves the problems of "merchants can only purchase POS built-in traffic cards and need to bear additional traffic fees; the machine has been modified and the merchant is unaware, which can easily lead to subsequent credit card theft", with low cost and high transaction security.

[0088] The embodiment of the present invention also provides a contactless card transaction method for dynamic routing applied to a merchant end, as described in the following embodiment. Since the principle of solving the problem by this method is similar to that of the contactless card transaction method for dynamic routing applied to a transaction front-end server, the implementation of this method can refer to the implementation of the contactless card transaction method for dynamic routing applied to a transaction front-end server, and the repeated parts will not be repeated.

[0089] Figure 3 FIG. 1 is a flow chart of a contactless card transaction method for dynamic routing applied to a merchant terminal in an embodiment of the present invention. Figure 3 As shown, the method comprises the following steps:

[0090] Step 101: upon receiving a contactless card transaction request, identifying the merchant's current area information; the contactless card transaction request includes transaction data;

[0091] Step 102: Encrypting the transaction data according to a preset encryption key pre-acquired from the transaction front-end server;

[0092] Step 103: Send the encrypted transaction data and the merchant's current area information to the transaction front-end server; the transaction front-end server is used to find the current transaction gateway corresponding to the merchant's current area according to the merchant's current area information and the relationship between the pre-configured area and the transaction gateway; decrypt the encrypted transaction data using the preset encryption key to obtain decrypted transaction data; determine the encryption key corresponding to the current transaction gateway according to the current transaction gateway and the relationship between the pre-configured transaction gateway and the encryption key distributed to the merchant; re-encrypt the decrypted transaction data using the encryption key corresponding to the current transaction gateway to obtain re-encrypted transaction data; send the re-encrypted transaction data to the current transaction gateway to complete the subsequent transaction processing, and return the transaction processing result fed back by the current transaction gateway to the merchant.

[0093] In one embodiment, encrypting the transaction data according to a preset encryption key pre-acquired from the transaction front-end server may include:

[0094] Sending a merchant-side security detection request to the risk prevention server to determine whether the merchant-side transaction APP operating environment is safe before the transaction occurs; the security detection request includes characteristic parameters collected by the merchant-side;

[0095] When receiving the detection result of the current merchant terminal security determined by the risk prevention server according to the characteristic parameters collected by the merchant terminal, the current transaction data is encrypted according to the preset encryption key pre-acquired from the transaction front-end server.

[0096] In the embodiment of the present invention, characteristic parameters of the merchant terminal (e.g., mobile phone) and the transaction APP are collected and submitted to the risk prevention server. The risk prevention server combines the security benchmark characteristics of various merchant terminals (e.g., mobile phones) to obtain the security status of the merchant terminal (e.g., mobile phone) and the transaction APP, and returns it to the transaction APP and the merchant terminal (e.g., mobile phone). Figure 1 The merchant terminal held by the merchant shown in the figure) can prevent the occurrence of risky transactions and ensure the security of insurance transactions. The embodiment of the present invention can solve the problem of unified security detection under different types of merchant terminals and shield the incompatibility of security detection solutions caused by the differentiation of merchant terminals. The following is a detailed introduction.

[0097] 1) APP (here APP refers to the dynamic merchant security consistency detection method applied to the merchant side, such as Figure 2 The consistency detection module (shown in the “Consistency Detection Module”) establishes a trusted identity foundation. After the consistency detection module APP is installed, it collects the characteristic information (parameters) of the merchant terminal and the transaction APP installed by the merchant terminal when it is run for the first time, and encrypts and sends it to the risk prevention server (such as the trigger conditions mentioned in the following embodiments. The behavior of collecting characteristic parameters can also be performed under the preset trigger conditions, such as Figure 2 Steps a and b) in the above description, that is, in one embodiment, the characteristic parameters of the merchant terminal may include: the characteristic parameters of the merchant terminal itself and the characteristic parameters of the transaction APP installed in the merchant terminal. The characteristic parameters of the merchant terminal (such as a mobile phone) may include one of the following parameters or any combination thereof: mobile phone model, manufacturer, running operating system and its version number, operating system API level, mobile phone sensor list, Bootloader fingerprint (fingerprint), mobile phone TEE key consistency result (Key Attestation), Android Key Attestation parameters (if any), mobile phone unique ID value (egAndroidID), mobile phone system security patch level, list of APPs with SU permissions installed on the mobile phone, network port / network port driver and IP address information on the mobile phone, list of APPs with permission to read NFC interface on the mobile phone, mobile phone system debug characteristics, the APP mentioned in the characteristic parameters of the merchant terminal (such as a mobile phone) may refer to a transaction APP, or may refer to, for example, Figure 2 The "consistency detection module" shown in the "consistency detection module" can be placed in the trading APP in the form of SDK. The characteristic information (parameters) of the trading APP may include: trading APP package name, trading APP digital signature key hash list, trading APP permission list, trading APP version number, trading APP hash value, trading APP signature hash value. After the risk prevention server obtains the characteristic parameters of the mobile phone and APP, it detects whether the mobile phone characteristic parameters and APP characteristic parameters meet the basic threshold (security benchmark characteristics). If they meet, the APP (such as Figure 1 The “consistency detection module” shown in the figure creates a unique identification number, which can be indexed to the information of the above-mentioned mobile phone and transaction APP.

[0098] 2) APP (Consistency Detection Module) collects environmental parameters (Attestation), and APP periodically (randomly selected time intervals of every 10-30 minutes) collects mobile phone parameters and APP operating parameters. Its collection cycle and collection trigger mode (conditions) can be described in the following Table 4:

[0099]

[0100] Table 4

[0101] The characteristic parameters collected can be described in Table 5 below:

[0102]

[0103]

[0104] Table 5

[0105] 3) Risk-prevention servers perform baseline checks, such as Figure 2 Step c: "Benchmark" in the above. When the risk prevention server receives a consistency security check (detection) request from a merchant terminal such as a mobile phone, it will perform the first step of basic security check. This includes the following detailed steps.

[0106] a) Decrypt the encrypted consistency data packet. Only the data that is successfully decrypted can be used for subsequent consistency checks. If there are consecutive requests for data that fail to be decrypted, the risk prevention server will set the device to a non-secure state. After successful decryption, proceed to the next step of basic checks.

[0107] b) Check the trusted root of the device (merchant side), which is mainly to verify the certificate trust chain of the device's Key Attestation. This verification will detect whether the entire system of the device has been tampered with, and determine whether the consistency security check request comes from a real and reliable APP. The meaning of Attestation in the embodiment of the present invention is: proof, consistency, and a description of the collected data, which has not been tampered with, replayed, or pre-played.

[0108] c) Identify the root characteristics of the device, which includes checking the consistency data (a description of the collected data, such data has not been tampered with, replayed or pre-played, etc.) in the root Status, which contains a list of various root app installations collected on the mobile phone. For programs that contain known root apps, root directories, and programs that can perform root operations, the risk prevention server will mark the conclusion of the check as unsafe.

[0109] d) Identify the emulator characteristics of the device, which includes checking the emulator characteristic parameters contained in the emulator status in the consistency data, such as: typical emulator network card parameters, instruction set parameters, known emulator system fixed parameters, etc. If the detection contains known emulator characteristic parameters, the risk prevention server will mark the conclusion of the check as unsafe.

[0110] e) Identify the debug features of the device, including checking the debug feature parameters tracing, debug variant, system debug and other features in the consistency data to determine whether the app is in the debug state. For the results of detecting parameters containing known debug features, the risk prevention server will mark the check as unsafe.

[0111] f) Identify the hooking characteristics of the device, including checking the hooking status and other characteristic parameters in the consistency data to determine whether the device has installed the hooking framework, whether the app's memory contains fingerprint information such as hooking tools or library files. For parameter results containing known hooking characteristics, the risk prevention server will mark the check as unsafe.

[0112] g) Other security level checks: In order to achieve high security, the operating system version level and security patch level will be checked to ensure that only when the device parameters reach the set level will the result be marked as a safe state.

[0113] h) When all basic checks are completed, the risk prevention server will query whether the device model has a normal list or abnormal list policy set. If so, it will be transferred to the corresponding policy set for further judgment.

[0114] 4) The risk prevention server performs normal list strategy detection, such as Figure 2 Step d in: In order to target the differentiated features of different types of devices, the risk prevention server is equipped with a normal list strategy, that is, the normal list strategy is dynamically maintained (such as the normal policy entries that meet the data items shown in Table 5 above). The normal list includes a recheck of one or more pieces of data in the consistency data. Correct the results determined in the benchmark check (if necessary). After the normal list strategy set is run, the conclusion that some specific models of mobile phones are misjudged as unsafe under the benchmark check is corrected. After completing the normal list check, the risk prevention server will query whether there is still an abnormal list strategy for the device (such as an abnormal policy entry that does not meet the data items shown in Table 5 above). If there is an abnormal list strategy set, continue to run the abnormal list strategy set, that is, count the abnormal dataItem historical data of the device (merchant side) for security policy analysis.

[0115] When used on the merchant side, the normal list strategy is a normal strategy that conforms to normal feature parameters (such as the data items shown in Table 5 above) and is dynamically maintained for the differentiated features of different types of mobile terminals; the abnormal list strategy is an abnormal strategy that does not conform to normal feature parameters (such as the data items shown in Table 5 above) and is dynamically maintained for the differentiated features of different types of mobile terminals.

[0116] 5) The risk prevention server performs abnormal list strategy detection, such as Figure 2Step e in: In view of the differentiated characteristics of different types of devices, the risk prevention server also maintains a dynamically changing exception list strategy, that is, it dynamically maintains the exception list strategy. The exception list contains a recheck of one or more pieces of data in the consistency data. Correct the results determined in the policy set check (if necessary). After the operation of the exception list strategy set, the conclusions that some specific models of mobile phones were mistakenly judged as unsafe under the baseline check are corrected. After completing the exception list check, the risk prevention server will make an overall security level decision.

[0117] 6) Risk-proof server-overall security level decision, such as Figure 2 In step f: “Decision”, after checking the above three steps, each parameter in the consistency data will have a security level conclusion.

[0118] In specific implementation, the dynamically maintained security detection strategy can be the dynamically maintained preset normal list strategy and the dynamically maintained preset abnormal list strategy mentioned above. The normal list strategy and the abnormal list strategy will be updated after various types of merchant-side systems are upgraded, that is, the detection code will be dynamically updated. Therefore, after the merchant-side product system is upgraded, the security of the merchant-side can also be effectively detected without false alarms or omissions. At the same time, according to the dynamically maintained security detection strategy, the latest security vulnerabilities and other problems can be predicted and detected, and the security of merchant-side transactions can also be guaranteed.

[0119] a) The conclusion of each parameter is one of the following Table 6. The safest level is HEALTH, and the most serious level is UNDER_ATTACKING.

[0120]

[0121] Table 6

[0122] b) The risk prevention server will summarize the security conclusions of all parameters and give a comprehensive security level for the device (merchant side) / transaction app, as shown in Table 7 below.

[0123]

[0124] Table 7

[0125] c) The risk prevention server replies the comprehensive security level result to the consistency detection module, and the consistency detection module feeds the result back to the trading APP for the trading APP to make further responses based on the result, such as Figure 2 The g and h in.

[0126] 7) APP security response: After receiving the security level identification (result) from the anti-risk server, the APP will perform further execution actions as shown in Table 8 below.

[0127]

[0128]

[0129] Table 8

[0130] In order to facilitate understanding of how to implement the present invention, the risk prevention process of the merchant side involved in the embodiment of the present invention is described in the form of the following Table 9.

[0131] Step Number illustrate a Collecting consistent data b Upload to the risk prevention server c Consistency data baseline check d Check the normal list (white list) of consistent data e Consistency data exception list check f Security Level Decision Conclusion g Security level returned to consistency detection module h Security level result app response execution

[0132] Table 9

[0133] The embodiment of the present invention also provides a dynamic routing non-contact card transaction merchant terminal, as described in the following embodiment. Since the principle of solving the problem by the merchant terminal is similar to the dynamic routing non-contact card transaction method applied to the transaction front-end server, the implementation of the merchant terminal can refer to the implementation of the dynamic routing non-contact card transaction method applied to the transaction front-end server, and the repeated parts will not be repeated.

[0134] Figure 5 FIG. 1 is a schematic diagram of a contactless card transaction merchant terminal with dynamic routing in an embodiment of the present invention. Figure 5 As shown, the merchant terminal includes:

[0135] The identification unit 011 is used to identify the merchant's current area information when receiving a contactless card transaction request; the contactless card transaction request includes transaction data;

[0136] The encryption unit 012 is used to encrypt the transaction data according to the preset encryption key pre-acquired from the transaction front-end server;

[0137] The sending unit 013 is used to send the encrypted transaction data and the merchant's current area information to the transaction front-end server; the transaction front-end server is used to find the current transaction gateway corresponding to the merchant's current area according to the merchant's current area information and the relationship between the pre-configured area and the transaction gateway; the encrypted transaction data is decrypted using the preset encryption key to obtain decrypted transaction data; the encryption key corresponding to the current transaction gateway is determined according to the current transaction gateway and the relationship between the pre-configured transaction gateway and the encryption key distributed to the merchant; the decrypted transaction data is re-encrypted using the encryption key corresponding to the current transaction gateway to obtain re-encrypted transaction data; the re-encrypted transaction data is sent to the current transaction gateway to complete the subsequent transaction processing, and the transaction processing result fed back by the current transaction gateway is returned to the merchant end.

[0138] In one embodiment, the encryption unit is specifically used for:

[0139] Sending a merchant-side security detection request to an external risk prevention server to determine whether the merchant-side transaction APP operating environment is safe before the transaction occurs; the security detection request includes characteristic parameters collected by the merchant-side;

[0140] When receiving the detection result of the external risk prevention server determining the security of the current merchant terminal according to the characteristic parameters collected by the merchant terminal, the current transaction data is encrypted according to the preset encryption key pre-acquired from the transaction front-end server.

[0141] The embodiment of the present invention also provides a dynamic routing contactless card transaction front-end server, as described in the following embodiment. Since the principle of solving the problem by the front-end server is similar to the dynamic routing contactless card transaction method applied to the transaction front-end server, the implementation of the front-end server can refer to the implementation of the dynamic routing contactless card transaction method applied to the transaction front-end server, and the repeated parts will not be repeated.

[0142] Figure 6 FIG. 1 is a schematic diagram of the structure of a dynamic routing contactless card transaction front-end server in an embodiment of the present invention. Figure 6 As shown, the server includes:

[0143] The area determination unit 021 is used to find the current transaction gateway corresponding to the current area of ​​the merchant according to the merchant's current area information and the relationship between the pre-configured area and the transaction gateway when receiving the contactless card transaction request; the contactless card transaction request includes transaction data and the merchant's current area information, the transaction data is encrypted by a preset encryption key at the merchant end and then sent, and the preset encryption key is obtained in advance from the transaction front-end server;

[0144] The decryption unit 022 is used to decrypt the encrypted transaction data using the preset encryption key to obtain the decrypted transaction data;

[0145] The encryption key determination unit 023 is used to determine the encryption key corresponding to the current transaction gateway according to the current transaction gateway and the relationship between the pre-configured transaction gateway and the encryption key distributed to the merchant;

[0146] The re-encryption unit 024 is used to re-encrypt the decrypted transaction data using the encryption key corresponding to the current transaction gateway to obtain the re-encrypted transaction data;

[0147] The feedback unit 025 is used to send the re-encrypted transaction data to the current transaction gateway to complete the subsequent transaction processing, and return the transaction processing result fed back by the current transaction gateway to the merchant end.

[0148] In one embodiment, the transaction data includes card data and PIN data of a contactless bank card; the preset encryption key is IK_KEY, and a subkey derived from the key is used to encrypt the card data and PIN data of the contactless bank card.

[0149] In one embodiment, the dynamically routed contactless card transaction front-end server also includes a submission unit for submitting the current merchant information to the risk prevention server before sending the re-encrypted transaction data to the current transaction gateway to complete subsequent transaction processing, so that the risk prevention server can perform security data policy analysis to identify whether the current transaction is a risky transaction.

[0150] In one embodiment, the submitting unit is specifically used for:

[0151] Submit the current merchant information to the risk prevention server, so that the risk prevention server can perform strategy analysis based on the current merchant information, the historical transaction data of the current merchant, and the geographic location information of the current merchant to identify whether the current transaction is a risky transaction.

[0152] In one embodiment, the submitting unit is specifically used for:

[0153] Submit the current merchant information to the risk prevention server, which performs a strategy analysis based on the current merchant information, the current merchant's historical transaction data, and the preset abnormal list data strategy to identify whether the current transaction is a risky transaction.

[0154] In one embodiment, the above-mentioned dynamic routing contactless card transaction front-end server further includes: a prohibition unit, which is used to prohibit processing of the current transaction when the current transaction is identified as a risky transaction.

[0155] The embodiment of the present invention also provides a contactless card transaction system with dynamic routing, as described in the following embodiment. Since the principle of solving the problem by the system is similar to that of the contactless card transaction method with dynamic routing applied to the transaction front-end server, the implementation of the system can refer to the implementation of the contactless card transaction method with dynamic routing applied to the transaction front-end server, and the repeated parts will not be repeated.

[0156] Figure 7 FIG. 1 is a schematic diagram of a contactless card transaction system with dynamic routing according to an embodiment of the present invention. Figure 7 As shown, the system includes:

[0157] The merchant terminal 01 as described above, and the transaction front-end server 02 as described above.

[0158] The embodiment of the present invention further provides a dynamic routing contactless card transaction system for implementing dynamic routing contactless card transactions. The system includes: the merchant terminal as described above, and the transaction front-end server as described above.

[0159] An embodiment of the present invention further provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the above-mentioned dynamic routing contactless card transaction method when executing the computer program.

[0160] An embodiment of the present invention further provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the above-mentioned dynamic routing contactless card transaction method is implemented.

[0161] Compared with the technical solution in the prior art in which, for merchants in the same area, the transaction front-end server generally only realizes fixed docking with the same transaction gateway, resulting in the existing contactless card transaction routing solution being not safe, flexible and convenient, and affecting the user experience, in the dynamic routing contactless card transaction solution provided by the embodiment of the present invention, the relationship between the area and the transaction gateway is pre-configured, and the merchant's current transaction gateway can be dynamically and flexibly determined according to the merchant's current area. At the same time, the relationship between the transaction gateway and the encryption key distributed to the merchant is also pre-configured. According to the above-mentioned dynamically and flexibly determined current transaction gateway, and the relationship between the transaction gateway and the encryption key distributed to the merchant, the encryption key corresponding to the current transaction gateway can be determined, and the decrypted transaction data is re-encrypted according to the encryption key corresponding to the current transaction gateway, and the re-encrypted transaction data is sent to the current transaction gateway to complete the subsequent transaction processing, and the transaction processing result fed back by the current transaction gateway is returned to the merchant end, so that dynamic routing contactless card transactions can be realized, which is safe, flexible and convenient, and improves the user experience.

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

[0163] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks 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.

[0164] 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.

[0165] 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 The steps for the functions specified in one or more boxes.

[0166] The specific embodiments described above further illustrate the objectives, technical solutions and beneficial effects of the present invention in detail. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A contactless card transaction method with dynamic routing, characterized in that: The method is applied to a transaction front-end server, and the method comprises: When receiving a contactless card transaction request, searching for the current transaction gateway corresponding to the merchant's current area according to the merchant's current area information and the relationship between the pre-configured area and the transaction gateway; the contactless card transaction request includes transaction data and the merchant's current area information, the transaction data is encrypted by a preset encryption key at the merchant end and then sent, and the preset encryption key is obtained in advance from the transaction front-end server; Decrypting the encrypted transaction data using the preset encryption key to obtain decrypted transaction data; Determining the encryption key corresponding to the current transaction gateway according to the current transaction gateway and the relationship between the pre-configured transaction gateway and the encryption key distributed to the merchant; Re-encrypt the decrypted transaction data using the encryption key corresponding to the current transaction gateway to obtain re-encrypted transaction data; The re-encrypted transaction data is sent to the current transaction gateway to complete the subsequent transaction processing, and the transaction processing result fed back by the current transaction gateway is returned to the merchant end.

2. The method according to claim 1, characterized in that Before sending the re-encrypted transaction data to the current transaction gateway to complete the subsequent transaction processing, the method further includes: Submit the current merchant information to the risk prevention server for the risk prevention server to perform security data policy analysis to identify whether the current transaction is a risky transaction.

3. The method according to claim 2, characterized in that Submit the current merchant information to the risk prevention server for security data policy analysis to identify whether the current transaction is a risky transaction, including: Submit the current merchant information to the risk prevention server, so that the risk prevention server can perform strategy analysis based on the current merchant information, the historical transaction data of the current merchant, and the geographic location information of the current merchant to identify whether the current transaction is a risky transaction.

4. The method according to claim 2, characterized in that Submit the current merchant information to the risk prevention server for security data policy analysis to identify whether the current transaction is a risky transaction, including: Submit the current merchant information to the risk prevention server, which performs a strategy analysis based on the current merchant information, the current merchant's historical transaction data, and the preset abnormal list data strategy to identify whether the current transaction is a risky transaction.

5. A dynamic routing contactless card transaction method, characterized in that: The method is applied to the merchant side, and the method includes: Upon receiving a contactless card transaction request, identifying the merchant's current area information; the contactless card transaction request includes transaction data; Encrypting transaction data according to a preset encryption key pre-obtained from a transaction front-end server; The encrypted transaction data and the merchant's current area information are sent to the transaction front-end server; the transaction front-end server is used to find the current transaction gateway corresponding to the merchant's current area according to the merchant's current area information and the relationship between the pre-configured area and the transaction gateway; the encrypted transaction data is decrypted using the preset encryption key to obtain decrypted transaction data; the encryption key corresponding to the current transaction gateway is determined according to the current transaction gateway and the relationship between the pre-configured transaction gateway and the encryption key distributed to the merchant; the decrypted transaction data is re-encrypted using the encryption key corresponding to the current transaction gateway to obtain re-encrypted transaction data; the re-encrypted transaction data is sent to the current transaction gateway to complete the subsequent transaction processing, and the transaction processing result fed back by the current transaction gateway is returned to the merchant.

6. The method according to claim 5, characterized in that The transaction data is encrypted according to the preset encryption key obtained in advance from the transaction front-end server, including: Sending a merchant-side security detection request to the risk prevention server to determine whether the merchant-side transaction APP operating environment is safe before the transaction occurs; the security detection request includes characteristic parameters collected by the merchant-side; When receiving the detection result of the current merchant terminal security determined by the risk prevention server according to the characteristic parameters collected by the merchant terminal, the current transaction data is encrypted according to the preset encryption key pre-acquired from the transaction front-end server.

7. A dynamic routing contactless card transaction front-end server, characterized in that: include: The area determination unit is used to find the current transaction gateway corresponding to the current area of ​​the merchant according to the merchant's current area information and the relationship between the pre-configured area and the transaction gateway when receiving the contactless card transaction request; the contactless card transaction request includes transaction data and the merchant's current area information, the transaction data is encrypted by a preset encryption key at the merchant end and then sent, and the preset encryption key is obtained in advance from the transaction front-end server; A decryption unit, used to decrypt the encrypted transaction data using the preset encryption key to obtain decrypted transaction data; An encryption key determination unit, configured to determine an encryption key corresponding to the current transaction gateway according to the current transaction gateway and a relationship between a pre-configured transaction gateway and an encryption key distributed to a merchant; The re-encryption unit is used to re-encrypt the decrypted transaction data using the encryption key corresponding to the current transaction gateway to obtain the re-encrypted transaction data; The feedback unit is used to send the re-encrypted transaction data to the current transaction gateway to complete the subsequent transaction processing, and return the transaction processing result fed back by the current transaction gateway to the merchant end.

8. A dynamically routed contactless card transaction merchant terminal, characterized in that: include: An identification unit, used to identify the merchant's current area information when receiving a contactless card transaction request; The contactless card transaction request includes transaction data; An encryption unit, used to encrypt transaction data according to a preset encryption key pre-acquired from a transaction front-end server; The sending unit is used to send the encrypted transaction data and the merchant's current area information to the transaction front-end server; the transaction front-end server is used to find the current transaction gateway corresponding to the merchant's current area according to the merchant's current area information and the pre-configured relationship between the area and the transaction gateway; the encrypted transaction data is decrypted using the preset encryption key to obtain the decrypted transaction data; According to the current transaction gateway, and the relationship between the pre-configured transaction gateway and the encryption key distributed to the merchant, the encryption key corresponding to the current transaction gateway is determined; the decrypted transaction data is re-encrypted using the encryption key corresponding to the current transaction gateway to obtain re-encrypted transaction data; the re-encrypted transaction data is sent to the current transaction gateway to complete the subsequent transaction processing, and the transaction processing result fed back by the current transaction gateway is returned to the merchant.

9. A contactless card transaction system with dynamic routing, characterized in that: include: The merchant terminal as claimed in claim 8, and the transaction front-end server as claimed in claim 7.

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

Images