Contactless payment methods, systems, devices, and media based on near-field communication

Abstract

This invention discloses a contactless payment method, system, device, and medium based on near-field communication (NFC). It is applied to merchant terminals, user payment devices, third-party acquiring institutions, clearing institutions, and account service institutions. The merchant terminal generates transaction data containing transaction parameters, payment application identification information, and standardized application wake-up commands, and writes it to an NDEF tag. When the user payment device approaches and reads the tag, it automatically launches the payment application, verifies the signature, and generates dynamic verification information containing a dynamic identifier and timestamp. The merchant terminal generates terminal legal authorization information through a built-in security chip and submits it along with the dynamic verification information to the third-party acquiring institution for verification. After the clearing institution verifies the signature routing, the account service institution verifies the validity of the dynamic verification information and the consistency of the transaction digest, and completes the deduction. This invention achieves contactless payment, improves operational convenience, adapts to multiple platforms and wallets, enhances compatibility, and ensures transaction security through dynamic encryption and hardware-level protection.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of electronic payment technology, and in particular to a contactless payment method, system, device and medium based on near-field communication. Background Technology

[0002] In the current field of electronic payment technology, mainstream payment methods include QR code payment, barcode payment, and traditional near-field communication (NFC) payment. These methods have revealed numerous shortcomings in practical applications. QR code payment requires users to actively scan a QR code and manually confirm the payment, which is not only cumbersome but also easily affected by factors such as ambient light, the integrity of the QR code, and network transmission latency, leading to low payment efficiency or even payment failure. Barcode payment requires users to actively unlock their mobile devices, open the corresponding payment application, and display the payment code, also resulting in redundant steps. Furthermore, network latency directly affects the transmission and response of payment instructions. While traditional NFC payment does not rely on network transmission, it requires users to manually select the payment method. Different manufacturers' mobile devices use different NFC protocols; for example, the protocol standards for Android and iOS operating systems are not unified. This leads to a high failure rate in device-to-device interactions, making convenient cross-platform payments difficult to achieve. Meanwhile, existing payment technologies also suffer from security issues. Most payment solutions use static encryption to protect payment data, which has low security strength and is easily cracked by attackers. Furthermore, payment terminals generally lack hardware-level security mechanisms, making it impossible to effectively verify the legitimacy of the terminal itself. Attackers can intercept and repeatedly send legitimate payment data to launch replay attacks, leading to illegal tampering or theft of payment data and seriously threatening users' financial security. In summary, existing payment technologies generally suffer from technical defects such as operational redundancy, insufficient compatibility, and security vulnerabilities, urgently requiring a new payment method to address these problems. Summary of the Invention

[0003] This invention provides a contactless payment method, system, device, and medium based on near-field communication, aiming to solve the problems of operational redundancy, insufficient compatibility, and security vulnerabilities that are common in existing payment technologies.

[0004] In a first aspect, embodiments of the present invention provide a contactless payment method based on near-field communication, applicable to merchant terminals, user payment devices, third-party acquiring institutions, clearing institutions, and account service institutions, the method comprising: The merchant terminal generates transaction data containing transaction parameters and payment application identification information, and writes the transaction data into a near-field communication data tag; wherein, the transaction parameters include transaction amount, terminal identifier, sequence identifier and signature information, and the transaction data embeds a standardized application wake-up command, which includes application wake-up address and payment application identification information; The user payment device approaches the merchant terminal and reads the near-field communication data tag. According to the standardized application wake-up command, the corresponding payment application is automatically launched, and the signature information is verified for legality. After the verification is passed, dynamic verification information is generated. The dynamic verification information includes a user transaction summary composed of user account information, terminal identifier, transaction amount, dynamic identifier and timestamp. The merchant terminal generates terminal legal authorization information for the current transaction using the private key of the built-in security chip, and submits the terminal legal authorization information and the dynamic verification information to the third-party acquiring institution. The third-party acquiring institution verifies the legitimacy of the merchant terminal. After the verification is successful, it submits the terminal's legal license information and the dynamic verification information to the clearing institution. The clearing institution verifies the legitimacy of the terminal's legitimate authorization information using a public key. After successful verification, it parses the dynamic verification information and routes the transaction request to the corresponding account service institution. The account service provider verifies the validity of the dynamic verification information and the consistency of the user transaction summary. Once the verification is successful, the deduction operation for the user's account is completed.

[0005] Secondly, the present invention also provides a contactless payment system based on near-field communication, including a unit for performing the above-described method.

[0006] Thirdly, embodiments of the present invention also provide a computer device, the computer device including a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the above-described method.

[0007] Fourthly, embodiments of the present invention also provide a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the above-described method.

[0008] This invention provides a contactless payment method, system, device, and medium based on near-field communication. This invention generates transaction data containing transaction parameters and payment application identification information on the merchant terminal and embeds standardized application wake-up commands. This transaction data is written into a near-field communication data tag. The user's payment device only needs to be near the merchant terminal to read the data tag, and the corresponding payment application will automatically launch according to the standardized application wake-up command. Users do not need to manually unlock the device, open the application, or select a payment method. Furthermore, the standardized application wake-up command is compatible with application launch protocols of different operating systems, breaking down protocol barriers between devices from different manufacturers and effectively resolving issues of operational redundancy and insufficient compatibility. Then, the private key of the security chip built into the merchant terminal generates terminal legal authorization information, combined with dynamic verification information containing the user's transaction summary generated by the user's payment device. A layered verification system is built relying on third-party acquiring institutions, clearing institutions, and account service institutions to achieve multiple verifications of the merchant terminal's legality and the user's transaction validity. The timestamps and dynamic identifiers in the dynamic verification information effectively resist replay attacks, and the hardware-level private key storage and signature mechanism eliminates the vulnerability of static encryption, fundamentally filling security vulnerabilities. This organically integrates the solutions to the three core problems of operational redundancy, insufficient compatibility, and security vulnerabilities, ultimately achieving a convenient seamless payment experience, efficient cross-platform compatibility, and end-to-end security protection. Attached Figure Description

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

[0010] Figure 1 This is a schematic diagram of a contactless payment method based on near-field communication according to an embodiment of the present invention; Figure 2 This is a schematic block diagram of a contactless payment system based on near-field communication according to an embodiment of the present invention; Figure 3 This is a schematic block diagram of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0011] 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, not all, of the embodiments of the present invention. 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.

[0012] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0013] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0014] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0015] As used in this specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if [described condition or event] is detected" may be interpreted, depending on the context, as "once determined," "in response to determination," "once [described condition or event] is detected," or "in response to detection of [described condition or event]."

[0016] In today's rapidly developing digital consumption landscape, electronic payment technology has become an indispensable pillar of socio-economic activities. Mainstream payment methods such as QR code payment, barcode payment, and traditional near-field communication (NFC) payment are widely used in various transaction scenarios. However, in actual promotion and use, these payment technologies have gradually revealed significant shortcomings. QR code and barcode payments require users to manually complete a series of operations, including unlocking the device, opening the application, scanning or displaying the payment code, and confirming the transaction. These steps are cumbersome and easily affected by factors such as ambient light, network latency, and the integrity of the QR code. Traditional NFC payment suffers from compatibility issues due to inconsistent protocol standards among different manufacturers, resulting in a high failure rate for cross-platform payment interactions. Meanwhile, most existing payment technologies use static encryption to protect transaction data, and payment terminals lack hardware-level security mechanisms. This not only fails to effectively verify the terminal's legitimacy but also makes it vulnerable to replay attacks, data tampering, and other malicious behaviors, creating significant security vulnerabilities. These problems severely restrict the further development of electronic payment technology and fail to meet users' urgent needs for a convenient, compatible, and secure payment experience.

[0017] To address this, this invention proposes a contactless payment method, system, device, and medium based on near-field communication (NFC). By constructing a NFC payment system that embeds standardized merchant terminal commands, enables contactless wake-up of user devices, implements layered verification throughout the entire process, and provides hardware-level security protection, it achieves a contactless payment experience with zero redundancy, cross-platform device compatibility, and end-to-end security protection, effectively solving the shortcomings of existing payment methods. Details are as follows: Please see Figure 1 , Figure 1 This is a flowchart illustrating the steps of a contactless payment method based on near-field communication (NFC) provided in an embodiment of the present invention. The method is applied to merchant terminals, user payment devices, third-party acquiring institutions, clearing institutions, and account service institutions. Specifically, a merchant terminal refers to a transaction processing device deployed in a merchant's business environment, supporting NFC functionality and equipped with a built-in security chip. It is used to generate transaction data, write NFC data tags, and submit transaction information. In practical scenarios, examples include a merchant's NFC-enabled cash register, smart POS machine, or self-service payment terminal. A user payment device refers to a mobile terminal device held by the user, supporting NFC functionality and pre-stored with a payment application private key. It is used to read NFC data tags, launch the payment application, and generate dynamic verification information. In practical scenarios, examples include a user's mobile phone, smartwatch, or smart bracelet. A third-party acquiring institution refers to a third-party acquiring institution that possesses acquiring qualifications and connects to the payment system. The merchant terminal and the clearing institution are financial service institutions used to verify the legitimacy of the merchant terminal and forward transaction information. In practice, these include acquiring departments of banks and acquiring institutions such as UnionPay Merchant Services. The clearing institution refers to the core institution responsible for clearing transaction funds and verifying information between the receiving institution and the account service institution. It is used to verify the legal authorization information of the terminal and route transaction requests. In practice, this includes institutions such as UnionPay and NetsUnion Clearing Corporation. The account service institution refers to the financial institution that provides account management and fund settlement services to users. It is used to verify the validity of dynamic verification information and complete the deduction operation. In practice, this includes various banks or third-party payment institutions. The method includes steps S110-S160.

[0018] S110. The merchant terminal generates transaction data containing transaction parameters and payment application identification information, and writes the transaction data into a near-field communication data tag; wherein, the transaction parameters include transaction amount, terminal identifier, sequence identifier and signature information, and the transaction data embeds a standardized application wake-up command, which includes application wake-up address and payment application identification information; In this embodiment, transaction parameters refer to a set of data representing the core information of the current transaction, including transaction amount, terminal identifier, sequence identifier, and signature information; transaction amount is the specific amount of funds in this transaction; terminal identifier is the unique identity identifier of the merchant terminal, used to distinguish different merchant devices; sequence identifier is the unique serial number of each transaction, used to avoid transaction duplication; signature information is anti-counterfeiting information generated by the merchant terminal based on its own information; payment application identifier information is information used to uniquely identify the target payment application, used to accurately locate the payment application to be launched, such as package name or UniversalLink; transaction data is a complete set of transaction information formed by integrating transaction parameters and payment application identifier information; near-field communication data tag (NFC Data Exchange Format (NDEF) tag) is a data storage carrier that supports near-field communication technology and can be read by the user's payment device at close range; standardized application wake-up command is a unified application launch command adapted to different operating systems, including application wake-up address (URL) and payment application identifier information, the application wake-up address is the launch path information of the payment application.

[0019] Specifically, the merchant terminal first collects the transaction amount and terminal identifier sequence of the current transaction. Based on this information, it generates signature information to form transaction parameters. Then, it integrates the transaction parameters with the payment application identifier information to generate transaction data. Simultaneously, it generates a standardized application wake-up command and embeds it into the transaction data. Finally, the merchant terminal writes the integrated transaction data into a near-field communication data tag through its own near-field communication module, completing the pre-setting of the transaction data. Specifically, this step, by generating a standardized application wake-up command and embedding it into the transaction data, solves the problem of incompatibility between different manufacturers' device protocols in existing technologies. At the same time, by integrating core transaction information and pre-setting it into the near-field communication data tag, it avoids the need for users to manually scan codes or display payment codes, specifically addressing the issue of operational redundancy. Through the above operations, the merchant terminal can quickly complete the integration and pre-setting of transaction data, laying the foundation for subsequent seamless payment and achieving initial compatibility across device protocols.

[0020] S120. The user payment device approaches the merchant terminal and reads the near-field communication data tag. According to the standardized application wake-up command, the corresponding payment application is automatically launched. The signature information is verified for legality. After the verification is passed, dynamic verification information is generated and sent to the merchant terminal. The dynamic verification information includes user account information, terminal identifier, transaction amount, dynamic identifier and timestamp, which form a user transaction summary. In this embodiment, the dynamic verification information (dynamic token) is a set of information generated by the user's payment device to verify the legality of the user's transaction. It includes user account information, terminal identifier, transaction amount, dynamic identifier, and timestamp, forming a user transaction summary. The dynamic identifier is a randomly generated one-time identifier used to prevent replay attacks. The timestamp is the specific time information of the transaction. The user transaction summary is a summary data formed by integrating the core information of the user transaction and is used to verify the consistency of the transaction information. The core technical carrier corresponding to the dynamic identifier is ID, which is a dynamic verification credential that binds key transaction information.

[0021] Specifically, users simply need to bring their payment device close to the near-field communication (NFC) data tag on the merchant terminal. The payment device automatically reads the transaction data from the tag via its built-in NFC module, extracts a standardized application wake-up command from the transaction data, and automatically launches the corresponding payment application without manual user intervention. The payment application then extracts the signature information from the transaction data for validity verification. Upon successful verification, it extracts the user account information, terminal identifier, and transaction amount, generates a dynamic identifier and timestamp, integrates them to form a user transaction summary, and then combines them to generate dynamic verification information. Finally, this dynamic verification information is sent to the merchant terminal. In essence, this step achieves automatic launch of the payment application through a standardized application wake-up command, eliminating the need for manual operations such as unlocking the device and opening the application, thus solving the problem of operational redundancy. Simultaneously, by generating dynamic verification information containing a dynamic identifier and timestamp, it replaces traditional static encrypted information, addressing the security vulnerability of static encryption. Through the above operations, seamless wake-up of the user's payment device and generation of dynamic verification information are achieved, improving the convenience of payment operations while strengthening the security of transaction information.

[0022] S130. The merchant terminal generates terminal legal authorization information for the current transaction using the private key of the built-in security chip, and submits the terminal legal authorization information and the dynamic verification information to the third-party acquiring institution. In this embodiment, the built-in security chip is a hardware security module integrated inside the merchant terminal. It has the functions of preventing physical cracking and hardware isolation. It is used to store the private key and perform encryption operations. Its core encryption technology can adopt the SM2 national cryptographic algorithm. The private key is the private key in the merchant terminal's asymmetric encryption key pair. It is used to generate terminal legal license information. The terminal legal license information is the verification information that represents the legality of the merchant terminal. Its essence is a license signature, which is used to prove that the merchant terminal is a legitimate transaction device.

[0023] Specifically, when generating terminal authorization information, the merchant terminal calls the private key stored in the built-in security chip to perform encryption calculations based on the core information of the current transaction, generating the terminal authorization information. The merchant terminal then integrates the generated terminal authorization information with the dynamic verification information sent by the user's payment device and submits it to the third-party acquiring institution through the communication module, completing the initial submission of transaction information. In detail, this step achieves hardware-level protection of the private key by storing it in the built-in security chip and performing encryption calculations, addressing the security vulnerability of existing payment terminals lacking hardware-level protection. Simultaneously, by generating terminal authorization information, it provides a basis for verifying the legitimacy of the merchant terminal, preventing unauthorized terminals from initiating transactions and mitigating the risk of terminal identity forgery. Through the above operations, the security of the merchant terminal's private key storage and use is ensured, effectively verifying the legitimacy of the merchant terminal and providing hardware-level protection for transaction security.

[0024] S140. The third-party acquiring institution verifies the legality of the merchant terminal. After the verification is passed, it submits the terminal's legal license information and the dynamic verification information to the clearing institution. In this embodiment, the third-party acquiring institution is a financial service institution with acquiring qualifications, which is used to connect merchant terminals and clearing institutions, and to perform merchant terminal legality verification and transaction information forwarding operations. Its core verification basis includes the license signature and token-related association information in the terminal's legal permission information.

[0025] Specifically, after receiving the terminal's legal license information and dynamic verification information submitted by the merchant terminal, the third-party acquiring institution first parses the terminal's legal license information, extracting the chip serial number, time window verification identifier, and digital signature. It then queries a pre-set whitelist of legitimate merchant terminals to verify whether the chip serial number has been registered and matches the merchant's qualifications. If a time window verification identifier exists, it verifies whether the timestamp difference is within a preset threshold. Simultaneously, it performs preliminary verification of the digital signature using the pre-stored merchant terminal public key. After all verification items pass, the terminal's legal license information and dynamic verification information are submitted to the clearing institution. In essence, this step verifies the merchant terminal's legitimacy from multiple dimensions, addressing the security vulnerability of lacking a terminal legitimacy verification mechanism in existing technologies. Furthermore, the acquiring institution's preliminary verification can intercept transactions initiated by unauthorized terminals in advance, preventing invalid transaction information from flowing to subsequent stages and improving transaction processing efficiency. Through the above operations, accurate verification of merchant terminal legitimacy is achieved, effectively intercepting illegal transactions, ensuring the front-end security of the transaction chain, and improving overall transaction processing efficiency.

[0026] S150. The clearing institution verifies the legality of the terminal's legal authorization information using a public key. After successful verification, it parses the dynamic verification information and routes the transaction request to the corresponding account service institution. In this embodiment, the clearing institution is the core institution responsible for transaction fund clearing and information verification. The public key is an asymmetric encryption key corresponding to the merchant terminal's private key, used to verify the terminal's legitimate authorization information. Its core verification object is the license signature. The transaction request is instruction information representing the user's payment needs, used to trigger the account service institution to perform deduction operations. The account service institution is a financial institution that provides users with account management and fund settlement services. The core carrier of dynamic verification information is the token.

[0027] Specifically, after receiving the terminal's legal license information and dynamic verification information submitted by the third-party acquiring institution, the clearing institution uses the pre-stored merchant terminal public key to verify the legality of the terminal's legal license information. If the verification is successful, the merchant terminal is considered legitimate. Subsequently, the clearing institution parses the dynamic verification information, extracts the user account information and core transaction information, and routes the transaction request to the corresponding account service institution based on the user account information, thus completing precise routing of the transaction request. Specifically, this step verifies the merchant terminal's legality by using the public key to verify the terminal's legal license information, strengthening transaction security. Simultaneously, precise routing of transaction requests solves the compatibility issues between different account service institutions, improves the efficiency of transaction request flow, and avoids incorrect request routing. Through these operations, a second security verification of transaction information is achieved, ensuring the precise flow of transaction requests and improving the security and efficiency of transaction clearing.

[0028] S160. The account service institution verifies the validity of the dynamic verification information and the consistency of the user transaction summary. After the verification is passed, the deduction operation of the user account is completed.

[0029] In this embodiment, the account service provider is a financial institution that provides account management and fund settlement services to users. It is used to verify the validity of transactions and perform deduction operations. The validity of dynamic verification information is whether the dynamic verification information is generated by a legitimate user and has not expired. Its core verification object is the Token. The consistency of user transaction summary is whether the user transaction summary matches the actual transaction information.

[0030] Specifically, after receiving a transaction request routed by the clearing institution, the account service provider first extracts the dynamic verification information and user transaction summary. For the validity verification of the dynamic verification information, the account service provider queries its stored user account registration information to compare whether the user account information in the dynamic verification information is a registered and legitimate account. Simultaneously, it extracts the timestamp from the dynamic verification information and determines whether the difference between the timestamp and the current system time is within a preset valid period, thus confirming that the dynamic verification information has not expired. For the consistency verification of the user transaction summary, the account service provider extracts the actual core transaction information submitted by the merchant terminal from the transaction request, including the transaction amount and terminal identifier. It then compares this information with the corresponding transaction amount and terminal identifier in the user transaction summary, and verifies whether the generation rules of the user transaction summary are consistent with preset rules to ensure that the summary has not been tampered with. After all verification items pass, the account service provider executes the deduction operation from the user account, completing the fund settlement for this transaction. Specifically, this step addresses the security vulnerabilities in existing technologies by clearly defining the verification logic for the validity of dynamic verification information and the consistency of user transaction summaries across multiple dimensions. This resolves the vulnerability of payment data to tampering or theft. Furthermore, the final verification by the account service institution effectively prevents user fund losses due to illegal transactions, thus ensuring user fund security. Through these operations, final verification of transaction information and fund settlement are achieved, ensuring the legality and accuracy of transactions and comprehensively protecting user fund security.

[0031] In one embodiment, step S110 is specifically executed as follows: the merchant terminal encapsulates the transaction amount, terminal identifier, payment application compatibility identifier, and sequence identifier into a near-field communication data record using a type-length-value encoding format; the merchant terminal writes the signature information into the signature payload area of ​​the near-field communication data record; the merchant terminal embeds a standardized application wake-up command into the near-field communication data record, wherein, when the user payment device is running a first type of operating system, an Android application startup record containing the payment application package name is written; when the user payment device is running a second type of operating system, a near-field communication unified resource identifier record that triggers the payment application routing is written; the merchant terminal writes the near-field communication data record integrating the signature information and the standardized application wake-up command into a near-field communication data tag; after the user payment device reads the near-field communication data tag, the operating system kernel layer parses the standardized application wake-up command in the near-field communication data record, automatically starts the specified payment application, and transmits the complete transaction data.

[0032] In this embodiment, the type length value encoding format refers to the standard format for encoding information according to the structure of data type, data length, and data content. It is TLV encoding. The near-field communication data record is a logical data unit that integrates transaction core information, signature information, and standardized application wake-up instructions. The signature payload area is a dedicated data area in the near-field communication data record used to store signature information. The standardized application wake-up instruction is a unified application startup instruction adapted to different operating systems, which includes the application wake-up address and payment application identification information. The near-field communication unified resource identifier record is a startup instruction used to trigger the routing of the payment application on the iOS operating system. The Android application startup record is a startup instruction used to directly start the payment application on the Android operating system, which is associated with the package name information of the payment application.

[0033] Specifically, the merchant terminal first collects the transaction amount, terminal identifier, payment application compatibility identifier, and sequence identifier of the transaction. This information is then standardized and encapsulated according to the TLV encoding format to form a near-field communication (NFC) data record. Subsequently, pre-generated signature information is written into the signature payload area of ​​this data record to ensure the integrity and anti-counterfeiting of the transaction information. Next, based on the operating system type compatible with the target payment application, the merchant terminal embeds the corresponding standardized application wake-up command into the NFC data record. If the user's payment device is running an Android operating system, an Android application startup record containing the payment application package name is written; if it is running an iOS operating system, a NFC Uniform Resource Identifier record that triggers the payment application routing is written. Finally, the merchant terminal, through its own NFC module, writes the NFC data record, which integrates the signature information and the standardized application wake-up command, into a NFC data tag. When the user's payment device approaches the tag, the built-in NFC module reads the NFC data record within the tag. The operating system kernel then parses the standardized application wake-up command, automatically launching the specified payment application and transmitting the complete transaction data into the application. Specifically, this step encapsulates core transaction information using TLV encoding format to ensure the standardization and readability of data storage. By embedding standardized application wake-up commands adapted to different operating systems into the near-field communication data record, it solves the compatibility issues caused by differences in NFC protocols between different manufacturers' devices in existing technologies. Furthermore, by integrating and encapsulating signature information with core transaction information, it avoids the cumbersome operation of users manually scanning codes or displaying payment codes, specifically mitigating operational redundancy. Through these operations, standardized encapsulation and cross-platform adaptation of transaction data are achieved, ensuring that users' payment devices can seamlessly wake up payment applications, laying the foundation for data transmission for a seamless payment experience, while simultaneously improving the security of transaction information transmission and cross-device compatibility.

[0034] In one embodiment, after the step of parsing the standardized application wake-up instruction by the operating system kernel layer, step S110 further performs the following steps: When the operating system kernel of the user payment device detects that multiple payment applications exist on the current device, it reads the payment application compatibility identifier from the near-field communication data record; the operating system kernel matches the payment application compatibility identifier with a preset payment application priority list, and filters out the target payment application corresponding to the compatibility identifier; the operating system kernel directly routes the transaction data and signature information to the target payment application and prevents other payment applications from obtaining the transaction data.

[0035] In this embodiment, the payment application compatibility identifier is a unique identifier embedded in the near-field communication data record for matching and adapting payment applications. The preset payment application priority list is a list of payment applications pre-stored in the user's payment device and sorted according to user habits or application adaptation rules. The target payment application is the payment application corresponding to this transaction that is determined after compatibility matching and priority filtering.

[0036] Specifically, after parsing the standardized application wake-up command in the near-field communication data record, the operating system kernel layer of the user's payment device first checks the number of payment applications installed on the device. If only one payment application exists, it is launched directly. If multiple payment applications are detected, the operating system kernel immediately reads the payment application compatibility identifier from the near-field communication data record. Then, the operating system kernel calls the pre-set payment application priority list in the device, compares and matches the payment application compatibility identifier with the adaptation identifier of each payment application in the list, and selects the unique target payment application that meets the compatibility requirements and has the highest priority. Finally, the operating system kernel directly routes the complete transaction data and signature information in the near-field communication data record to the target payment application, while building a data isolation barrier to prevent other payment applications from obtaining the transaction-related data, ensuring the targeted transmission of transaction information. In particular, this step, by reading the payment application compatibility identifier and matching the priority list, solves the problem of insufficient compatibility in existing payment technologies when multiple payment applications coexist, which cannot automatically adapt to the target application. It avoids the redundancy of users manually selecting payment applications. By targetedly routing transaction data and isolating other applications, it not only ensures the security of transaction information transmission but also specifically compensates for the defects of chaotic application adaptation in a multi-wallet ecosystem. Through the above operations, automatic adaptation and targeted activation in multiple payment application scenarios can be achieved, further improving the convenience and smoothness of contactless payment, strengthening the security and uniqueness of transaction information transmission, and improving the technical solution for cross-application compatibility.

[0037] In one embodiment, step S120 is performed as follows: When the merchant terminal is first activated, the built-in security chip generates an asymmetric encryption key pair and permanently stores the private key in the physical-resistant isolation zone of the security chip. When generating terminal legal authorization information, the merchant terminal retrieves the transaction amount, terminal identifier, sequence identifier, and current timestamp of the current transaction, transmits them to the built-in security chip, and generates a merchant transaction digest. The merchant terminal uses the private key through the built-in security chip to perform encryption operations on the merchant transaction digest, wherein the encryption operation is completed within the hardware isolation environment of the security chip. The merchant terminal determines the digital signature generated by the encryption operation as the terminal legal authorization information.

[0038] In this embodiment, the asymmetric encryption key pair is an encryption and decryption key combination composed of a private key and a public key, used to realize the encryption verification of data. The private key is the key held only by the merchant terminal and used for encryption operations, while the public key is the key publicly disclosed for signature verification. The physical cracking protection isolation area is a dedicated storage area in the built-in security chip with anti-physical attack functions, used to securely store the private key, such as an independent encrypted storage partition or tamper-proof storage unit in the security chip. The hardware isolation environment is the computing environment in the built-in security chip that is independent of other systems in the terminal, used to isolate the encryption operation process, such as a trusted execution environment or independent encryption operation core in the security chip.

[0039] Specifically, upon initial activation, the merchant terminal's built-in security chip automatically generates an asymmetric encryption key pair. The private key is then permanently stored in a physically-protected isolation zone within the security chip to prevent unauthorized reading or tampering. When the merchant terminal needs to generate legitimate authorization information, it first retrieves the transaction amount, terminal identifier, sequence identifier, and current timestamp of the current transaction. This information is transmitted to the built-in security chip, which integrates these elements to generate a merchant transaction digest. The merchant terminal then uses the stored private key via the built-in security chip to perform encryption operations on the transaction digest within a hardware-isolated environment. This encryption process is entirely isolated from other systems within the terminal. Finally, the merchant terminal uses the digital signature generated by the encryption operation to confirm the legitimate authorization information. In essence, this step generates and stores an asymmetric encryption key pair through the built-in security chip, utilizes a physically-protected isolation zone to ensure the security of the stored private key, and performs encryption operations in a hardware-isolated environment. This addresses the security vulnerabilities of existing payment technologies, such as the vulnerability of static encryption to cracking and the lack of hardware-level protection in payment terminals. Furthermore, by integrating core transaction information to generate and encrypt a merchant transaction digest, it provides a reliable basis for verifying the legitimacy of the merchant terminal and prevents unauthorized terminals from forging transaction information. Through the above operations, hardware-level security protection is achieved throughout the entire process of private key storage and encryption operations, ensuring the uniqueness and security of the terminal's legally authorized information, and providing a solid guarantee for the security of the front end of the transaction chain.

[0040] In one embodiment, when step S120 is specifically executed, before the merchant terminal determines the digital signature generated by the encryption operation as the terminal's legitimate license information, the following steps are also specifically executed: the merchant terminal extracts the current timestamp through the built-in security chip and calculates the difference between it and the timestamp in the merchant transaction summary; the merchant terminal verifies whether the timestamp difference is within a preset valid time window; when the timestamp difference exceeds the preset valid time window, the built-in security chip terminates the signature process and generates a transaction anomaly alarm; when the timestamp difference is within the preset valid time window, the built-in security chip continues to perform the signature operation and writes a time window verification identifier into the generated terminal legitimate license information.

[0041] In this embodiment, the preset valid time window refers to the time interval between the allowed transaction digest generation and the execution of encryption operations, which is used to limit the effective duration of the transaction process. The time window verification mark is a mark embedded in the terminal's legal permission information, which is used to indicate that the transaction has passed the time validity verification.

[0042] Specifically, before the merchant terminal generates a merchant transaction summary using the built-in security chip and prepares to call the private key for encryption, the built-in security chip first extracts the current system time to generate a current timestamp. Then, it extracts the timestamp recorded when the transaction occurred from the generated merchant transaction summary. The difference between the two timestamps is calculated to obtain the time difference. Subsequently, the merchant terminal verifies whether the time difference is within a preset valid time window. If the time difference exceeds the preset valid time window, the built-in security chip immediately terminates the subsequent signature process and generates a transaction anomaly alarm to indicate that the merchant terminal has a risk of transaction timeout. If the time difference is within the preset valid time window, the built-in security chip continues to execute the previously incomplete private key encryption and signing operation, and writes a time window verification identifier into the generated terminal legal permission information, completing the time validity verification step. In particular, this step, by extracting two timestamps and calculating the difference, combined with the preset valid time window for validity verification, solves the replay attack risk caused by the lack of transaction timeliness verification in existing payment technologies. By promptly terminating timeout transactions and generating alarms, it prevents illegal attackers from using intercepted expired transaction information to forge legitimate transactions, specifically addressing the security vulnerability that static encryption cannot resist replay attacks. Through the above operations, the timeliness of the transaction process can be controlled, the security of the terminal's legitimate authorization information can be further strengthened, replay attacks can be effectively resisted, and a timeliness protection barrier can be added to the security of the entire transaction chain.

[0043] In one embodiment, step S120 may further include the following steps: The user payment device extracts its own unique hardware identifier, including the device serial number and security zone identifier, and combines it with a randomly generated dynamic identifier and the current timestamp. This is then fused with the terminal identifier and transaction amount in the transaction parameters to generate a basic transaction factor. The user payment device encrypts the basic transaction factor using a symmetric encryption algorithm built into the payment application to generate a user transaction digest. The user payment device calls its built-in security module, which includes a device security element and a trusted execution environment. The payment application's private key is pre-stored in this security module. The user payment device uses the payment application's private key to sign the user transaction digest through the security module. The entire signing process is completed within the hardware isolation environment of the security module. The user payment device combines the signature result, the user transaction digest, and the de-identified user account information to generate complete dynamic verification information.

[0044] In this embodiment, the unique hardware identifier is the exclusive identity identifier of the user payment device, including the device serial number and the security zone identifier, used to distinguish different user devices. The dynamic identifier is a randomly generated one-time verification identifier. The basic transaction factor is the original data unit formed by integrating the device identity information, transaction core information, dynamic identifier, and timestamp. The symmetric encryption algorithm is an encryption technology that uses a single key for encryption and decryption. The device security element is a hardware security component integrated into the user payment device, such as an embedded security chip or smart card module. The trusted execution environment is a secure operating environment in the user payment device that is independent of the main operating system, such as the TEE (Trusted Execution Environment). It is an independent secure area embedded in the main processor of the user payment device (such as a mobile phone or smartwatch), physically isolated and logically independent from the device's main operating system (such as Android or iOS). Together, they constitute a built-in security module used to securely store private keys and perform encrypted signature operations. The desensitized user account information is data after privacy protection processing of the user's complete account information to avoid leakage of sensitive information. The payment application's private key is generated and distributed uniformly by the corresponding account service institution. When a user first installs and activates the payment application, it is written into the user's payment device's built-in security module through a secure transmission channel. The entire process is stored offline and is not exposed to the outside world.

[0045] Specifically, after verifying the legality of the signature information, the user payment device first extracts its own device serial number and security area identifier as a unique hardware identifier. Then, it randomly generates a dynamic identifier and obtains the current timestamp. Simultaneously, it extracts the terminal identifier and transaction amount from the transaction data. After concatenating all the above information in a preset order, it performs an irreversible fusion operation using the SHA256 hash algorithm to generate a fixed-length, uniquely corresponding basic transaction factor. This ensures that any change in input information will result in a completely different basic transaction factor. Subsequently, the basic transaction factor is encrypted using the symmetric encryption algorithm built into the payment application to form a user transaction digest. Next, the user payment device calls the built-in security module, which includes device security elements such as embedded security chips and trusted execution environments such as TEEs. The payment application's private key is pre-stored in this security module. The user payment device calls the private key through the security module to sign the user transaction digest in a hardware-isolated environment. Finally, the signature result, the user transaction digest, and the de-identified user account information are combined to generate complete dynamic verification information. Specifically, this step integrates multi-dimensional dynamic information and generates basic transaction factors through hash algorithm fusion, then encrypts them to form a user transaction digest. This addresses the security vulnerability of static encryption in existing technologies, which is easily cracked. A built-in security module, composed of a device security element and a trusted execution environment, stores the private key and performs the signing, achieving hardware-level protection of the private key and preventing its leakage. Simultaneously, by generating dynamic verification information containing a one-time dynamic identifier, replay attacks are effectively resisted. This dynamic verification information is submitted to the clearing institution and account service institution for verification. The corresponding public key is pre-distributed by the account service institution and stored in the clearing institution and its own system. The signature result is verified using the public key. By comparing the hash value obtained from the signature verification with the hash value of the recalculated user transaction digest, it is confirmed that the dynamic verification information was generated by a legitimate payment application and has not been tampered with. Through these operations, the secure generation and end-to-end verifiability of dynamic verification information are achieved, ensuring the uniqueness and integrity of transaction information, strengthening the security of user transactions, and protecting user account privacy.

[0046] In one embodiment, step S140 may further include the following steps: The third-party acquiring institution parses the terminal's legal licensing information, extracting the pre-embedded chip serial number, time window verification identifier, and digital signature. The third-party acquiring institution queries a pre-set whitelist of legitimate merchant terminals to verify whether the chip serial number has been registered with the clearing institution and is consistent with the merchant's qualification information. If the terminal's legal licensing information contains a time window verification identifier, the third-party acquiring institution verifies whether the difference between the current system time and the timestamp in the merchant's transaction summary is within a preset threshold. The third-party acquiring institution uses the pre-stored merchant terminal public key to perform a preliminary verification of the digital signature, confirming that the terminal's legal licensing information has not been tampered with. The third-party acquiring institution determines the merchant terminal is legitimate only when the chip serial number matches, a time window verification identifier is present, the time threshold verification passes, and the digital signature verification passes; otherwise, it terminates the transaction and sends an illegal terminal alarm to the clearing institution.

[0047] In this embodiment, the chip serial number is a unique identifier of the security chip built into the merchant terminal, used to verify the legality of the merchant terminal hardware. The time window verification identifier is a mark indicating that the merchant transaction has passed the time validity verification. The digital signature is anti-counterfeiting information generated by the merchant terminal based on the encryption of the merchant transaction digest using the private key. The preset legitimate merchant terminal whitelist is a list of legitimate merchant terminal information that has completed registration and filing stored by a third-party acquiring institution. The preset threshold is a pre-set maximum range of allowed timestamp differences. The public key is a public key paired with the merchant terminal's private key, used to perform signature verification operations on the digital signature.

[0048] Specifically, after receiving the terminal's legal license information and dynamic verification information submitted by the merchant terminal, the third-party acquiring institution first parses the terminal's legal license information, extracting the pre-embedded chip serial number time window verification identifier and digital signature. Then, it queries its own pre-set whitelist of legitimate merchant terminals to verify whether the extracted chip serial number has been registered with the clearing institution and whether the merchant qualification information corresponding to the chip serial number matches the whitelist record. If the terminal's legal license information contains a time window verification identifier, it extracts the timestamp from the merchant's transaction summary, calculates the difference between it and the current system time, and verifies whether this difference is within a preset threshold. Simultaneously, the third-party acquiring institution uses the pre-stored merchant terminal public key to perform a preliminary verification operation on the digital signature to confirm that the terminal's legal license information has not been tampered with. Only when all three conditions—chip serial number matching time threshold verification passing and digital signature verification passing—are met simultaneously, does the third-party acquiring institution determine that the merchant terminal is legitimate; otherwise, it immediately terminates the transaction process and reports an illegal terminal alarm to the clearing institution. Specifically, this step addresses the security issue of unauthorized terminals forging transactions by verifying the consistency between the chip serial number and the whitelist. It further defends against replay attacks by verifying the timestamp difference corresponding to the identifier via a time window check, and ensures that the terminal's legitimate authorization information has not been tampered with through public key verification. This effectively mitigates the security vulnerability of existing technologies that lack terminal legitimacy verification mechanisms. Through these operations, multi-dimensional and accurate verification of merchant terminal legitimacy is achieved, proactively intercepting illegal transactions, ensuring the security of the front end of the transaction chain, reducing invalid transaction flows, and improving overall transaction processing efficiency.

[0049] Figure 2 This is a schematic block diagram of a contactless payment system 200 based on near-field communication provided in an embodiment of the present invention. Figure 2 As shown, corresponding to the above-described contactless payment method based on near-field communication, the present invention also provides a contactless payment system 200 based on near-field communication. This contactless payment system 200 includes a unit for executing the above-described contactless payment method based on near-field communication, and this unit can be configured in a computer device. Specifically, please refer to... Figure 2 The contactless payment system 200 based on near-field communication includes units for executing the contactless payment method based on near-field communication described above. These units correspond one-to-one with the steps of the contactless payment method based on near-field communication. These include: an embedding unit 201, a wake-up unit 202, a generation unit 203, a first verification unit 204, a second verification unit 205, and a third verification unit 206.

[0050] The embedding unit 201 is used by the merchant terminal to generate transaction data containing transaction parameters and payment application identification information, and to write the transaction data into a near-field communication data tag; wherein, the transaction parameters include transaction amount, terminal identifier, sequence identifier and signature information, and the transaction data embeds a standardized application wake-up instruction, which includes an application wake-up address and payment application identification information; The wake-up unit 202 is used to bring the user payment device close to the merchant terminal and read the near-field communication data tag, automatically start the corresponding payment application according to the standardized application wake-up command, verify the legality of the signature information, generate dynamic verification information after the verification is passed and send it to the merchant terminal. The dynamic verification information includes a user transaction summary composed of user account information, terminal identifier, transaction amount, dynamic identifier and timestamp. The generation unit 203 is used for the merchant terminal to generate terminal legal authorization information for the current transaction using the private key of the built-in security chip, and to submit the terminal legal authorization information and the dynamic verification information to the third-party acquiring institution. The first verification unit 204 is used by the third-party acquiring institution to verify the legality of the merchant terminal. After the verification is passed, the terminal's legal license information and the dynamic verification information are submitted to the clearing institution. The second verification unit 205 is used by the clearing institution to verify the legality of the terminal's legal authorization information using a public key. After the verification is successful, the dynamic verification information is parsed and the transaction request is routed to the corresponding account service institution. The third verification unit 206 is used by the account service institution to verify the validity of the dynamic verification information and the consistency of the user transaction summary. After the verification is passed, the deduction operation of the user account is completed.

[0051] It should be noted that the contactless payment system 200 based on near-field communication in this embodiment also includes units that correspond one-to-one with the contactless payment method based on near-field communication described above. For the sake of brevity, these will not be described in detail here.

[0052] The aforementioned contactless payment system 200 based on near-field communication can be implemented as a computer program, which can be used in various ways, such as... Figure 3 It runs on the computer device shown.

[0053] Please see Figure 3 , Figure 3 This is a schematic block diagram of a computer device provided in an embodiment of this application. The computer device 500 may be a terminal.

[0054] See Figure 3The computer device 500 includes a processor 502, a memory, and a network interface 505 connected via a system bus 501. The memory may include a non-volatile storage medium 503 and internal memory 504.

[0055] The non-volatile storage medium 503 may store an operating system 5031 and a computer program 5032. The computer program 5032 includes program instructions that, when executed, cause the processor 502 to perform a contactless payment method based on near-field communication.

[0056] The processor 502 provides computing and control capabilities to support the operation of the entire computer device 500.

[0057] The internal memory 504 provides an environment for the operation of the computer program 5032 in the non-volatile storage medium 503. When the computer program 5032 is executed by the processor 502, the processor 502 can execute a contactless payment method based on near-field communication.

[0058] This network interface 505 is used for network communication with other devices. Those skilled in the art will understand that... Figure 3 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device 500 to which the present application is applied. The specific computer device 500 may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0059] The processor 502 is used to run a computer program 5032 stored in a memory to implement the steps of the above method.

[0060] It should be understood that in the embodiments of this application, the processor 502 may be a central processing unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor.

[0061] It will be understood by those skilled in the art that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program includes program instructions and can be stored in a storage medium, which is a computer-readable storage medium. The program instructions are executed by at least one processor in the computer system to implement the process steps of the embodiments of the above methods.

[0062] Therefore, the present invention also provides a storage medium. This storage medium can be a computer-readable storage medium. The storage medium stores a computer program, wherein the computer program includes program instructions. When executed by a processor, the program instructions cause the processor to perform the steps of the above-described method.

[0063] The storage medium can be any computer-readable storage medium capable of storing program code, such as a USB flash drive, portable hard drive, read-only memory (ROM), magnetic disk, or optical disk.

[0064] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0065] In the several embodiments provided by this invention, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For example, the division of each unit is merely a logical functional division, and there may be other division methods in actual implementation. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0066] The steps in the method of this invention can be adjusted, merged, or reduced in order according to actual needs. The units in the device of this invention can be merged, divided, or reduced according to actual needs. Furthermore, the functional units in the various embodiments of this invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0067] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0068] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0069] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Since these modifications and variations fall within the scope of the claims and their equivalents, this invention also intends to include these modifications and variations.

[0070] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A contactless payment method based on near-field communication, characterized in that, Applied to merchant terminals, user payment devices, third-party acquiring institutions, clearing institutions, and account service institutions, the method includes: The merchant terminal generates transaction data containing transaction parameters and payment application identification information, and writes the transaction data into a near-field communication data tag; wherein, the transaction parameters include transaction amount, terminal identifier, sequence identifier and signature information, and the transaction data embeds a standardized application wake-up command, which includes application wake-up address and payment application identification information; The user payment device approaches the merchant terminal and reads the near-field communication data tag. Based on the standardized application wake-up command, it automatically launches the corresponding payment application, verifies the legality of the signature information, and generates dynamic verification information upon successful verification, sending it to the merchant terminal. The step of generating dynamic verification information upon successful verification includes: the user payment device extracting its own unique hardware identifier, including the device serial number and security zone identifier, combining it with a randomly generated dynamic identifier and the current timestamp, and performing a fusion calculation with the terminal identifier and transaction amount in the transaction parameters to generate a basic transaction factor; the user payment device then uses a symmetric encryption algorithm built into the payment application to verify the signature information. The basic transaction factors are encrypted to generate a user transaction digest. The user payment device calls its built-in security module, which includes a device security element and a trusted execution environment. The payment application private key is pre-stored in this security module. The user payment device signs the user transaction digest using the payment application private key through the security module. The signing process is completed entirely within the hardware isolation environment of the security module. The user payment device combines the signature result, the user transaction digest, and the de-identified user account information to generate complete dynamic verification information. The dynamic verification information includes a user transaction digest composed of user account information, terminal identifier, transaction amount, dynamic identifier, and timestamp. The merchant terminal generates terminal authorization information for the current transaction using the private key of the built-in security chip, and submits the terminal authorization information and the dynamic verification information to the third-party acquiring institution. The step of the merchant terminal generating terminal authorization information for the current transaction using the private key of the built-in security chip includes: upon initial activation, the built-in security chip generates an asymmetric encryption key pair and permanently stores the private key in a physical attack-resistant isolation zone of the security chip. This physical attack-resistant isolation zone is a dedicated storage area within the built-in security chip with physical attack protection capabilities, used for securely storing the private key. The physical attack-resistant isolation zone is an independent encrypted storage partition or tamper-proof storage unit within the security chip. When generating terminal authorization information, the merchant terminal retrieves the transaction amount, terminal identifier, sequence identifier, and current timestamp of the current transaction, transmits them to the built-in security chip, and generates a merchant transaction summary. The merchant terminal uses the private key obtained through the built-in security chip to process the merchant transaction. The transaction digest undergoes encryption operations, which are confined to the hardware isolation environment of the security chip. This hardware isolation environment is the computing environment within the built-in security chip, used to isolate the encryption operation. The hardware isolation environment can be a trusted execution environment or an independent encryption core within the security chip. Before the merchant terminal determines the digital signature generated by the encryption operation as the terminal's legitimate license information, the merchant terminal extracts the current timestamp through the built-in security chip and calculates the difference between it and the timestamp in the merchant transaction digest. The merchant terminal verifies whether the timestamp difference is within a preset valid time window. When the timestamp difference exceeds the preset valid time window, the built-in security chip terminates the signature process and generates a transaction anomaly alarm. When the timestamp difference is within the preset valid time window, the built-in security chip continues to perform the signature operation and writes a time window verification identifier into the generated terminal legitimate license information. The merchant terminal then determines the digital signature generated by the encryption operation as the terminal's legitimate license information. The third-party acquiring institution verifies the legitimacy of the merchant terminal. Upon successful verification, it submits the terminal's legal license information and the dynamic verification information to the clearing institution. The steps for the third-party acquiring institution to verify the legitimacy of the merchant terminal include: parsing the terminal's legal license information to extract the pre-embedded chip serial number, time window verification identifier, and digital signature; querying a pre-set whitelist of legitimate merchant terminals to verify whether the chip serial number has been registered with the clearing institution and is consistent with the merchant's qualification information; if the terminal's legal license information contains a time window verification identifier, the third-party acquiring institution verifies whether the difference between the current system time and the timestamp in the merchant's transaction summary is within a preset threshold; the third-party acquiring institution uses a pre-stored merchant terminal public key to perform preliminary verification of the digital signature to confirm that the terminal's legal license information has not been tampered with; the third-party acquiring institution determines the merchant terminal is legitimate only when the chip serial number matches, a time window verification identifier is present, the time threshold verification passes, and the digital signature verification passes; otherwise, it terminates the transaction and sends an illegal terminal alarm to the clearing institution. The clearing institution verifies the legitimacy of the terminal's legitimate authorization information using a public key. After successful verification, it parses the dynamic verification information and routes the transaction request to the corresponding account service institution. The account service provider verifies the validity of the dynamic verification information and the consistency of the user transaction summary. Once the verification is successful, the deduction operation for the user's account is completed.

2. The method according to claim 1, characterized in that, The step of writing the transaction data into the near-field communication data tag includes: The merchant terminal encapsulates the transaction amount, terminal identifier, payment application compatibility identifier, and sequence identifier into a near-field communication data record according to the type-length-value encoding format. The merchant terminal writes the signature information into the signature payload area of ​​the near-field communication data record; The merchant terminal embeds a standardized application wake-up command into the near-field communication data record. When the user payment device is running a first type of operating system, an Android application startup record containing the payment application package name is written. When the user payment device is running a second type of operating system, a near-field communication unified resource identifier record that triggers the payment application routing is written. The merchant terminal integrates the signature information and standardized application wake-up instructions into the near-field communication data record, and writes it into the near-field communication data tag. After the user payment device reads the near-field communication data tag, the operating system kernel layer parses the standardized application wake-up instructions in the near-field communication data record, automatically starts the specified payment application, and transmits the complete transaction data.

3. The method according to claim 2, characterized in that, After the step of parsing the standardized application wake-up instruction by the operating system kernel layer, the method further includes: When the operating system kernel of the user payment device detects that multiple payment applications exist on the current device, it reads the payment application compatibility identifier from the near-field communication data record. The operating system kernel matches a pre-set list of payment application priorities with the payment application compatibility identifier and selects the target payment application corresponding to the compatibility identifier. The operating system kernel directly routes the transaction data and signature information to the target payment application and prevents other payment applications from obtaining the transaction data.

4. A contactless payment system based on near-field communication, characterized in that, The system includes a unit for performing the method of any one of claims 1-3.

5. A computer device, characterized in that, The computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method as described in any one of claims 1-3.

6. A computer-readable storage medium, characterized in that, The storage medium stores a computer program that, when executed by a processor, can implement the method as described in any one of claims 1-3.

Images