A POS terminal transaction verification method and system based on the Internet of Things

Abstract

The application discloses a POS terminal transaction verification method and system based on Internet of Things, and relates to the technical field of Internet of Things.The method comprises the following steps: acquiring transaction request data, performing version identification and integrity verification, locally analyzing and encapsulating to generate a first processing result if the protocol version is successfully identified and the verification is passed, otherwise, calculating a hash message authentication code as a security credential, sending the data and the credential to a target service address and receiving a second processing result, and outputting a transaction instruction according to the first or second processing result.The application solves the problems of transaction verification delay and security risk caused by protocol incompatibility of the POS terminal through intelligent shunting and security credential mechanism, and improves transaction processing efficiency and security.

Description

Technical Field

[0001] This application relates to the field of Internet of Things (IoT) technology, and more specifically, to a POS terminal transaction verification method and system based on IoT. Background Technology

[0002] In the Internet of Things (IoT) environment, POS terminals, as key devices connecting consumers, merchants, and payment networks, bear a central responsibility for their internal payment protocol parsing components. However, as payment technologies and security standards evolve, payment service providers upgrade their protocols, while POS terminal firmware updates often lag behind. This can lead to the terminal failing to fully recognize or correctly process new payment protocol data, triggering computationally intensive internal compatibility attempts and severely impacting transaction verification speed. Furthermore, this protocol incompatibility can also affect the normal operation of the terminal's internal security encryption components, posing a challenge to the security of sensitive transaction data.

[0003] For example, in a large commercial complex, multiple merchants use POS terminals from different batches and models. Recently, a dominant digital payment service provider in the area, in response to increasingly stringent industry data security standards and to further enhance user privacy protection, comprehensively upgraded the data encryption and encapsulation specifications of its core payment protocol. This upgrade introduced more complex encryption methods and new data field structures, aiming to provide a higher level of security. However, considering the large existing stock of POS terminals in the market and the cyclical differences in their upgrade cycles, the service provider did not adopt a strategy of forcing all terminals to immediately update synchronously. Instead, they chose a gradual compatibility strategy, allowing the old and new protocols to coexist for a period of time and gradually guiding merchants to upgrade their terminal devices. While this strategy offers flexibility in commercial promotion, it sows the seeds for future technical compatibility issues.

[0004] In this progressively compatible environment, if a POS terminal has not yet updated its firmware, its internal payment protocol parsing module will still be designed based on the older specification. Problems will arise when it receives a transaction request from a digital payment tool that has been updated to the new protocol. The older parsing module will be unable to fully recognize or correctly deconstruct the specific data fields and encryption structures introduced in the new protocol. In this case, when processing these new structures, the older parsing module may experience deviations or omissions in key information (such as transaction amount and payment voucher integrity identifiers), resulting in incomplete or inaccurate data at the parsing stage.

[0005] Furthermore, the POS terminal's firmware had a potential flaw in its initial error handling mechanism. When the payment protocol parsing module encountered a new protocol data structure that it couldn't recognize or correctly decompose, it didn't immediately declare parsing failure and terminate the current request. Instead, it was designed to trigger a resource-intensive "compatibility backtracking" procedure. This procedure attempted to "guess" and adapt to the new protocol data by repeatedly comparing various older parsing logics and data formats. This continuous, inefficient looping and log writing significantly consumed the computing power and memory bandwidth of the POS terminal's CPU. Therefore, even under normal customer traffic, processing a single new protocol transaction request would drastically reduce the overall POS terminal system's response speed, resulting in significant transaction verification delays.

[0006] Because the payment protocol parsing module's understanding of the new protocol is incomplete, it cannot correctly execute the key negotiation process or secure message encapsulation required by the new protocol when attempting to interact with the security encryption chip inside the POS terminal. When the old parsing module cannot provide data or instructions that meet these new requirements, the end-to-end encryption protection chain that should be provided by the security encryption chip breaks. This means that the integrity and confidentiality of sensitive transaction data during processing within the POS terminal and transmission to the payment network face higher risks, potentially existing in an insufficiently protected form at some stages, thus weakening the overall security protection capability. Ultimately, under the combined influence of the above factors, when a customer uses their digital payment tool, updated to the latest protocol version, to make a payment, the POS terminal faces multiple challenges. First, the payment protocol parsing module's inadequate understanding of the new protocol leads to data parsing errors; second, the internal defect's exception handling mechanism is triggered, resulting in slow system response and significant transaction verification delays; finally, the critical security encryption mechanism fails due to protocol incompatibility, exposing transaction data to security risks. These problems work together to cause repeated transaction failures, forcing customers to try multiple times or even change payment methods. This not only severely damages the user's payment experience but also exposes merchants to transaction interruptions, potential fund security risks, and subsequent reconciliation and compliance challenges. This scenario highlights the urgent need for POS terminals in the Internet of Things (IoT) environment to intelligently adapt to multiple protocols, provide low-latency responses, and enhance security verification in the face of rapid iterations in payment protocols.

[0007] To address the aforementioned issues, existing technologies urgently need improvement. Summary of the Invention

[0008] This application discloses a POS terminal transaction verification method and system based on the Internet of Things (IoT), aiming to solve the problems of slow transaction verification speed, security challenges, and poor user experience caused by protocol incompatibility when POS terminals face rapid iteration of payment protocols in the IoT environment.

[0009] The technical solution of this application is as follows: In the first aspect, this application discloses a POS terminal transaction verification method based on the Internet of Things, including the following steps: acquiring transaction request data, and performing version identification and integrity verification on the transaction request data respectively; when the protocol version is successfully identified and the integrity verification passes, parsing and encapsulating the transaction request data that has passed the integrity verification according to the identified protocol version to generate a first processing result; when the protocol version cannot be successfully identified or the integrity verification fails, calculating the hash message verification code of the transaction request data as a security credential, and sending the transaction request data and security credential to a preset target service address according to the version identification result and the integrity verification result, and receiving a second processing result from the target service address; outputting a transaction result indication according to the first processing result or the second processing result received from the target service address.

[0010] Through this technical solution, this application can intelligently identify the protocol version and integrity of transaction request data. Data that conforms to the protocol specifications is processed locally and efficiently, while abnormal or unknown protocol data is forwarded to the target service address for processing through security credentials. This effectively solves the compatibility problem of POS terminals in scenarios where new and old protocols are mixed, improves the efficiency and security of transaction verification, and avoids resource waste and transaction delays caused by protocol incompatibility.

[0011] Furthermore, version identification and integrity verification are performed on the transaction request data, including the following steps: parsing the protocol header of the transaction request data and matching the parsing result with the pre-stored protocol version identifier to identify the protocol version of the transaction request data; performing integrity verification on the transaction request data, including: checking whether the length of the transaction request data is within a preset range, and / or calculating the checksum of the transaction request data and comparing the checksum with the checksum field carried in the transaction request data.

[0012] Through this technical solution, this application can ensure the accuracy of protocol version identification and the reliability of data integrity judgment for transaction request data by parsing the protocol header and performing multi-dimensional integrity verification, providing a solid foundation for subsequent intelligent processing and effectively avoiding misjudgments caused by data format or content errors.

[0013] Based on this, the transaction request data that has passed the integrity check is parsed and encapsulated according to the identified protocol version, including the following steps: Parsing the fields of the transaction request data that has passed the integrity check according to the field definitions corresponding to the identified protocol version to obtain the parsed transaction data; Encapsulating the parsed transaction data into a transaction message according to the field definitions corresponding to the identified protocol version, as the first processing result.

[0014] Through this technical solution, this application can finely parse and encapsulate transaction data based on the accurately identified protocol version, ensuring that the locally processed transaction data is in the correct format and complete in content, thereby significantly improving the accuracy and efficiency of local transaction verification.

[0015] Furthermore, calculating the hash message verification code of the transaction request data as a security credential includes the following steps: obtaining a preset key; using the key to perform hash message verification code calculation on the transaction request data to generate a security credential.

[0016] Through this technical solution, this application can generate a high-strength security credential for transaction request data of abnormal or unknown protocols by means of a hash message verification code (HMAC) mechanism, which ensures the integrity and authenticity of the data during the forwarding process. Even if the data itself cannot be parsed locally, its security is effectively guaranteed.

[0017] In some preferred embodiments, before calculating the hash message verification code of the transaction request data as a security credential, the method further includes: generating a structured instruction package containing a recommended processing method and a target service address; and sending the transaction request data and security credential to a preset target service address. Specifically, according to the recommended processing method in the structured instruction package, the transaction request data, security credential, version identification result, and integrity verification result are sent to the target service address in the structured instruction package.

[0018] Through this technical solution, this application can pre-generate structured instruction packages to clarify the recommended processing method and target service address for abnormal data, making the forwarding and processing of abnormal data more intelligent and automated, and further improving the system's adaptability and processing efficiency to complex scenarios.

[0019] More specifically, in some implementation schemes, a structured instruction packet containing a recommended processing method and a target service address is generated. Specifically, the structured instruction packet sets a type field for the recommended processing method, the value of which is used to indicate the forwarding operation; and sets an address field for the target service address, the value of which is used to indicate the network location of the server receiving the transaction request data and security credentials.

[0020] This technical solution enables the clear and controllable forwarding instructions for abnormal data by explicitly defining type and address fields in the structured instruction packet, ensuring that the data can be accurately sent to the designated processing server and further optimizing the accuracy of the abnormal handling process.

[0021] Preferably, the preset target service address is the address of the back-end payment network or the address of the edge service; when the protocol version cannot be successfully identified or the integrity verification fails, if the preset target service address is the address of the back-end payment network, the transaction request data and security credentials are sent to the back-end payment network, and the second processing result is received from the back-end payment network; when the protocol version cannot be successfully identified or the integrity verification fails, if the preset target service address is the address of the edge service, the transaction request data and security credentials are sent to the edge service, and the second processing result is received from the edge service.

[0022] Through this technical solution, this application can flexibly choose to forward abnormal data to the back-end payment network or edge service for processing according to different business needs and network environments, thereby achieving optimal utilization of resources and maximizing processing efficiency, and improving the flexibility and scalability of the system.

[0023] Based on the above, this application further proposes that when the protocol version cannot be successfully identified and the integrity verification passes, the transaction request data is marked as dynamically encoded protocol data, and the dynamically encoded protocol data mark, the transaction request data, and the security credentials are sent together to the target service address.

[0024] Through this technical solution, this application can clearly mark specific types of abnormal data (i.e., data with unknown protocol versions but passed integrity), enabling the target service address to be processed in a targeted manner, such as performing dynamic protocol parsing, thereby improving the intelligence level and success rate of abnormal data processing.

[0025] As a technical improvement, when the protocol version is successfully identified but the integrity verification fails, the transaction request data is marked as data to be repaired, and the marked data to be repaired, the transaction request data, and the security credentials are sent together to the target service address.

[0026] Through this technical solution, this application can clearly mark another specific type of abnormal data (i.e., data whose protocol version is known but whose integrity has not passed), enabling the target service address to perform data repair or anomaly investigation, thereby improving the system's ability to recover damaged data and its overall robustness.

[0027] Secondly, this application also discloses a POS terminal transaction verification system based on the Internet of Things, comprising: a data acquisition module for acquiring transaction request data; a verification module for performing version identification and integrity verification on the transaction request data; a first processing module for parsing and encapsulating the transaction request data that has passed integrity verification according to the identified protocol version when the protocol version is successfully identified and the integrity verification passes, thereby generating a first processing result; a second processing module for calculating a hash message verification code of the transaction request data as a security credential when the protocol version cannot be successfully identified or the integrity verification fails, and sending the transaction request data and security credential to a preset target service address according to the version identification result and the integrity verification result, and receiving a second processing result from the target service address; and an output module for outputting a transaction result indication according to the first processing result or the second processing result.

[0028] Through this technical solution, the system of this application can achieve intelligent identification, efficient local processing, and secure forwarding of transaction request data through modular design, thereby constructing an efficient, secure, and flexible POS terminal transaction verification architecture, effectively solving the problems of poor protocol compatibility, low processing efficiency, and high security risks in the prior art. Beneficial effects

[0029] The IoT-based POS terminal transaction verification method disclosed in this application first identifies and verifies the integrity of transaction request data after acquisition. When the protocol version is successfully identified and the integrity verification passes, the system can locally parse and encapsulate the transaction request data according to the identified protocol version, generating a first processing result. This enables fast and efficient processing of standard and complete transaction requests, avoiding unnecessary resource consumption. When the protocol version cannot be successfully identified or the integrity verification fails, the system no longer attempts inefficient internal compatibility backtracking. Instead, it calculates a hash message verification code for the transaction request data as a security credential and sends the transaction request data and security credential to a preset target service address for further processing based on the version identification and integrity verification results, and receives a second processing result. This mechanism effectively avoids the POS terminal falling into the resource-intensive "compatibility backtracking" dilemma due to protocol incompatibility, significantly improves the response speed of transaction verification, and solves the problem of transaction verification delay in existing technologies. Meanwhile, by generating hash message verification codes as security credentials, the integrity and authenticity of abnormal or unknown protocol data are ensured during forwarding. Even if the data cannot be parsed locally, its security is effectively guaranteed, overcoming the shortcomings of existing technologies where the failure of security encryption components leads to challenges in protecting sensitive transaction data. Finally, the system outputs a transaction result indication based on either the first processing result from local processing or the second processing result from remote processing, achieving intelligent adaptation and efficient processing of various transaction requests. This significantly improves the user payment experience and reduces the operational risks for merchants. In summary, this application, through intelligent protocol identification, traffic diversion processing, and security credential mechanisms, effectively solves a series of technical problems faced by POS terminals in the Internet of Things environment when dealing with rapid iterations of payment protocols, such as poor protocol compatibility, low processing efficiency, high security risks, and poor user experience. It has significant progressive and practical value. Attached Figure Description

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

[0031] Figure 1 A flowchart illustrating a POS terminal transaction verification method based on the Internet of Things (IoT) provided in this embodiment of the invention; Figure 2 A flowchart of the parsing and encapsulation steps provided in the embodiments of the present invention; Figure 3 A flowchart for obtaining security credentials provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of a POS terminal transaction verification system based on the Internet of Things, provided in an embodiment of the present invention. Detailed Implementation

[0032] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0033] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0034] Traditional POS terminals, when processing payment protocols, may fail to fully recognize or correctly process new payment protocol data due to outdated firmware updates. This triggers internal compatibility attempts that consume significant computing resources, severely impacting transaction verification speed. Furthermore, this protocol incompatibility can affect the normal operation of the terminal's internal security encryption components, posing a challenge to the security of sensitive transaction data.

[0035] like Figure 1 As shown, this application proposes a POS terminal transaction verification method based on the Internet of Things, including the following steps: S1. Obtain transaction request data, and perform version identification and integrity verification on the transaction request data respectively; S21. When the protocol version is successfully identified and the integrity verification is passed, the transaction request data that has passed the integrity verification is parsed and encapsulated according to the identified protocol version to generate a first processing result; S22. When the protocol version cannot be successfully identified or the integrity verification fails, calculate the hash message verification code of the transaction request data as a security credential, and send the transaction request data and the security credential to a preset target service address according to the result of the version identification and the result of the integrity verification, and receive a second processing result from the target service address; S3. Output a transaction result indication based on the first processing result or the second processing result received from the target service address.

[0036] In step S1, transaction request data refers to the raw payment information received by the POS terminal from payment tools (such as bank cards, mobile payment applications, etc.), which typically includes the transaction amount, merchant information, payment vouchers, etc. Version identification refers to identifying the payment protocol version followed by the transaction request data to determine the subsequent data parsing and processing methods. Integrity verification refers to verifying whether the transaction request data has been tampered with or damaged during transmission, ensuring data reliability.

[0037] In step S21, the first processing result refers to the transaction message generated after parsing and encapsulation when the transaction request data meets the expected protocol version and the integrity verification passes, which can be directly used for subsequent transaction processing.

[0038] In step S22, Hash Message Authentication Code (HMAC) is a security mechanism used to verify data integrity and authenticate the message source. It generates a fixed-length verification code using a key and a hash function. The security credential refers to the verification code calculated through HMAC, used to ensure the security and integrity of transaction request data during transmission. The second processing result refers to the processing result received from the target service address after forwarding the data to the target service address when the transaction request data cannot identify the protocol version or fails integrity verification. The target service address refers to the address of the backend server used to process abnormal or unknown protocol transaction requests; it can be the address of a backend payment network or edge service.

[0039] In step S3, the transaction result indication refers to the transaction status information displayed to the user or merchant based on the processing result, such as transaction success, transaction failure, or processing status. The implementation environment of this application is typically a POS terminal in an IoT environment, which has data acquisition, processing, communication, and output capabilities, and can interact with payment tools, back-end payment networks, or edge services.

[0040] The core of the IoT-based POS terminal transaction verification method proposed in this application lies in the intelligent preprocessing and distribution of transaction request data to cope with the rapid iteration and diversity of payment protocols. Specifically, after acquiring transaction request data, version identification and integrity verification are required. For example, the POS terminal can be configured with a data receiving module responsible for listening to and capturing transaction requests from payment tools. Once the data is received, it is passed to a protocol parsing module. This protocol parsing module can preset multiple protocol version identifiers and attempt to identify the protocol version by comparing the protocol header information in the transaction request data with these identifiers. Simultaneously, to ensure data reliability, integrity verification can be performed on the transaction request data. For example, it can simply check whether the length of the data packet is within a preset reasonable range, or calculate the checksum of the data and compare it with the checksum field carried in the data. When the protocol version is successfully identified and the integrity verification passes, it indicates that the transaction request data conforms to the standard data of the current POS terminal's processing capabilities. At this point, based on the identified protocol version, the transaction request data that has passed the integrity verification is parsed and encapsulated to generate the first processing result. For example, the protocol parsing module can parse the transaction request data based on the field definitions corresponding to the identified protocol version, extracting key information such as transaction amount, card number, and expiration date. Then, based on the same protocol version field definitions, the parsed transaction data is repackaged into a standard transaction message as the first processing result. This process ensures that standard transactions are processed efficiently and accurately. However, if the protocol version cannot be successfully identified or the integrity check fails, it indicates that the transaction request data may be abnormal, such as new protocol data, corrupted data, or malicious data. In this case, to avoid invalid internal compatibility attempts by the terminal and to ensure data security, a hash message verification code for the transaction request data needs to be calculated as a security credential. For example, the POS terminal can have a built-in security module that pre-stores a key for HMAC operations. When abnormal data is received, the security module uses the preset key to perform an HMAC operation on the entire transaction request data, generating a unique security credential. Subsequently, based on the version identification result and the integrity check result, the transaction request data and the security credential are sent to a preset target service address, and the second processing result is received from that target service address. For example, the communication module of a POS terminal can package the original transaction request data, the generated security credentials, and detailed results of version identification and integrity verification, and send them over the network to a pre-set back-end payment network or edge service. These remote services typically have more powerful processing capabilities and more comprehensive protocol libraries, enabling them to further analyze, repair, or forward abnormal data. Finally, based on the first processing result or the second processing result received from the target service address, a transaction result indication is output.For example, the display module of a POS terminal can show users or merchants information such as "transaction successful," "transaction failed," or "transaction in progress" based on the received processing results. If the received result is the first processing result, the transaction status is indicated directly based on its content; if the received result is the second processing result, the transaction status is indicated based on the result returned by the remote service.

[0041] In summary, this application effectively solves the problems of low transaction verification efficiency, insufficient data security, and excessive resource consumption in existing POS terminals when facing rapid iterations of payment protocols by introducing preprocessing, secure credential generation, and intelligent diversion mechanisms. It provides a more efficient, secure, and flexible solution for POS terminal transaction verification in the Internet of Things environment.

[0042] The steps of performing version identification and integrity verification on transaction request data can be further refined into the following operations: The protocol header of the transaction request data is parsed, and the parsing result is matched with a pre-stored protocol version identifier to identify the protocol version of the transaction request data; Performing the integrity check on the transaction request data includes: checking whether the length of the transaction request data is within a preset range, and / or calculating the checksum of the transaction request data, and comparing the checksum with the checksum field carried in the transaction request data.

[0043] The version identification process begins by parsing the protocol header of the transaction request data. This header typically contains crucial information such as the data packet format and protocol version. After parsing, the obtained protocol version information is compared with a pre-stored list of protocol version identifiers in the system. This matching process aims to determine the specific protocol version followed by the current transaction request data, ensuring correct data parsing and processing subsequently.

[0044] Performing integrity checks on transaction request data can be understood as verifying whether the data has been damaged or tampered with during transmission. Specifically, this verification process may include checking whether the overall length of the transaction request data falls within a preset valid range. This effectively prevents abnormal processing caused by data truncation or padding errors.

[0045] Calculate the checksum of the transaction request data and compare it with the checksum field carried in the transaction request data itself. Checksum is a commonly used data integrity verification mechanism. By comparing the calculated checksum with the checksum contained in the original data, it can be determined whether the data has maintained its integrity during transmission.

[0046] This application's solution concretizes the abstract steps of version identification and integrity verification, enabling the POS terminal to systematically perform preliminary legality and validity checks on received transaction request data. Parsing the protocol header and matching the version identifier ensures the system can correctly understand and process data formats from different protocol versions. Simultaneously, by checking data length and comparing checksums, abnormal or tampered transaction request data can be promptly detected and intercepted, thus preventing illegitimate data from being introduced into subsequent processing.

[0047] like Figure 2 As shown, the process of parsing and encapsulating the transaction request data that has passed the integrity check based on the identified protocol version includes the following steps A1 to A2: A1. Based on the field definitions corresponding to the identified protocol version, parse the fields of the transaction request data that has passed the integrity check to obtain the parsed transaction data; A2. Based on the field definitions corresponding to the identified protocol version, the parsed transaction data is encapsulated into a transaction message, which is used as the first processing result.

[0048] The "field definition" refers to the pre-defined specifications for data structure, field order, field length, data type, and encoding method for a specific protocol version. These definitions are typically stored in the system's configuration library or protocol dictionary to ensure accurate lookup and application when processing data from different protocol versions. Field parsing of transaction request data that has passed integrity verification involves identifying and extracting various business fields (such as transaction type, transaction amount, card number, validity period, and merchant information) from the original transaction request data stream or data block according to the field definitions corresponding to the identified protocol version, based on a pre-defined structure and rules. This process aims to transform the raw, potentially inconsistent data into structured, easily processed parsed transaction data. Further, encapsulating the parsed transaction data into a transaction message involves reorganizing and encoding this parsed transaction data according to the field definitions corresponding to the identified protocol version, and possibly adding necessary message headers, message trailers, or security information to form a transaction message conforming to the specific transaction protocol specifications. This transaction message serves as the first processing result and can be used in subsequent transaction processing procedures, such as sending it to the back-end payment system for clearing or authorization.

[0049] This application's solution, by clearly defining the specific steps of parsing and encapsulation, ensures accurate processing of transaction request data when the protocol version is successfully identified and data integrity verification passes. First, by parsing fields according to the field definitions corresponding to the protocol version, all necessary transaction information can be accurately extracted from the raw data, avoiding parsing errors caused by protocol format differences. Second, by encapsulating the parsed data into standardized transaction messages based on the same field definitions, it ensures that the generated initial processing result meets the requirements of subsequent processing systems, thereby enabling the transaction data to be correctly understood and processed.

[0050] like Figure 3 As shown, calculating the hash message verification code of the transaction request data as a security credential includes the following steps B1 to B2: B1. Obtain the preset key; B2. Use the key to perform a hash message verification code operation on the transaction request data to generate the security credential.

[0051] Obtaining the preset key refers to pre-establishing and securely storing a shared secret information between the POS terminal and the target service address. This key can be a symmetric key, and it can be obtained by pre-configuring it through a secure channel, or dynamically generating and securely distributing it during system initialization or the first communication via a key negotiation protocol. The security of this key is crucial for the subsequent generation of security credentials. Further, performing a hash message verification code operation on the transaction request data using the key involves employing a Message Authentication Code (MAC) algorithm, such as a hash function-based Message Authentication Code (HMAC) algorithm, combined with the preset key and the transaction request data, to generate a fixed-length hash value. This operation aims to ensure data integrity and verify the source of the data. For example, the HMAC-SHA256 algorithm can be used, taking the transaction request data as input and performing a hash operation using the preset key to generate a unique hash message verification code. Thus, the security credential is generated, which is the result obtained through the hash message verification code operation. This security credential, as a digital fingerprint or authentication tag of the transaction request data, proves that the transaction request data has not been tampered with during transmission and indeed originates from a legitimate POS terminal possessing the preset key.

[0052] This application's solution generates a security credential by performing a hash message verification code operation on the transaction request data when the protocol version cannot be successfully identified or the integrity verification fails. Specifically, a preset key is first obtained; this key is secret information shared between the POS terminal and the target service address, providing the foundation for subsequent authentication. Then, the original transaction request data is hashed using this key to generate a unique security credential. This security credential is sent to the target service address along with the transaction request data, allowing the target service address to perform an independent hash message verification code operation on the received transaction request data using the same preset key and compare the result with the received security credential. In this way, even if the transaction request data itself has format or version issues, its integrity and authenticity of origin can still be effectively verified, thereby avoiding the risk of malicious tampering or forgery of data.

[0053] In some embodiments of this application described above, before calculating the hash message verification code of the transaction request data as a security credential, the method further includes: generating a structured instruction packet containing a recommended processing method and a target service address; The step of sending the transaction request data and the security credential to the preset target service address specifically involves: According to the recommended processing method in the structured instruction package, the transaction request data, the security credential, the version identification result, and the integrity verification result are sent to the target service address in the structured instruction package.

[0054] The phrase "generating a structured instruction package containing recommended processing methods and target service addresses" refers to the process where, when the system detects anomalies in transaction request data (e.g., the protocol version cannot be successfully identified or integrity verification fails), instead of simply sending the data to a fixed, preset target service address, it first constructs an instruction package containing processing guidance information. This structured instruction package can be understood as a data structure containing suggestions or instructions on how to handle the current abnormal transaction data. For example, the recommended processing method could indicate retrying, forwarding to a specific repair service, logging and issuing an alarm, or directly rejecting the transaction. The target service address refers to the specific network location where the data should ultimately be sent according to the recommended processing method. This could be a specific processing node in the backend payment network, a diagnostic module in an edge service, or a server specifically used for abnormal data analysis. The purpose is to provide clear guidance and routing information for subsequent abnormal data processing, improving the intelligence and flexibility of the processing.

[0055] The phrase "sending the transaction request data, the security credential, the version identification result, and the integrity verification result to the target service address in the structured instruction package according to the recommended processing method in the structured instruction package" can be understood as follows: after generating the structured instruction package, the system will execute the data sending operation according to the recommended processing method explicitly specified in the instruction package. This means that the sending behavior is no longer blind but strategic. For example, if the recommended processing method indicates that it needs to be forwarded to the repair service, the system will package the transaction request data, the calculated security credential (hash message verification code), the version identification result and integrity verification result that caused the anomaly together, and send them to the target service address specified in the structured instruction package (i.e., the address of the repair service). This method ensures that abnormal data can be accurately routed to the service node most suitable for handling this type of anomaly, while the accompanying identification and verification results can help the receiver diagnose the problem more quickly. Its purpose is to achieve intelligent routing and targeted processing of abnormal transaction data, avoiding the limitations of a single fixed target address, and improving the efficiency and accuracy of anomaly handling.

[0056] This application's solution effectively addresses the lack of flexibility and specificity in abnormal data forwarding in basic solutions by introducing a step of generating structured instruction packets before sending abnormal transaction data. Specifically, when the protocol version cannot be successfully identified or integrity verification fails, the system no longer simply sends data to a preset fixed address. Instead, it dynamically generates an instruction packet containing a recommended processing method and a target service address based on the specific abnormal situation. The recommended processing method in this instruction packet guides the system to take the most appropriate follow-up action, such as forwarding to a dedicated repair service, logging service, or manual intervention platform, while the target service address ensures that the data is accurately routed to the corresponding processing node. Thus, this intelligent instruction packet guidance mechanism makes the processing flow of abnormal transaction data more refined and automated, avoiding the inefficiencies or improper handling that may result from fixed routing.

[0057] In some preferred embodiments, a specific example is given below. Suppose a POS terminal receives transaction request data. During version identification, the system finds that the protocol version of the transaction request data does not match any pre-stored protocol versions, meaning it cannot successfully identify the protocol version. Simultaneously, integrity verification may also fail, for example, due to checksum inconsistency. In this case, the system does not directly send the data to the default backend payment network. Instead, it first generates a structured instruction packet. In this instruction packet, the recommended processing method type field is set to "forward to protocol repair service," and the target service address address field is set to "IP address or domain name of the protocol repair service server." Subsequently, according to the instructions in this structured instruction packet, the system packages the original transaction request data, the calculated hash message verification code (security credential), and the results of version identification failure and integrity verification failure together, and sends them to the designated protocol repair service server. After receiving the data, the protocol repair service server can attempt to perform protocol adaptation or data repair on the transaction data based on the accompanying version identification and integrity verification results, thereby achieving more refined and intelligent processing of abnormal transactions and avoiding the problems that may arise from simple discarding or uniform forwarding.

[0058] This application further proposes the above-mentioned method of generating a structured instruction package containing the recommended processing method and the target service address, including: The structured instruction packet includes a type field for the recommended processing method, the value of which indicates the forwarding operation. The structured instruction packet includes an address field for the target service address, the value of which indicates the network location of the server receiving the transaction request data and the security credentials.

[0059] The structured instruction package is designed as a data structure containing multiple fields to carry different instruction information. Specifically, the recommended processing method type field is a key component of this structured instruction package, and its value is specifically set to indicate that abnormal transaction request data should be forwarded. This means that when the POS terminal encounters a situation where the protocol version cannot be successfully identified or the integrity verification fails when processing transaction request data, this type field will explicitly instruct the system not to perform local processing, but to forward the data to other service entities.

[0060] The structured instruction packet also includes an address field for the target service address. The value of this address field is used to precisely indicate the network location of the server receiving the transaction request data and the security credentials. This server can be a specific node in the backend payment network or a processing unit in the edge service. By explicitly specifying this network location, it can be ensured that abnormal transaction request data and its security credentials can be accurately routed to a backend system with the appropriate processing capabilities, thereby enabling centralized management and handling of abnormal situations.

[0061] This application's solution explicitly sets the recommended processing method type field and the target service address address field in the structured instruction packet. This enables the POS terminal to generate an instruction packet containing clear processing instructions and target routing information when faced with abnormal transaction request data. When the transaction request data cannot be identified or verified locally, the system can accurately send the transaction request data, security credentials, and version identification and integrity verification results to the server network location specified in the address field, according to the forwarding operation indicated by the type field in the structured instruction packet. This ensures effective diversion and processing of abnormal data, avoids bottlenecks or errors in local processing, and provides necessary information and routing guidance for subsequent centralized anomaly handling.

[0062] This application further proposes that the aforementioned preset target service address be the address of the backend payment network or the address of the edge service. Specifically, when the protocol version cannot be successfully identified or the integrity verification fails, if the aforementioned preset target service address is configured as the address of the backend payment network, the transaction request data and the security credential will be sent to the backend payment network, and the second processing result will be received from the backend payment network.

[0063] In this context, the back-end payment network typically refers to a centralized system operated by financial institutions or payment service providers to process large volumes of transactions and conduct final settlements. It possesses powerful processing capabilities and high security, enabling in-depth analysis and processing of complex and abnormal transactions.

[0064] When the protocol version cannot be successfully identified or the integrity verification fails, if the preset target service address is configured as the address of the edge service, the transaction request data and the security credentials will be sent to the edge service, and the second processing result will be received from the edge service. An edge service can be understood as computing resources deployed in a local network or regional network close to the POS terminal, such as edge servers or gateway devices. Its purpose is to provide low-latency, distributed data processing capabilities, enabling preliminary processing or forwarding of specific types of abnormal transactions, thereby reducing the burden on the back-end payment network.

[0065] This application's solution introduces backend payment network addresses and edge service addresses as optional preset target service addresses. This allows the system to flexibly select different processing paths based on actual needs and system strategies when handling transaction request data that fails protocol version identification or integrity verification. When comprehensive and in-depth risk assessment and processing are required, data can be routed to the backend payment network, utilizing its powerful processing capabilities and rich business logic. Conversely, when rapid response, reducing core network load, or localized processing are needed, data can be routed to edge services, thereby achieving more efficient and low-latency abnormal transaction processing. This mechanism effectively avoids the processing bottlenecks and inefficiencies that may arise from a single target address.

[0066] In some preferred embodiments, suppose an IoT POS terminal fails to identify the protocol version when processing a transaction request. If the system's preset target service address is configured as the address of the backend payment network, the POS terminal will send the transaction request data and the calculated hash message verification code as security credentials to the backend payment network. Upon receiving this data, the backend payment network can utilize its comprehensive risk control system and business rule engine to conduct in-depth analysis of the abnormal transaction, such as attempting protocol version recovery, manual review, or risk assessment, ultimately generating a second processing result and returning it to the POS terminal. The POS terminal then outputs a transaction instruction based on this result. For example, as another specific implementation, if the system's preset target service address is configured as the address of an edge service, the POS terminal will send the transaction request data and security credentials to the edge service deployed in a local or regional network. The edge service can perform preliminary classification or filtering of the abnormal transaction according to preset lightweight rules, such as determining whether it is a known type of error or implementing a simple retry mechanism. If the edge service can handle the data, it directly generates the second processing result; if it cannot handle the data, it can further forward the data to the back-end payment network, thereby achieving layered processing, effectively reducing the direct load on the back-end payment network, and potentially shortening the processing time for some abnormal transactions.

[0067] This application further proposes that when the protocol version cannot be successfully identified and the integrity verification passes, the transaction request data is marked as dynamically encoded protocol data, and the dynamically encoded protocol data mark, the transaction request data, and the security credentials are sent together to the target service address.

[0068] Dynamically encoded protocol data refers to transaction request data that may employ a non-standard or dynamically changing protocol format, making it unrecognizable by the local system using pre-stored protocol version identifiers. However, its data structure and content maintain integrity during transmission. Marking transaction request data as dynamically encoded protocol data can be achieved by adding a specific identifier, flag, or metadata field to the sent data packet. This marker explicitly indicates that the transaction request data belongs to the dynamically encoded type. The marker can be a boolean value, such as "isDynamicProtocol" set to true, or an enumeration value, such as "protocolType" set to "DYNAMIC". In this way, the target service address, upon receiving the data, can identify the data's specificity based on this marker, thereby initiating a specific processing procedure for dynamically encoded protocol data.

[0069] This application's solution addresses the limitation of the basic solution's uniform handling of all protocol version identification failures by dynamically encoding protocol data and marking it under specific conditions (i.e., when protocol version identification fails but integrity verification passes). This encoding, along with security credentials, is then sent to the target service address. Because of this explicit marking of specific data, the target service address, upon receiving the data, can immediately identify that the transaction request data may not be erroneous in the traditional sense, but rather uses a dynamic or novel protocol that the local system cannot recognize. Therefore, the target service address can use this marking to initiate a dedicated parsing module or forwarding mechanism for dynamically encoded protocol data. For example, it can route the data to a backend service with stronger protocol parsing capabilities or a dedicated protocol adapter for processing, avoiding the misjudgment of potentially valid transaction data as completely invalid data, thereby improving the flexibility and success rate of transaction processing.

[0070] In some preferred embodiments, suppose an IoT POS terminal receives transaction request data. During version identification of this data, it is found that its protocol header does not match any pre-stored protocol version identifiers, meaning the protocol version cannot be successfully identified. However, during integrity verification, by checking the data length and calculating the checksum, the transaction request data is found to be complete and tamper-proof. In this case, the POS terminal determines that the data may have used some kind of dynamic encoding protocol. At this point, the POS terminal generates a flag, for example, by adding a field "protocol_status: dynamic_unrecognized" to the metadata of the data packet, and packages this flag, the original transaction request data, and the calculated hash message verification code (security credential) together, sending them to a preset target service address, such as the protocol adaptation service of the backend payment network. Upon receiving the data packet, the protocol adaptation service of the backend payment network, based on the "dynamic_unrecognized" flag, will activate a dedicated dynamic protocol parsing engine to attempt to parse and process the transaction request data, rather than simply rejecting it as an invalid transaction.

[0071] This application further proposes that when the protocol version is successfully identified and the integrity verification fails, the transaction request data is marked as data to be repaired, and the marked data to be repaired, the transaction request data, and the security credentials are sent together to the target service address.

[0072] Marking transaction request data as data to be repaired involves attaching a specific identifier or metadata to the data before sending it. This indicates that although the protocol version is identifiable, the data has integrity issues and requires repair. The marker for data to be repaired can be a specific field value, a flag, or a structured label, its purpose being to clearly communicate the data's status and suggested processing to the recipient. For example, a status code can be set in the header or appendix field of the sent data packet, with the value indicating "to be repaired." Sending the marker for the data to be repaired, the transaction request data, and security credentials together to the target service address means that this information is transmitted as a whole. This ensures that when the target service address receives the transaction request data, it simultaneously receives a clear indication of its integrity verification failure and security credentials for security verification, thus providing the necessary contextual information for subsequent repair procedures.

[0073] The proposed solution marks transaction request data as "data to be repaired" in specific cases where the protocol version is successfully identified but integrity verification fails, and sends this marked data along with the transaction request data and security credentials. This explicit marking allows the target service address to immediately identify that the anomaly is due to an integrity issue rather than a protocol version problem upon receiving the data, thus avoiding a uniform and potentially inefficient general processing of all anomaly data. In this way, the receiver can quickly initiate targeted data repair processes based on this marking, such as attempting data recovery, requesting retransmission, or performing manual intervention, significantly improving the intelligence and efficiency of anomaly data handling.

[0074] In some preferred embodiments, suppose a POS terminal, while processing a transaction, successfully identifies the protocol version of the transaction request data as "V2.0," but during integrity verification, it finds that the checksum of the data does not match the calculated checksum, causing the integrity verification to fail. In this case, the POS terminal will not directly send the data as ordinary abnormal data, but will first mark the transaction request data as "data to be repaired." Specifically, a specific status code, such as "0x02," can be set in a reserved field of the data packet sent to the target service address, indicating "integrity verification failed, to be repaired." Subsequently, the POS terminal packages the data to be repaired (containing this status code), the original transaction request data, and the calculated hash message verification code (security credential) together and sends it to the preset target service address. Upon receiving the data packet, the target service address will parse the status code "0x02," thus immediately recognizing that the transaction request data requires integrity repair processing, rather than being due to a protocol version mismatch or other types of errors. Based on this, the target service address can prioritize calling the data repair module to attempt to recover the transaction data or request the POS terminal to retransmit, thereby achieving efficient and targeted anomaly handling.

[0075] This application also discloses a POS terminal transaction verification system based on the Internet of Things, including: The data acquisition module is used to acquire transaction request data; The verification module is used to perform version identification and integrity verification on the transaction request data respectively; The first processing module is used to parse and encapsulate the transaction request data that has passed the integrity verification according to the identified protocol version when the protocol version is successfully identified and the integrity verification is passed, and generate a first processing result. The second processing module is used to calculate the hash message verification code of the transaction request data as a security credential when the protocol version cannot be successfully identified or the integrity verification fails, and to send the transaction request data and the security credential to a preset target service address according to the result of the version identification and the result of the integrity verification, and to receive the second processing result from the target service address. The output module is used to output a transaction result indication based on the first processing result or the second processing result.

[0076] This system employs a modular design to achieve intelligent preprocessing and distribution of transaction request data. The data acquisition module receives the raw transaction data, which is then verified by the verification module to identify the protocol version and ensure integrity. Based on the verification results, the system can intelligently distribute the data to the first processing module for efficient local processing, or to the second processing module for secure forwarding to the backend service.

[0077] This design effectively avoids the inefficient internal compatibility attempts of traditional POS terminals when faced with protocol incompatibility, thereby significantly improving transaction verification efficiency, ensuring data transmission security, and optimizing system resource utilization. Through the collaborative work of various modules, this system can flexibly respond to the rapid iteration and diversity of payment protocols, providing a stable, efficient, and secure verification mechanism for POS terminal transactions in the Internet of Things (IoT) environment.

[0078] The specific steps and working principle of the IoT-based POS terminal transaction verification method have been described in the above embodiments, and will not be repeated here. It should be emphasized that the IoT-based POS terminal transaction verification system proposed in this application, through its modular design, concretizes each functional step in the above method into independent, collaborative hardware or software modules, thereby achieving a more efficient and flexible system architecture.

[0079] Specifically, the data acquisition module is configured to receive transaction request data from external devices or network interfaces. This module can be a physical interface, such as a USB interface, NFC card reader, Bluetooth module, or Wi-Fi communication module, used for data interaction with payment instruments. As a preferred implementation, the data acquisition module can be integrated into the communication unit of the POS terminal, capturing transaction requests via wired or wireless means.

[0080] The verification module is configured to perform version identification and integrity verification on received transaction request data. This module can be a standalone processor unit or implemented by specific software logic on the POS terminal's main control chip. For example, the verification module may include a protocol parser that pre-stores version identifiers and verification rules for various payment protocols. In practical applications, the verification module can employ various techniques for integrity verification, such as calculating the Cyclic Redundancy Check (CRC) code of the data and comparing it with the CRC field carried in the data, or checking whether the length of the data packet conforms to a specific protocol specification.

[0081] The first processing module is configured to parse and encapsulate the transaction request data and generate a first processing result upon successful identification of the protocol version and passing integrity verification. This module can be a dedicated data processing unit or a software program executed by the main processor of the POS terminal. Specifically, the first processing module can extract fields from the transaction data by calling the corresponding parsing algorithm based on the identified protocol version, and re-encapsulate the parsed data into a standard transaction message according to a preset message format.

[0082] The second processing module is configured to calculate a hash message verification code for the transaction request data as a security credential when the protocol version cannot be successfully identified or the integrity verification fails. It then sends the data to a preset target service address and receives the second processing result. This module may include a cryptographic coprocessor or security chip to perform the hash message verification code calculation, ensuring the integrity and authenticity of the data. Furthermore, the second processing module includes a communication interface for packaging the original transaction request data, security credential, and verification result and sending them over the network to the backend payment network or edge service, and for receiving processing results from these remote services.

[0083] The output module is configured to output a transaction result indication based on a first processing result or a second processing result. This module can be a display driver for displaying transaction status information on the POS terminal's display screen, such as "Transaction Successful," "Transaction Failed," or "Processing." Additionally, the output module may include a printer interface for printing transaction slips, or a buzzer / indicator for indicating the transaction result via sound or light. As a specific implementation, the output module can be integrated with the POS terminal's user interface (UI) management unit, responsible for presenting the processing results in a user-friendly manner.

[0084] The core innovation of the IoT-based POS terminal transaction verification system proposed in this application lies in its modular design, which enables intelligent protocol identification, integrity verification, and traffic distribution, significantly improving the efficiency and security of transaction verification. Compared with existing POS terminal systems that rely on a single, fixed processing flow, this system represents a significant advancement. Existing systems, when faced with new payment protocols or abnormal data, often fall into inefficient internal compatibility attempts due to a lack of flexible modular processing mechanisms, leading to transaction verification delays and resource waste. This system, however, constructs an intelligent decision-making and traffic distribution architecture through the collaborative work of a data acquisition module, a verification module, a first processing module, a second processing module, and an output module. The verification module can quickly determine the data status and, based on the determination result, intelligently distribute the processing task to the local first processing module for efficient processing, or securely forward it to a backend service with stronger processing capabilities through the second processing module. This traffic distribution mechanism avoids the local terminal from getting bogged down in resource-intensive computations when processing unknown or abnormal data, thereby significantly improving the response speed of transaction verification and the overall system efficiency. Furthermore, by calculating a hash message verification code as a security credential through the second processing module, this system can still ensure the integrity and authenticity of transaction request data during transmission, even in cases of data anomalies or unknown protocols, effectively enhancing the end-to-end security of sensitive transaction data. The introduction of this security credential addresses the potential security deficiencies that may arise from protocol incompatibility in existing technologies.

[0085] In summary, this system, through its unique modular architecture and intelligent traffic diversion strategy, effectively solves the problems of low transaction verification efficiency, insufficient data security, and excessive resource consumption in existing POS terminals when facing rapid iterations of payment protocols. It provides a more efficient, secure, and flexible solution for POS terminal transaction verification in the Internet of Things environment.

[0086] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A POS terminal transaction verification method based on Internet of Things, characterized in that, Includes the following steps: Obtain transaction request data, and perform version identification and integrity verification on the transaction request data respectively; When the protocol version is successfully identified and the integrity verification passes, the transaction request data that has passed the integrity verification is parsed and encapsulated according to the identified protocol version to generate a first processing result; When the protocol version cannot be successfully identified or the integrity verification fails, the hash message verification code of the transaction request data is calculated as a security credential, and the transaction request data and the security credential are sent to a preset target service address according to the result of the version identification and the result of the integrity verification, and a second processing result is received from the target service address. Output a transaction result indication based on the first processing result or the second processing result received from the target service address.

2. The IoT based POS terminal transaction verification method as claimed in claim 1, wherein, The process of performing version identification and integrity verification on the transaction request data includes the following steps: The protocol header of the transaction request data is parsed, and the parsing result is matched with a pre-stored protocol version identifier to identify the protocol version of the transaction request data; Performing the integrity check on the transaction request data includes: checking whether the length of the transaction request data is within a preset range, and / or calculating the checksum of the transaction request data, and comparing the checksum with the checksum field carried in the transaction request data.

3. The IoT based POS terminal transaction verification method as claimed in claim 1, wherein, The step of parsing and encapsulating the transaction request data that has passed the integrity verification based on the identified protocol version includes the following steps: Based on the field definitions corresponding to the identified protocol version, the transaction request data that has passed the integrity check is parsed to obtain the parsed transaction data; Based on the field definitions corresponding to the identified protocol version, the parsed transaction data is encapsulated into a transaction message, which serves as the first processing result.

4. The IoT based POS terminal transaction verification method as claimed in claim 1, wherein, The calculation of the hash message verification code of the transaction request data as a security credential includes the following steps: Obtain the preset key; The security credential is generated by performing a hash message verification code operation on the transaction request data using the key.

5. The POS terminal transaction verification method based on the Internet of Things according to claim 1, characterized in that, Before calculating the hash message verification code of the transaction request data as a security credential, the method further includes: generating a structured instruction packet containing a recommended processing method and a target service address; The step of sending the transaction request data and the security credential to the preset target service address specifically involves sending the transaction request data, the security credential, the version identification result, and the integrity verification result to the target service address in the structured instruction package according to the recommended processing method in the structured instruction package.

6. The POS terminal transaction verification method based on the Internet of Things according to claim 5, characterized in that, The generation of the structured instruction package containing the recommended processing method and the target service address is specifically as follows: The structured instruction packet includes a type field for the recommended processing method, the value of which indicates the forwarding operation. The structured instruction packet includes an address field for the target service address, the value of which indicates the network location of the server receiving the transaction request data and the security credentials.

7. The POS terminal transaction verification method based on the Internet of Things according to claim 1, characterized in that, The preset target service address is the address of the back-end payment network or the address of the edge service; If the protocol version cannot be successfully identified or the integrity verification fails, and if the preset target service address is the address of the backend payment network, the transaction request data and the security credential are sent to the backend payment network, and the second processing result is received from the backend payment network. If the protocol version cannot be successfully identified or the integrity verification fails, and if the preset target service address is the address of the edge service, the transaction request data and the security credential are sent to the edge service, and the second processing result is received from the edge service.

8. The POS terminal transaction verification method based on the Internet of Things according to claim 1, characterized in that, When the protocol version cannot be successfully identified and the integrity verification passes, the transaction request data is marked as dynamically encoded protocol data, and the marked dynamically encoded protocol data, the transaction request data, and the security credentials are sent together to the target service address.

9. The POS terminal transaction verification method based on the Internet of Things according to claim 1, characterized in that, When the protocol version is successfully identified and the integrity verification fails, the transaction request data is marked as data to be repaired, and the marked data to be repaired, the transaction request data, and the security credentials are sent together to the target service address.

10. A POS terminal transaction verification system based on the Internet of Things, characterized in that, include: The data acquisition module is used to acquire transaction request data; The verification module is used to perform version identification and integrity verification on the transaction request data respectively; The first processing module is used to parse and encapsulate the transaction request data that has passed the integrity verification according to the identified protocol version when the protocol version is successfully identified and the integrity verification is passed, and generate a first processing result. The second processing module is used to calculate the hash message verification code of the transaction request data as a security credential when the protocol version cannot be successfully identified or the integrity verification fails, and to send the transaction request data and the security credential to a preset target service address according to the result of the version identification and the result of the integrity verification, and to receive the second processing result from the target service address. The output module is used to output a transaction result indication based on the first processing result or the second processing result.

Images