Real-name authentication and payment code binding security payment method

Abstract

The application discloses a real-name authentication and payment code binding security payment method, and belongs to the field of financial technology and information security. The method comprises the following steps: S1, collecting user declared expected transaction information and payment context data during payment, generating and temporarily storing a dynamic intention contract; S2, synchronously performing regular biometric recognition and coercion feature detection based on a bank hosting template on the client side during payment verification; S3, forwarding the biometric feature data to a bank authorization server for security comparison and ruling after encryption by the payment server; and S4, performing a differentiated process according to the comparison result. The application solves the industry problem that personal and property safety cannot be considered in the payment code theft, transaction tampering and coercion payment scenarios by deeply binding the transaction intention, coercion response and bank offline strong authentication, and builds a multi-dimensional security payment system that is active, concealed and tamper-proof.

Description

Technical Field

[0001] This invention belongs to the field of financial technology and information security technology, and relates to a secure payment method that combines real-name authentication with payment code binding. Background Technology

[0002] With the widespread adoption of mobile payments and the deep integration of biometric technology, payment security faces increasingly complex and severe challenges. Existing mainstream payment security technologies mainly focus on strengthening identity authentication and dynamic payment credentials, but they still have systemic flaws when dealing with new risks, especially extreme coercive scenarios involving personal safety.

[0003] Firstly, regarding the binding of payment credentials and real-name authentication, existing payment systems are generally built on an architecture of "one-time real-name authentication, multiple uses." When a user first activates the payment function, they must complete strict real-name authentication (such as ID card information, bank card verification, and facial recognition), and the resulting payment code is then bound to that real-name account. While this model ensures the traceability of payment transactions, its security heavily relies on the validity period management and anti-interception capabilities of the payment code itself. The harm is even greater if a static or short-term valid payment code bound to a real-name account is leaked, because all transactions will be attributed to that real-name user.

[0004] Secondly, regarding payment credential security, as an improvement over static payment codes, existing technologies generally employ dynamically refreshed payment codes (such as QR codes that change every minute) to prevent screenshot theft. The core principle of this approach is to ensure the uniqueness and temporary validity of the payment credential through a time dimension. However, its inherent flaw lies in the complete disconnect between the payment credential and the specific "transaction intent." A valid dynamic payment code is merely an identity token associated with a user account, without carrying crucial semantic information such as "who the payee is" and "the maximum amount to be paid." This means that once an attacker obtains the payment code within its validity period through screenshots, photos, or man-in-the-middle attacks, they can initiate payment requests for any amount to any payee. The payment system can only verify the validity of the code and the account balance, but cannot determine whether the transaction aligns with the user's original intent.

[0005] Secondly, regarding the security of biometric payments, facial recognition and fingerprint scanning have become mainstream. By upgrading identity verification from "known" (password) to "all" (biometric features), convenience and anti-fraud capabilities have been significantly improved. However, its security model is essentially a binary judgment logic: the system compares data and outputs only two results: "passed" (the user) or "rejected" (not the user). This design faces a dilemma when dealing with the specific scenario of "coerced payment," where personal safety and property security are mutually exclusive. When a user is coerced by criminals to make a facial recognition payment, if the recognition is "rejected," it may immediately anger the perpetrator and endanger the user's personal safety; if the recognition is "passed," the system will complete the payment normally, resulting in the user's financial loss. Existing biometric payment solutions completely lack a channel to secretly transmit danger signals to the system and trigger protection mechanisms while the user outwardly "cooperates" to complete the verification.

[0006] Furthermore, at the security policy management level, all security features of existing payment applications, including transaction limits, device binding, night lock, and emergency contacts, are entirely controlled by the online client application. Users can enable or disable these features themselves in the application settings. This design is extremely vulnerable to physical coercion: a perpetrator could easily force a user to operate their phone in person, disabling all security measures and rendering these features ineffective. The lack of physically isolated design to resist coercion in the management of the security policy itself is one of its most fatal weaknesses.

[0007] Finally, at the level of risk control mechanisms, the existing system mainly relies on post-transaction data analysis and risk control model interception. This model is prone to delays and misjudgments. Risk control systems typically analyze data based on multi-dimensional rules only after a transaction has occurred, making it difficult to intervene precisely at the moment the transaction happens. Furthermore, overly strict risk control rules may interfere with the payment experience of normal users and generate false alarms.

[0008] In summary, the industry urgently needs an innovative secure payment solution that can break the existing binary security model, deeply integrate real-name accounts, transaction intent, biometrics, and proactive protection, and ensure that the core protection mechanism itself is not compromised through system architecture design. This invention is proposed against this backdrop. Summary of the Invention

[0009] In view of the problems existing in the prior art, the present invention provides a secure payment method that binds real-name authentication and payment code to solve the above-mentioned technical problems.

[0010] To achieve the above and other objectives, the technical solution adopted by the present invention is as follows: This invention provides a secure payment method that links real-name authentication with payment codes, applicable to systems including payment clients, payment servers, bank authorization servers, and bank offline authentication terminals. The method includes the following steps: S1: Intent Contract Generation and Temporary Storage Steps. When a payment is initiated by the payment client, the user's declared expected transaction information is collected. The expected transaction information includes at least the expected payee identifier and the expected transaction amount limit. The expected transaction information and the payment context data collected in real time are combined to form a dynamic intent contract. The dynamic intent contract is structured and cryptographically hashed to generate a unique identifier, and then uploaded to the payment server and temporarily stored in a memory database with an automatic cleanup mechanism. S2: Dual-channel parallel biometric identification steps. During payment verification, the payment client simultaneously executes the regular biometric verification channel and the coercion response feature detection channel; the coercion response feature detection is based on a coercion response biometric template that the user has pre-registered through the bank's offline authentication terminal, which is different from the regular biometrics. The template is stored in a secure storage area protected by the hardware security module of the bank's authorization server. S3: Bank-side security comparison and adjudication steps. The payment server encrypts the real-time collected biometric data and forwards it to the bank's authorization server; the bank's authorization server uses the stored coercion feature template in a secure and isolated environment to perform similarity comparison, generates a comparison result including a confidence score, and returns it to the payment server after digital signature; S4: Differentiation Process Execution and Verification Steps. After verifying the completeness and timeliness of the received comparison results, the payment server performs differentiation processing based on a preset dynamic decision threshold matrix: S41: Normal process branch. If the comparison result indicates normal and the confidence score is higher than the high threshold, a dynamic payment voucher containing random seeds and local environment microdata is generated based on the dynamic intent contract. When the receiving end requests payment, the payee identifier and amount in the actual transaction request are verified to be consistent with the expected transaction information in the dynamic intent contract. Fund transfer is only authorized when they are completely consistent. S42: Coercion Response Branch. If the comparison result indicates that coercion has been detected or the confidence score is below a low threshold, the coercion response handling process is triggered. The coercion response handling process includes: sending a fake instruction to the payment client to display the normal payment process interface, suspending the real fund transfer and generating a simulated transaction response, sending a multi-channel silent alarm to the user's preset emergency contact, and initiating real-time location tracking and environmental information collection of the payment client.

[0011] Preferably, step S1 specifically includes: S11: Perform semantic parsing and format standardization on the expected transaction information declared by the user, including encoding format conversion and validity verification of the expected payee identifier, and currency unit unification and numerical range verification of the upper limit of the expected transaction amount. S12: Synchronously collect device fingerprint information, geographic location coordinates, and timestamp sequence as payment context data through the device system interface, and perform outlier detection and integrity verification on the collected context data; S13: The standardized expected transaction information and the verified payment context data are structured and serialized in a predetermined order to generate a structured object of transaction intent; S14: Perform a cryptographic hash operation on the structured object of the transaction intent to generate an intent digest that serves as a unique identifier and a basis for integrity verification; S15: Package and encrypt the structured object of the transaction intent, intent summary, digital signature and validity period parameters to form a dynamic intent contract data packet and upload it to the payment server.

[0012] Preferably, the dual-channel parallel biometric identification in step S2 specifically includes: S21: Activate the biometric acquisition module to acquire continuous video streams and environmental audio data; S22: Initialize the regular authentication pipeline and the duress signature detection pipeline in parallel within the trusted execution environment of the payment client; S23: The conventional identity verification pipeline performs face detection and feature extraction on the video stream and compares it with the local registration template, and outputs an identity verification confidence score; S24: The stress feature detection pipeline performs micro-expression action unit detection and eye movement trajectory analysis on the same video stream, and extracts acoustic features from the environmental audio. S25: The coercion feature detection pipeline asynchronously obtains the coercion feature template data pre-registered by the user from the payment server, and performs similarity matching between the real-time extracted multimodal features and the template in a secure environment; S26: Perform weighted decision fusion on the multimodal matching results. When the comprehensive score exceeds the preset detection threshold, it is determined that a stress feature has been detected.

[0013] Preferably, step S3 specifically includes: S31: The payment server constructs a comparison request message containing a unique identifier, timestamp, user identifier, and encrypted biometric data; S32: Transmit the comparison request message to the bank's authorization server through a secure channel authenticated by both parties' certificates; S33: The bank's authorization server decrypts the feature data in a secure isolation environment protected by the hardware security module, and retrieves the corresponding coercion feature template based on the user identifier; S34: The stress feature comparison engine calculates the similarity between real-time feature data and template data in the embedding space; S35: Generate the comparison result level and confidence score based on the similarity calculation results and the preset decision threshold; S36: The bank's authorization server uses its private key to digitally sign the complete comparison result and returns it to the payment server through a secure channel.

[0014] Preferably, the consistency verification in step S41 specifically includes: S411: When the receiving end uploads a payment request, the payment server parses the dynamic payment voucher and restores the random seed and local environment micro data; S412: Using the random seed as the search key, query the corresponding dynamic intent contract in the intent contract temporary storage library; S413: Verify the validity and integrity of the dynamic intent contract; S414: Extract the expected payee identifier and expected transaction amount limit from the verified dynamic intent contract; S415: Perform a rigorous multi-dimensional comparison between the payee identifier and amount in the actual request and the extracted expected information, including precise or fuzzy matching of the identifier and comparison of the numerical value and fluctuation range of the amount.

[0015] Preferably, the stress response handling process in step S42 specifically includes: S421: Sends encrypted fake control instructions to the payment client, controlling the client to load a preset interface template and dynamically fill in transaction information, rendering and displaying a fake interface that is visually consistent with the real payment success interface. S422: Mark the current transaction status as coercive action in the transaction log and generate a simulated successful transaction response based on the payment channel type to prevent the actual transfer of funds; S423: Extract the emergency contact list from the user's security policy and send a silent alert containing the event type, precise geographic location, and timestamp via multiple channels, including SMS, push notifications, automated voice calls, and email; S424: Send a silent tracking instruction to the payment client, start the background location service, and continuously collect and encrypt location data through multi-source fusion positioning technology; S425: Hides the recovery operation entry in the disguised interface. When a preset invisible operation sequence is captured, a security status confirmation signal is sent to the server to deactivate the alarm mode.

[0016] Preferably, the registration and management of the stress response biometric templates must be completed through the following offline process: S5: Users visit a bank's physical branch and complete multi-factor authentication through the bank's offline authentication terminal. The authentication includes at least: identification of the authenticity of the document chip, comparison of on-site biometric features with an authoritative database, and verification of bank card ownership. S51: After successful verification, the user records a coercion response biometric sample under the guidance of the terminal. The sample is encrypted to generate a coercion response biometric template, which is stored in the hardware security module of the bank's authorization server. S52: The bank's authorization server generates a policy update instruction, which is then digitally signed and sent to the payment server to activate or update the coercion response detection function module of the corresponding user's payment client.

[0017] Preferably, the coercion response detection module in the payment client follows the following management principles: S6: The activation status and strategy configuration of the aforementioned functional modules are entirely remotely controlled by the payment server according to the instructions of the bank authorization server; S61: The aforementioned functional module has no visual configuration entry, menu item, or related text prompt in the user interface of the payment client; S62: The code and resources of the aforementioned functional module are deployed through a silent update mechanism, and their running status is not visible to the user. The complete detection process is only started in the background when biometric payment is triggered.

[0018] A secure payment system that links real-name authentication with payment codes includes: The payment client module group, deployed on the user's mobile device, includes: The intent declaration interface is used to collect and standardize the expected transaction information declared by users. Context-aware unit, used to collect device fingerprint, geolocation and sensor micro data; A dual-channel biometric unit is used to perform routine biometric verification and stress signature detection in parallel in a trusted execution environment; A camouflage rendering engine is used to load templates and render and display camouflage interfaces based on server instructions; A secure communication module is used for encrypted data exchange with the payment server; The payment server module group, deployed on the backend of the payment platform, includes: The Intent Contract Manager is used to receive, verify, store, and query dynamic intent contracts. The collaborative adjudication scheduler is used to securely interact with the bank's authorization server and process comparison requests and responses; A transaction consistency verifier is used to compare the actual transaction request with the expected information in the dynamic intent contract. The coercion response handler coordinates spoofing control, transaction processing, alarm distribution, and location tracking. The bank authorization server module group is deployed independently within the bank system and includes: a policy-hosted repository and a coercion signature template database protected by a hardware security module; Feature comparison engine: a biometric similarity comparison algorithm that runs in a secure and isolated environment; An audit log system is used to prevent tampering and record all policy management and comparison operations. The bank's offline authentication terminal module group is deployed in the bank's physical outlets and includes: a multi-factor authentication unit that integrates a document reader, a biometric data collection device and a bank card reader; The feature acquisition guidance interface is used to guide users in recording stress feature samples; The teller's terminal is used to initiate and review policy change processes.

[0019] The secure payment method for real-name authentication and payment code binding provided by this invention has at least the following beneficial effects: This invention provides a secure payment system based on dynamic intent binding and bank-custodied coercion response. Through the collaborative work of the payment client, payment server, bank authorization server, and bank offline authentication terminal, it achieves a deep integration of pre-declaration of transaction intent, coercion response detection, and bank-level secure custody. This innovative architecture effectively solves the multi-dimensional security risks in current mobile payment systems caused by disconnected transaction intent, rigid biometric mechanisms, and easily tampered security policies. On one hand, this approach, through the generation and consistency verification mechanism of dynamic intent contracts, achieves for the first time pre-binding and mandatory verification of user payment intent, fundamentally eliminating the risk of transaction information being tampered with after the payment code is intercepted. This significantly improves the integrity and controllability of the transaction process, thereby building a tamper-proof security barrier at the source of payment and ensuring the safety of users' funds. On the other hand, through a dual-channel parallel biometric and bank-custodied coercion response mechanism, the system can covertly detect coercion signals in the standard identity verification process and trigger multi-dimensional emergency responses while ensuring the personal safety of users. This proactive protection strategy of "obvious compliance but covert retaliation" has innovatively solved the dilemma of traditional biometric payment in coercive scenarios, achieving the dual goals of property preservation and personal protection.

[0020] Meanwhile, this invention constructs an ultimate security defense against coercion and tampering by placing the registration and management permissions for coercion response strategies entirely within the bank's offline physical branches and using hardware security modules for template hosting. This architecture design, characterized by separation of permissions and physical isolation, ensures the absolute reliability of the core security mechanism. Even if the payment account and device are completely controlled by an attacker, this protection function cannot be remotely disabled, greatly enhancing the system's survivability under extreme threats. Furthermore, the system's dynamic decision threshold matrix and silent alarm tracking mechanism enable intelligent and precise risk response, allowing for real-time intervention during incidents and avoiding the lag and misjudgment problems of traditional risk control. Attached Figure Description

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

[0022] Figure 1 This is a schematic diagram showing the connections between the steps of the method of the present invention. Detailed Implementation

[0023] The following description, in conjunction with the implementation of the present invention, is merely an example and illustration of the concept of the present invention. Those skilled in the art can make various modifications or additions to the specific embodiments described, or use similar methods to replace them, as long as they do not deviate from the concept of the invention or exceed the scope defined in the claims, all of which should fall within the protection scope of the present invention.

[0024] Example 1: A secure payment method that combines real-name authentication with payment code binding, comprising the following steps: Step S1: Intent Contract Generation and Temporary Storage. When the payment client initiates a payment, the expected transaction information declared by the user is collected. The expected transaction information includes at least the expected recipient identifier and the expected transaction amount limit. The expected transaction information and the payment context data collected in real time are used to form a dynamic intent contract. The dynamic intent contract is structured and cryptographically hashed to generate a unique identifier, and then uploaded to the payment server and temporarily stored in a memory database with an automatic cleanup mechanism.

[0025] For example, step S1 includes: Step S11: Perform semantic parsing and format standardization on the user-declared expected transaction information, including encoding format conversion and validity verification of the expected payee identifier, and currency unit standardization and numerical range verification of the upper limit of the expected transaction amount.

[0026] Specifically: The payment client receives the expected payee identifier string and expected transaction amount input by the user through a human-computer interaction interface. The system performs standardized encoding conversion on the payee identifier. If the input is a mobile phone number, it is uniformly converted to an international format starting with "+86-"; if it is a bank card number, it is initially verified using the Luhn algorithm and supplemented with a bank identification code; if it is a third-party payment account, its account system identifier is parsed. Simultaneously, the system standardizes the unit of the amount, converting all amounts into integer values ​​in cents, and performs a reasonableness check on the upper limit of the input amount based on the user's available balance and the single transaction limit of the payment channel. If it exceeds the range, the user is prompted to adjust.

[0027] Step S12: Synchronously collect device fingerprint information, geographic location coordinates, and timestamp sequence as payment context data through the device system interface, and perform outlier detection and integrity verification on the collected context data.

[0028] Specifically: The payment client calls the system's security API to collect the device fingerprint. This fingerprint is generated by fusing multiple hardware and software features, including the device model, operating system version, security patch level, and hash digests of the installed application list, ensuring uniqueness and tamper resistance. Simultaneously, it obtains precise geographic coordinates through a fusion algorithm of GPS, Wi-Fi, and base station triangulation, achieving a positioning accuracy better than 10 meters. The system uses a secure clock to obtain a tamper-proof current timestamp. After collection, the system performs anomaly detection on various data points: comparing the device fingerprint with historical records to identify device cloning risks; comparing the geographic location with frequently visited locations to identify abnormal displacement; and verifying the timestamp with network time synchronization to identify time tampering.

[0029] Step S13: The standardized expected transaction information and the verified payment context data are structured and serialized in a predetermined order to generate a structured object of transaction intent.

[0030] Specifically: The system defines a standard transaction intent data structure (ProtocolBuffers format), with fields in a fixed order: version number, user ID, expected recipient identifier type, expected recipient identifier value, maximum amount value, currency type, device fingerprint hash, latitude coordinates, longitude coordinates, location accuracy, and timestamp. The data processed in steps S11 and S12 is filled into this structure to generate a complete structured object. The serialization process uses defined encoding rules to ensure that identical input data will always generate the same binary sequence.

[0031] Step S14: Perform a cryptographic hash operation on the structured object of the transaction intent to generate an intent digest that serves as a unique identifier and a basis for integrity verification.

[0032] Specifically: The system uses the SM3 national cryptographic hash algorithm to perform one-way hash calculation on the serialized byte stream generated in step S13, generating a fixed-length hash value of 256 bits, which is the intent digest. This digest has two core functions: 1) as a unique identifier for the payment intent, used for subsequent retrieval; 2) as a basis for data integrity verification, any tampering with the original intent data will result in a change in the hash value.

[0033] Step S15: Package and encrypt the transaction intent structured object, intent digest, digital signature and validity period parameter to form a dynamic intent contract data packet and upload it to the payment server.

[0034] Specifically: The payment client uses the user's locally stored private key to digitally sign the "intent digest + timestamp". Then, the original structured object, intent digest, digital signature, and an expiration parameter calculated based on the current time (e.g., "creation time + 300 seconds") are packaged into a data packet. This data packet is encrypted using the payment server's public key and uploaded via an HTTPS / TLS 1.3 secure channel. Upon receiving the packet, the payment server decrypts it using its private key, verifies the digital signature and expiration date, and then stores the complete dynamic intent contract (containing all metadata) in a high-performance in-memory database, with the intent digest as the key and the contract data as the value. The TTL (Time To Live) is set to match the expiration date for automatic cleanup.

[0035] Step S2: Dual-channel parallel biometric identification step. During payment verification, the payment client simultaneously executes the regular biometric verification channel and the coercion response feature detection channel; the coercion response feature detection is based on a coercion response biometric template that the user has pre-registered through the bank's offline authentication terminal, which is different from the regular biometrics. The template is stored in a secure storage area protected by the hardware security module of the bank's authorization server.

[0036] For example, step S2 includes: Step S21: Activate the biometric acquisition module to acquire continuous video streams and environmental audio data.

[0037] Specifically: After the user confirms the payment, the payment client uses the front-facing camera to capture a high-definition video stream at 30 frames per second, with a resolution of no less than 1080p. Simultaneously, it activates the microphone to capture ambient audio at a 16kHz sampling rate. The system automatically detects the ambient light intensity; if it falls below a threshold, it activates the screen fill light function.

[0038] Step S22: Initialize the regular authentication pipeline and the coercion signature detection pipeline in parallel within the trusted execution environment of the payment client.

[0039] Specifically, in trusted execution environments such as ARM TrustZone, the system loads two independent processing pipelines simultaneously. The regular authentication pipeline loads a face recognition algorithm model (such as FaceNet). The coercion feature detection pipeline loads a micro-expression recognition model (based on the FACS facial motion coding system) and an eye movement analysis model. The two pipelines share hardware access permissions for the camera and microphone, but have independent memory spaces and processing threads.

[0040] Step S23: The conventional authentication pipeline performs face detection and feature extraction on the video stream and compares it with the local registration template, outputting an authentication confidence score.

[0041] Specifically: The conventional pipeline performs face detection and 5-point keypoint alignment on each frame of video, then crops out standardized face regions. A deep learning model extracts a 512-dimensional feature embedding vector. This vector is then compared with a user-pre-encrypted registration template vector stored locally to calculate cosine similarity. The system processes multiple frames consecutively, taking the average similarity score as the final authentication confidence score. If the score is higher than 0.90 (configurable), the user is identified as the account holder.

[0042] Step S24: The coercion feature detection pipeline performs micro-expression action unit detection, eye movement trajectory analysis, and acoustic feature extraction on the same video stream.

[0043] Specifically: The coercive pipeline processes the same video stream in parallel, but their algorithms focus on different aspects. The micro-expression detection module analyzes brief, involuntary movements of specific facial muscle groups (such as the eyebrows, orbicularis oculi, and orbicularis oris), identifying the occurrence and combination of action units such as AU4 (brow drooping) and AU12 (corner of the mouth elongating). The eye analysis module tracks pupil position and identifies preset unnatural eye movement patterns, such as rapid "left-up-right-down" square trajectories. The audio analysis module extracts Mel-frequency cepstral coefficients (MFCCs) and detects the presence of preset rhythmic tapping or specific keyword audio patterns in the background.

[0044] Step S25: The coercion feature detection pipeline asynchronously obtains the coercion feature template data pre-registered by the user from the payment server, and performs similarity matching between the real-time extracted multimodal features and the template in a secure environment.

[0045] Specifically: During initialization, the payment client silently updates the payment server with the encrypted template of the user's coercion features (this template originally originated from the banking system). At this point, the coercion pipeline decrypts the template within the TEE. The template contains a set of predefined feature vectors or rules, such as: "blink frequency > 0.5Hz and lasts for 3 seconds," "AU12 intensity > 0.7 and AU4 intensity > 0.5 occurring simultaneously," and "specific MFCC sequence matching degree > 80%." The pipeline calculates the similarity between the features extracted in real-time in step S24 and these template rules one by one, outputting a matching score for each rule.

[0046] Step S26: Perform weighted decision fusion on the multimodal matching results. When the comprehensive score exceeds the preset detection threshold, it is determined that a stress feature has been detected.

[0047] Specifically, the system assigns weights (e.g., 0.5, 0.3, 0.2) to the three modalities of micro-expression, eye movements, and audio. The rule matching scores obtained in step S25 are normalized and weighted averaged according to modality to obtain the score for each modality. These scores are then weighted and fused to obtain a comprehensive score between 0 and 1. A relatively high detection threshold (e.g., 0.75) is set. If the comprehensive score exceeds this threshold, it is determined that "stress features have been detected," and a high-confidence stress label is generated; otherwise, it is labeled "not detected." This label will be uploaded along with the biometric data.

[0048] Step S3: Secure comparison and adjudication at the bank's end. The payment server encrypts the biometric data collected in real time and forwards it to the bank's authorization server. The bank's authorization server performs a similarity comparison using a stored coercion feature template in a secure, isolated environment, generates a comparison result including a confidence score, and returns it to the payment server after digital signature.

[0049] For example, step S3 includes: Step S31: The payment server constructs a comparison request message containing a unique request identifier, timestamp, user identifier, and encrypted biometric data.

[0050] Specifically: After receiving the biometric data packet uploaded by the client, the payment server generates a globally unique request ID (UUID). The request ID, the current server timestamp, the user ID, and the encrypted biometric data received from the client (including regular feature vectors and intermediate results of coercion detection) are packaged into a comparison request message. This message is then encrypted using the public key pre-exchanged by the bank's authorization server.

[0051] Step S32: Transmit the comparison request message to the bank's authorization server through a secure channel authenticated by both parties' certificates.

[0052] Specifically: A dedicated VPN tunnel based on two-way TLS / SSL certificate authentication is established between the payment server and the bank's authorization server. The payment server uses this tunnel to send encrypted request messages to the secure API endpoint specified by the bank's authorization server.

[0053] Step S33: The bank's authorization server decrypts the feature data in a secure isolation environment protected by the hardware security module, and retrieves the corresponding coercion feature template based on the user identifier.

[0054] Specifically: After receiving the request, the bank's authorization server first decrypts the request message within the HSM (Hardware Security Module). The decrypted data is strictly confined to the secure memory area of ​​the HSM. Based on the user identifier, the system retrieves the user's original coercion signature template (more precise and complete than the template held by the client) from an encrypted database also protected by the HSM.

[0055] Step S34: The stress feature comparison engine calculates the similarity between real-time feature data and template data in the embedding space.

[0056] Specifically, HSM's internal dedicated comparison engine performs high-precision matching between the micro-expression feature sequences and eye movement trajectories uploaded by the client and the original templates stored in the bank. The Dynamic Time Warping (DTW) algorithm is used to process the time-series data, and cosine similarity is used to process the feature vectors. Finally, an accurate similarity score (between 0 and 1) is calculated.

[0057] Step S35: Generate the comparison result level and confidence score based on the similarity calculation results and the preset decision threshold.

[0058] Specifically, the bank system presets three threshold levels: confirmed coercion (>0.8), suspected coercion (0.6-0.8), and normal (<0.6). Based on the range in which the calculated similarity score falls, a corresponding comparison result level code is generated (e.g., 1-coercion, 2-suspected, 0-normal). The confidence score is the similarity score itself.

[0059] Step S36: The bank authorization server uses its private key to digitally sign the complete comparison result and returns it to the payment server through a secure channel.

[0060] Specifically: The bank's authorization server uses its internal HSM private key to sign the response message, which includes the request ID, comparison result level, confidence score, and timestamp. The signature is then attached to the response message and returned to the payment server via an encrypted channel.

[0061] Step S4: Differentiation Process Execution and Verification. After verifying the completeness and timeliness of the received comparison results, the payment server performs differentiation processing based on a preset dynamic decision threshold matrix.

[0062] For example, step S4 is divided into two branches based on the comparison results: Step S41: Normal Process Branch. If the comparison result indicates normal and the confidence score is higher than the high threshold, a dynamic payment voucher containing a random seed and local environment microdata is generated based on the dynamic intent contract. When the receiving end requests payment, it verifies whether the payee identifier and amount in the actual transaction request are consistent with the expected transaction information in the dynamic intent contract. Fund transfer is only authorized when they are completely consistent.

[0063] Step S42: Stress Response Branch. If the comparison result indicates that stress has been detected or the confidence score is below a low threshold, the stress response handling procedure is triggered.

[0064] It should be added that the specific implementation of step S41 includes steps S411 to S415: Step S411: When the receiving end uploads a payment request, the payment server parses the dynamic payment voucher and restores the random seed and local environment micro data.

[0065] Specifically: The receiving end (merchant POS or barcode scanner) scans the dynamic payment QR code on the user's mobile phone, and uploads the encrypted string contained in the QR code, the payee ID of this transaction, and the requested amount to the payment server. The payment server first parses the encrypted string, and through reverse calculation (corresponding to the client's generation algorithm), it extracts the "random seed" issued by the server and the "sensor micro-data hash" mixed by the client.

[0066] Step S412: Use the random seed as the search key to query the corresponding dynamic intent contract in the intent contract temporary storage.

[0067] Specifically: The payment server uses the reconstructed "random seed" as the primary key to perform a query in the Redis cache. Since the seed and the intent contract are bound at the time of generation, the complete dynamic intent contract temporarily stored in step S1 can be retrieved quickly.

[0068] Step S413: Verify the validity and integrity of the dynamic intent contract.

[0069] Specifically: Check if the contract has expired (compare the current time with the contract's expiration date), and check if the contract's "used" status is "no". Simultaneously, recalculate the hash value of the transaction intent structured object in the contract and compare it with the "intent digest" stored in the contract to ensure the data has not been tampered with.

[0070] Step S414: Extract the expected payee identifier and the expected transaction amount limit from the verified dynamic intent contract.

[0071] Specifically: The standardized "expected payee identifier" and "expected transaction amount limit (unit: cents)" are extracted from the contract data.

[0072] Step S415: Perform a multi-dimensional and rigorous comparison between the payee identifier and amount in the actual request and the extracted expected information, including precise or fuzzy matching of the identifier and comparison of the numerical value and fluctuation range of the amount.

[0073] Specifically: The system compares the "Payee ID" uploaded by the merchant with the "Expected Payee Identifier" in the contract. For chain merchants, fuzzy matching is supported (e.g., if the expected identifier is "McDonald's," but the actual identifier is "McDonald's Wangfujing Store," it can be considered a match). The system compares the "Requested Amount" uploaded by the merchant with the "Amount Limit" in the contract, and the following condition must be met: Requested Amount ≤ Amount Limit. The system can be configured with a very small floating percentage (e.g., 0.1%) to handle rounding issues caused by payment channel fees. Consistency verification passes only when the payee matches and the amount does not exceed the limit. The payment server then sends a deduction instruction to the payment core.

[0074] It should be added that the specific implementation of step S42 includes steps S421 to S425: Step S421: Send an encrypted disguised control command to the payment client to control the client to load a preset interface template and dynamically fill in transaction information, rendering and displaying a disguised interface that is visually consistent with the real payment success interface.

[0075] Specifically: The payment server generates a special "DISGUISE_CMD" instruction, containing information such as the transaction amount and merchant name, and specifies an interface template ID (e.g., "success_v2"). This instruction is encrypted and pushed to the client. Upon receiving it, the client silently loads the corresponding template resource file in the background (this file is identical to the actual success interface resource but stored independently), fills in the transaction information, and immediately overwrites the current interface for display. The animation effects and waiting time are identical to the actual process.

[0076] Step S422: Mark the current transaction status as coercive disposal status in the transaction log table, and generate a simulated successful transaction response based on the payment channel type to prevent the actual transfer of funds.

[0077] Specifically: The payment server updates the transaction status to "COERCION_HOLD" in the database. For QR code payments, it returns "{"code":"SUCCESS","order_id":"..."}" to the merchant callback interface; for card transactions, it returns a "00" response code through the UnionPay network but sets a special flag in field 55. All these operations are intercepted at the payment gateway level to ensure that funds in the account are not deducted.

[0078] Step S423: Extract the emergency contact list from the user's security policy and send a silent alert containing the event type, precise geographic location, and timestamp via multiple channels including SMS, push notification, automated voice call, and email.

[0079] Specifically: The payment server reads 2-3 emergency contact details from the user's security configuration. A concise alert is sent via a high-priority SMS channel: "Urgent: Your family member [User Name] may be under duress for payment, location: [link]". A rich text notification with a map screenshot is sent via push service. Simultaneously, an automated voice outbound calling system dials the contacts and plays a voice alert. All alerts do not reveal any "disguised" information; the content is a genuine cry for help.

[0080] Step S424: Send a silent tracking instruction to the payment client to start the background location service and continuously collect and encrypt location data through multi-source fusion positioning technology.

[0081] Specifically: The server sends a "START_TRACE" command to the client. The client then initiates high-precision positioning in the background, combining GPS, Wi-Fi, base station, and Bluetooth beacon data, and encrypts and uploads location data packets every 15 seconds. The server then plots the movement trajectory in real time.

[0082] Step S425: Hide the recovery operation entry in the disguised interface. When the preset invisible operation sequence is captured, send a security status confirmation signal to the server to deactivate the alarm mode.

[0083] Specifically: Under the displayed fake "Payment Successful" screen, the system listens for an invisible interaction protocol. For example, the user rapidly taps five times consecutively in the center of the screen, or presses and holds the "Done" button for eight seconds. This action triggers the client to send an encrypted "SAFE_CONFIRM" signal to the server. Upon receiving this signal, the server stops alerts and tracking, and displays a hidden, real menu to the user, allowing them to choose subsequent actions.

[0084] Step S5: The user visits a physical bank branch and completes multi-factor authentication through the bank's offline authentication terminal.

[0085] Specifically: Users go to a bank branch that has signed an agreement with the partner payment platform and inform the teller that they need to apply for the "Secure Payment Guardian" service. The teller initiates a dedicated process in the bank's internal system. Users then complete the verification process by following these steps: Authenticity verification of ID card chip: Users place their second-generation ID card on a dedicated reader. The terminal reads the digital certificate and encrypted data within the ID card chip, verifies the validity of the chip's digital signature through a pre-set root certificate chain, checks the chip's physical anti-counterfeiting features (such as the membrane structure), and conducts online real-time verification with the ID card verification service platform designated by the Ministry of Public Security to confirm that the ID card is authentic, valid, and has not been reported lost.

[0086] On-site biometric verification against an authoritative database: Users, in front of the terminal's high-definition camera, follow the on-screen prompts to have their standard facial image captured. The captured image data is immediately transmitted, encrypted, via the bank's dedicated network to the "Citizen Identity Information Verification System" or "Networked Citizen Identity Information Verification System" connected to the public security department. The system performs a 1:1 facial comparison between the on-site photo and the standard photo stored in the ID card chip (or in the public security database), returning the comparison result and a similarity score. This verification is successful only if the similarity score exceeds a strict threshold set by the public security system (usually >0.90). Some high-risk scenarios may also require fingerprint verification.

[0087] Bank Card Ownership Verification: The user inserts or swipes any bank card (debit or credit card) registered in their name. The terminal reads the card number and prompts the user to enter the transaction PIN on the keypad. The system sends the card number and encrypted PIN to the bank's core system for verification, confirming that the card is in good standing, the PIN is correct, and the cardholder information matches the aforementioned ID card information. This step verifies the user's actual control over the bank account.

[0088] Step S51: After successful verification, the user records a stress response biometric sample under terminal guidance, and generates and stores a template.

[0089] Specifically: After all three strong verifications pass, the terminal interface switches to feature acquisition mode. The system guides the user through voice and animation to record one or more of the following coercive feature samples: Micro-expression sequence recording: The screen displays a prompt: "Please make a specific expression that you can remember naturally, such as blinking three times quickly." The user performs the action as instructed. The terminal records 3-5 seconds of facial video at a high frame rate (e.g., 120fps), capturing subtle muscle movements.

[0090] Eye movement mode recording: Prompt: "Please move your gaze in the direction indicated by the arrow (left-up-right-down)." The terminal records the movement trajectory of the eyeballs.

[0091] Voice command recording: Prompt: "Please speak a specific phrase in a natural tone, such as 'The weather is nice today.'" The user speaks as instructed. The terminal records the audio.

[0092] After recording, the terminal locally encrypts the original video / audio sample using a derived key from the bank's master key. The encrypted sample data is then securely transmitted to the bank's authorization server via the bank's intranet. Within the security boundary of the Hardware Security Module (HSM), the authorization server decrypts the sample and invokes pre-defined feature extraction algorithms (such as facial motion unit (AU) intensity extraction, eye optical flow feature extraction, and speech MFCC feature extraction) to generate a structured coercive response biometric template. This template is essentially a set of high-dimensional feature vectors or a mathematical description of behavioral patterns. After generation, the template is immediately re-encrypted by the HSM's internal master key and stored in a dedicated encrypted database protected by the HSM, strongly bound to the user's unique identifier (such as an ID card number hash). This original template data cannot be accessed by the payment platform or any other external system.

[0093] Step S52: The bank authorization server generates a policy update instruction and sends it to the payment server to activate the client function.

[0094] Specifically: After successful template storage, the bank's authorization server generates a structured security policy update instruction. This instruction includes at least: instruction type ("ACTIVATE" or "UPDATE"), target user identifier (payment account ID), associated bank-side template index ID, policy effective time, and operation serial number. The bank's authorization server digitally signs this instruction using its proprietary business private key. The signed instruction is then sent to the designated receiving interface of the payment platform via a pre-established financial-grade leased line or MPLS VPN between the bank and the payment platform.

[0095] Upon receiving the instruction, the payment server's collaborative adjudication scheduler first verifies the signature using the bank's pre-stored public key to ensure the instruction's authenticity and lack of tampering. After successful verification, the scheduler performs the following operations: In the payment platform's backend database, the user account's "coercion response function status" is marked as "activated".

[0096] The received policy index ID and other necessary information are associated with and stored with the user account.

[0097] An encrypted configuration update package is sent to the user's payment client via a silent push channel. This update package does not contain any biometric template data, but only a function switch command and necessary configuration parameters (such as the comparison service address and token).

[0098] The client receives and applies this update in the background, and the coercion response detection module in its TEE is activated, but the entire process is completely unnoticed by the user, and the application interface does not provide any prompts or require a restart.

[0099] The management principles for the coercion response detection function module in the payment client are implemented.

[0100] Step S6: The activation and configuration of the functional modules are remotely controlled by the payment server.

[0101] Specifically, the coercion response detection module in the payment client has its executable code and configuration file already present in the application installation package, but its initial state is "dormant" or "uninitialized." Its only activation method is to receive and verify an encrypted activation command from the payment server, as described in step S73. This command is sent through the application's own high-priority silent message channel (such as based on a long connection or vendor push service). After the client security module verifies the command signature, it changes the module's status flag from "DISABLED" to "ENABLED" in the TEE and loads the configuration parameters sent by the server. Users cannot find any switches, options, or descriptions related to this function in the phone's application settings, permission management, or any menu. The module's shutdown or policy update can only be accomplished by the server sending a new signed command.

[0102] Step S61: The functional module is completely hidden in the client user interface.

[0103] Specifically, to achieve ultimate concealment, the following measures were taken in the UI / UX design of the payment client: Settings menu: There is no entry, slider, text description or icon for this function in any of the potentially related settings pages such as "Security Center", "Payment Settings", "Biometrics", and "Privacy".

[0104] Application Permissions: In the system's application permission management list, this function does not request independent permissions. Its required camera and microphone permissions are shared with the regular face payment function to avoid attracting attention due to the addition of new permissions.

[0105] Help and Agreement: This coercion response feature is not mentioned in the user agreement, privacy policy, feature help documentation, or FAQ list. All copy and interface design ensure the feature is "hidden."

[0106] Runtime interface: When making facial recognition payments, the data collection interface is 100% consistent with the regular process, and no additional prompts such as "Detecting safe facial expressions" will appear.

[0107] Step S62: The functional module is deployed via silent update, triggered only in the background.

[0108] Specifically: Deployment: The core recognition model, rule engine, and other components of this module are part of the payment client's basic framework and are updated along with the main application version, or silently downloaded and replaced in the background via hot update technology. The update process does not generate pop-ups, does not notify, and does not require user confirmation.

[0109] Triggering the Module's Complete Execution: The module's full execution is subject to strict triggering conditions. The module will only initiate the complete detection process when both of the following conditions are met simultaneously: The payment process has entered the facial recognition verification stage.

[0110] The payment session token issued by the payment server contains an encrypted flag indicating that the user has enabled this function.

[0111] Resource Consumption and Stealth: In the non-triggered state, the module maintains only a low-power state listener with extremely low memory and CPU usage, making it undetectable by ordinary users or device management software. After being triggered, it runs in the TEE, and all intermediate processing data is not persisted to the disk and is immediately cleared after processing. No plaintext strings or identifiers related to "coercion detection" are left in the device system log and application log; it is only recorded as a regular biometric operation log.

[0112] By implementing steps S5 and S6, this invention ensures that the management authority (offline bank), control authority (remote server instructions), and execution authority (covert client module) of the ultimate security mechanism of coercion response are separated and highly reliable, fundamentally eliminating the possibility that this function can be turned off by attackers controlling user devices in coercion scenarios.

[0113] A secure payment system that links real-name authentication with payment codes includes: The payment client module group, deployed on the user's mobile device, includes: The intent declaration interface is used to collect and standardize the expected transaction information declared by users. Context-aware unit, used to collect device fingerprint, geolocation and sensor micro data; A dual-channel biometric unit is used to perform routine biometric verification and stress signature detection in parallel in a trusted execution environment; A camouflage rendering engine is used to load templates and render and display camouflage interfaces based on server instructions; A secure communication module is used for encrypted data exchange with the payment server; The payment server module group, deployed on the backend of the payment platform, includes: The Intent Contract Manager is used to receive, verify, store, and query dynamic intent contracts. The collaborative adjudication scheduler is used to securely interact with the bank's authorization server and process comparison requests and responses; A transaction consistency verifier is used to compare the actual transaction request with the expected information in the dynamic intent contract. The coercion response handler coordinates spoofing control, transaction processing, alarm distribution, and location tracking. The bank authorization server module group is deployed independently within the bank system and includes: a policy-hosted repository and a coercion signature template database protected by a hardware security module; Feature comparison engine: a biometric similarity comparison algorithm that runs in a secure and isolated environment; An audit log system is used to prevent tampering and record all policy management and comparison operations. The bank's offline authentication terminal module group is deployed in the bank's physical outlets and includes: a multi-factor authentication unit that integrates a document reader, a biometric data collection device and a bank card reader; The feature acquisition guidance interface is used to guide users in recording stress feature samples; The teller's terminal is used to initiate and review policy change processes.

[0114] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0115] It should be understood that determining B based on A does not mean determining B solely based on A; it also means determining B based on A and / or other information.

[0116] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0117] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A secure payment method that links real-name authentication with a payment code, characterized in that: The method, applicable to a system including a payment client, a payment server, a bank authorization server, and a bank offline authentication terminal, includes the following steps: S1: Intent Contract Generation and Temporary Storage Steps. When a payment is initiated by the payment client, the user's declared expected transaction information is collected. The expected transaction information includes at least the expected payee identifier and the expected transaction amount limit. The expected transaction information and the payment context data collected in real time are combined to form a dynamic intent contract. The dynamic intent contract is structured and cryptographically hashed to generate a unique identifier, and then uploaded to the payment server and temporarily stored in a memory database with an automatic cleanup mechanism. S2: Dual-channel parallel biometric identification steps. During payment verification, the payment client simultaneously executes the regular biometric verification channel and the coercion response feature detection channel; the coercion response feature detection is based on a coercion response biometric template that the user has pre-registered through the bank's offline authentication terminal, which is different from the regular biometrics. The template is stored in a secure storage area protected by the hardware security module of the bank's authorization server. S3: Bank-side security comparison and adjudication steps. The payment server encrypts the real-time collected biometric data and forwards it to the bank's authorization server; the bank's authorization server uses the stored coercion feature template in a secure and isolated environment to perform similarity comparison, generates a comparison result including a confidence score, and returns it to the payment server after digital signature; S4: Differentiation Process Execution and Verification Steps. After verifying the completeness and timeliness of the received comparison results, the payment server performs differentiation processing based on a preset dynamic decision threshold matrix: S41: Normal process branch. If the comparison result indicates normal and the confidence score is higher than the high threshold, a dynamic payment voucher containing random seeds and local environment microdata is generated based on the dynamic intent contract. When the receiving end requests payment, the payee identifier and amount in the actual transaction request are verified to be consistent with the expected transaction information in the dynamic intent contract. Fund transfer is only authorized when they are completely consistent. S42: Coercion Response Branch. If the comparison result indicates that coercion has been detected or the confidence score is below a low threshold, the coercion response handling process is triggered. The coercion response handling process includes: sending a fake instruction to the payment client to display the normal payment process interface, suspending the real fund transfer and generating a simulated transaction response, sending a multi-channel silent alarm to the user's preset emergency contact, and initiating real-time location tracking and environmental information collection of the payment client.

2. The method according to claim 1, characterized in that, Step S1 specifically includes: S11: Perform semantic parsing and format standardization on the expected transaction information declared by the user, including encoding format conversion and validity verification of the expected payee identifier, and currency unit unification and numerical range verification of the upper limit of the expected transaction amount. S12: Synchronously collect device fingerprint information, geographic location coordinates, and timestamp sequences as payment context data through the device system interface, and perform outlier detection and integrity verification on the collected context data; S13: The standardized expected transaction information and the verified payment context data are structured and serialized in a predetermined order to generate a structured object of transaction intent; S14: Perform a cryptographic hash operation on the structured object of the transaction intent to generate an intent digest that serves as a unique identifier and a basis for integrity verification; S15: Package and encrypt the structured object of the transaction intent, intent summary, digital signature and validity period parameters to form a dynamic intent contract data packet and upload it to the payment server.

3. The method according to claim 1, characterized in that, The dual-channel parallel biometric identification in step S2 specifically includes: S21: Activate the biometric acquisition module to acquire continuous video streams and environmental audio data; S22: Initialize the regular authentication pipeline and the duress signature detection pipeline in parallel within the trusted execution environment of the payment client; S23: The conventional identity verification pipeline performs face detection and feature extraction on the video stream and compares it with the local registration template, and outputs an identity verification confidence score; S24: The stress feature detection pipeline performs micro-expression action unit detection and eye movement trajectory analysis on the same video stream, and extracts acoustic features from the environmental audio. S25: The coercion feature detection pipeline asynchronously obtains the coercion feature template data pre-registered by the user from the payment server, and performs similarity matching between the real-time extracted multimodal features and the template in a secure environment; S26: Perform weighted decision fusion on the multimodal matching results. When the comprehensive score exceeds the preset detection threshold, it is determined that a stress feature has been detected.

4. The method according to claim 1, characterized in that, Step S3 specifically includes: S31: The payment server constructs a comparison request message containing a unique identifier, timestamp, user identifier, and encrypted biometric data; S32: Transmit the comparison request message to the bank's authorization server through a secure channel authenticated by both parties' certificates; S33: The bank's authorization server decrypts the feature data in a secure isolation environment protected by the hardware security module, and retrieves the corresponding coercion feature template based on the user identifier; S34: The stress feature comparison engine calculates the similarity between real-time feature data and template data in the embedding space; S35: Generate the comparison result level and confidence score based on the similarity calculation results and the preset decision threshold; S36: The bank's authorization server uses its private key to digitally sign the complete comparison result and returns it to the payment server through a secure channel.

5. The method according to claim 1, characterized in that, The consistency verification in step S41 specifically includes: S411: When the receiving end uploads a payment request, the payment server parses the dynamic payment voucher and restores the random seed and local environment micro data; S412: Using the random seed as the search key, query the corresponding dynamic intent contract in the intent contract temporary storage library; S413: Verify the validity and integrity of the dynamic intent contract; S414: Extract the expected payee identifier and expected transaction amount limit from the verified dynamic intent contract; S415: Perform a rigorous multi-dimensional comparison between the payee identifier and amount in the actual request and the extracted expected information, including precise or fuzzy matching of the identifier and comparison of the numerical value and fluctuation range of the amount.

6. The method according to claim 1, characterized in that, The stress response handling process in step S42 specifically includes: S421: Sends encrypted fake control instructions to the payment client, controlling the client to load a preset interface template and dynamically fill in transaction information, rendering and displaying a fake interface that is visually consistent with the real payment success interface. S422: Mark the current transaction status as coercive action in the transaction log and generate a simulated successful transaction response based on the payment channel type to prevent the actual transfer of funds; S423: Extract the emergency contact list from the user's security policy and send a silent alert containing the event type, precise geographic location, and timestamp via multiple channels, including SMS, push notifications, automated voice calls, and email; S424: Send a silent tracking instruction to the payment client, start the background location service, and continuously collect and encrypt location data through multi-source fusion positioning technology; S425: Hides the recovery operation entry in the disguised interface. When a preset invisible operation sequence is captured, a security status confirmation signal is sent to the server to deactivate the alarm mode.

7. The method according to claim 1, characterized in that, The registration and management of the stress response biometric templates must be completed through the following offline process: S5: Users visit a bank's physical branch and complete multi-factor authentication through the bank's offline authentication terminal. The authentication includes at least: identification of the authenticity of the document chip, comparison of on-site biometric features with an authoritative database, and verification of bank card ownership. S51: After successful verification, the user records a coercion response biometric sample under the guidance of the terminal. The sample is encrypted to generate a coercion response biometric template, which is stored in the hardware security module of the bank's authorization server. S52: The bank's authorization server generates a policy update instruction, which is then digitally signed and sent to the payment server to activate or update the coercion response detection function module of the corresponding user's payment client.

8. The method according to claim 7, characterized in that, The coercion response detection module in the payment client follows the following management principles: S6: The activation status and strategy configuration of the aforementioned functional modules are entirely remotely controlled by the payment server according to the instructions of the bank authorization server; S61: The aforementioned functional module has no visual configuration entry, menu item, or related text prompt in the user interface of the payment client; S62: The code and resources of the aforementioned functional module are deployed through a silent update mechanism, and their running status is not visible to the user. The complete detection process is only started in the background when biometric payment is triggered.

9. A secure payment system for implementing the method of any one of claims 1-8, characterized in that, include: The payment client module group, deployed on the user's mobile device, includes: The intent declaration interface is used to collect and standardize the expected transaction information declared by users. Context-aware unit, used to collect device fingerprint, geolocation and sensor micro data; A dual-channel biometric unit is used to perform routine biometric verification and stress signature detection in parallel in a trusted execution environment; A camouflage rendering engine is used to load templates and render and display camouflage interfaces based on server instructions; A secure communication module is used for encrypted data exchange with the payment server; The payment server module group, deployed on the backend of the payment platform, includes: The Intent Contract Manager is used to receive, verify, store, and query dynamic intent contracts. The collaborative adjudication scheduler is used to securely interact with the bank's authorization server and process comparison requests and responses; A transaction consistency verifier is used to compare the actual transaction request with the expected information in the dynamic intent contract. The coercion response handler coordinates spoofing control, transaction processing, alarm distribution, and location tracking. The bank authorization server module group is deployed independently within the bank system and includes: a policy-hosted repository and a coercion signature template database protected by a hardware security module; Feature comparison engine: a biometric similarity comparison algorithm that runs in a secure and isolated environment; An audit log system is used to prevent tampering and record all policy management and comparison operations. The bank's offline authentication terminal module group is deployed in the bank's physical outlets and includes: a multi-factor authentication unit that integrates a document reader, a biometric data collection device and a bank card reader; The feature acquisition guidance interface is used to guide users in recording stress feature samples; The teller's terminal is used to initiate and review policy change processes.

Images