Transaction processing method and system

Abstract

The application relates to the technical field of safety protection, and discloses a transaction processing method and system, which comprises the following steps: a co-signing client and a co-signing server cooperatively generate a certificate signature request file; a payment terminal transmits the certificate signature request file obtained from the co-signing client to a payment server to generate a co-signature certificate; the payment terminal obtains the co-signature certificate from the co-signing client, and triggers the co-signing client and the co-signing server to perform a national secret signature on obtained transaction information based on the co-signature certificate to generate a final signature; the payment server receives signature transaction information containing the final signature sent by the payment terminal, and performs signature verification on the final signature in the signature transaction information by using a stored certificate public key to determine whether to continue executing a transaction process. The application can be applied to the transaction processing scene of financial technology and medical health, and improves the security of transaction processing.

Description

Technical Field

[0001] This invention relates to the field of security protection technology, and in particular to a transaction processing method and system. Background Technology

[0002] Existing NFC (Near Field Communication) payment transactions (in fintech, such as large-amount transfers via NFC-based digital wallets; in healthcare, such as medical insurance settlement via NFC wristbands or smart pharmacy authentication for medication pickup) generally employ traditional digital signature methods to ensure payment security. The core of this method is that the payment terminal uses its local private key to generate a digital signature for confidential information such as the transaction message, amount, and timestamp, and the corresponding public key is used on the payment server to verify the signature, thus confirming the authenticity and integrity of the transaction. However, existing digital signature methods rely entirely on a single key pair for signing and verification, and are completed independently by a single signer (usually the client). This centralized signing model makes the security of the entire system highly dependent on the confidentiality of the private key. Once the private key is leaked or the client is maliciously manipulated, attackers can forge valid signatures, leading to undetected tampering of transaction information and severely impacting the integrity and security of the transaction data. Summary of the Invention

[0003] This invention provides a transaction processing method and system to solve the technical problem of low security in existing transaction processing methods.

[0004] Firstly, a transaction processing method is provided, including: The client and server collaborate to generate a certificate signing request file. The payment terminal will transmit the certificate signing request file obtained from the co-signing client to the payment server to generate a co-signing certificate; The payment terminal obtains the collaborative signature certificate from the collaborative signature client and triggers the collaborative signature client and the collaborative signature server to perform national cryptographic signature on the obtained transaction information based on the collaborative signature certificate to generate the final signature; The payment server receives the signed transaction information containing the final signature sent by the payment terminal, and uses the stored certificate public key to verify the final signature in the signed transaction information to determine whether to continue the transaction process.

[0005] Secondly, a transaction processing system is provided, comprising: a generation unit configured in the co-signing client and co-signing server, a transmission generation unit and an acquisition triggering unit configured in the payment terminal, and a verification unit configured in the payment server, wherein: The generation unit is used for the collaborative signing client and the collaborative signing server to generate a certificate signature request file. The transmission generation unit is used by the payment terminal to transmit the certificate signing request file obtained from the co-signing client to the payment server to generate a co-signing certificate; The acquisition triggering unit is used by the payment terminal to acquire the collaborative signature certificate from the collaborative signature client, and trigger the collaborative signature client and the collaborative signature server to perform national cryptographic signature on the acquired transaction information based on the collaborative signature certificate to generate the final signature; The verification unit is used by the payment server to receive the signed transaction information containing the final signature sent by the payment terminal, and to verify the final signature in the signed transaction information using the stored certificate public key to determine whether to continue the transaction process.

[0006] In the above-described transaction processing method, apparatus, computer equipment, and storage medium, a certificate signing request file is generated collaboratively by a co-signing client and a co-signing server. The payment terminal transmits the certificate signing request file obtained from the co-signing client to the payment server to generate a co-signing certificate. The payment terminal obtains the co-signing certificate from the co-signing client and triggers the co-signing client and the co-signing server to perform national cryptographic signature on the obtained transaction information based on the co-signing certificate, generating a final signature. The payment server receives the signed transaction information containing the final signature sent by the payment terminal and verifies the final signature in the signed transaction information using the stored certificate public key to determine whether to continue the transaction process. In this invention, the payment server generates a collaborative signature certificate based on the certificate signature request file jointly generated by the collaborative signature client and the collaborative signature server; the payment terminal triggers the collaborative signature client and the collaborative signature server to perform national cryptographic signature on the obtained transaction information based on the collaborative signature certificate to generate a final signature; the payment server verifies the final signature to determine whether to continue the transaction process. This not only effectively solves the security bottleneck caused by single-key signature in traditional transactions, but also eliminates the risk of forging transactions due to a single point of private key leakage, thus improving the security of transaction processing. Attached Figure Description

[0007] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments of the present invention 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.

[0008] Figure 1 This is a schematic diagram of an application environment for a transaction processing method according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating a transaction processing method according to an embodiment of the present invention; Figure 3 yes Figure 2 A schematic diagram of a specific implementation of step S110; Figure 4 yes Figure 2 A schematic diagram of a specific implementation of step S120; Figure 5 yes Figure 2 A schematic diagram of a specific implementation of step S130; Figure 6 yes Figure 2 A schematic diagram of a specific implementation of step S140; Figure 7 This is a schematic block diagram of a transaction processing system according to an embodiment of the present invention; Figure 8 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention; Figure 9 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

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

[0010] The transaction processing method provided in this embodiment of the invention can be applied to, for example, Figure 1In this application environment, the co-signing client communicates with the co-signing server to receive a certificate signing request file returned by the co-signing server; the payment terminal communicates with the co-signing client to obtain the certificate signing request file and the co-signing certificate from the co-signing client; and the payment server communicates with the payment terminal to receive transaction information containing the final signature sent by the payment terminal. In this invention, the payment server generates a co-signing certificate based on the certificate signing request file jointly generated by the co-signing client and the co-signing server; the payment terminal triggers the co-signing client and the co-signing server to perform national cryptographic signature on the obtained transaction information based on the co-signing certificate to generate the final signature; the payment server verifies the final signature to determine whether to continue the transaction process. This not only effectively solves the security bottleneck caused by single-key signature in traditional transactions but also eliminates the risk of forging transactions due to a single point of private key leakage, thus improving the security of transaction processing. It should be noted that the co-signing client is deployed on the device where the payment terminal is located, and the co-signing server is deployed on the device where the payment server is located. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a separate server or a server cluster consisting of multiple servers. The present invention will now be described in detail through specific embodiments.

[0011] Please see Figure 2 As shown, Figure 2 A flowchart of a transaction processing method provided in an embodiment of the present invention includes the following steps: S110-S140.

[0012] S110, the co-signing client and co-signing server work together to generate a certificate signing request file.

[0013] Specifically, the co-signing client is used to generate and store the first private key component. When signing a transaction, it uses the first private key component to perform a first-level national cryptographic signature on the transaction information. The co-signing server is used to generate and store the second private key component. When signing a transaction, it receives the first-level signature result from the co-signing client and uses the second private key component to perform a second-level national cryptographic signature to generate the final signature.

[0014] Among them, such as Figure 3 As shown, step S110 includes steps S111-S113: S111. The co-signing client generates a first private key component and generates a first part of the certificate signing request file based on the first private key component; S112. The co-signing server generates a second private key component and generates a second part of the certificate signing request file based on the second private key component; S113. The co-signing server generates the certificate signing request file based on the second part of the certificate signing request file and the first part of the certificate signing request file sent by the co-signing client.

[0015] Specifically, the co-signing client first independently generates a first private key component in its local secure environment using a national cryptographic asymmetric algorithm. Then, based on this first private key component and pre-defined user identifiers, algorithm parameters, and other information, the co-signing client constructs the first part of the certificate signing request file. Simultaneously, the co-signing server, within its own secure domain, also generates a second private key component using the same national cryptographic asymmetric algorithm, and generates the second part of the certificate signing request file based on this second private key component. After generating the first part of the certificate signing request file, the co-signing client securely sends it to the co-signing server. The co-signing server, acting as a synthesis node, upon receiving the first part of the request from the client, cryptographically associates and assembles it with its own generated second part of the certificate signing request file, ultimately forming a complete and unified certificate signing request file. Understandably, this synthesized file contains dual key information and identity statements from both the co-signing client and the co-signing server.

[0016] S120. The payment terminal transmits the certificate signing request file obtained from the co-signing client to the payment server to generate a co-signing certificate.

[0017] Specifically, after the co-signing server generates the certificate signing request file, it returns the generated certificate signing request file to the co-signing client.

[0018] Among them, such as Figure 4 As shown, step S120 includes steps S121-S122: S121. The payment terminal obtains the certificate signature request file from the co-signing client; S122. The payment terminal transmits the certificate signing request file to the payment server, so that the payment server, after verifying the validity of the certificate signing request file, generates the collaborative signature certificate based on the certificate signing request file.

[0019] Specifically, the payment terminal first securely interacts with the co-signing client. During this interaction, the payment terminal sends the user token and identity identifier obtained during registration with the co-signing server, along with user authorization, to the co-signing client, thereby initiating an instruction to obtain a Certificate Signing Request (CSR). After verifying the request's legitimacy, the co-signing client returns the CSR to the payment terminal. Subsequently, the payment terminal uploads the CSR, along with necessary secondary authentication factors (e.g., the user's payment password and SMS verification code), to the remote payment server via an encrypted channel. Upon receiving the CSR, the payment server executes a rigorous verification process, including verifying the user's identity, checking the completeness and signature validity of the CSR, and confirming its compliance with the certificate issuance policy. Only after all verifications pass will the payment server generate a co-signing certificate based on the CSR and using national cryptographic algorithms.

[0020] S130. The payment terminal obtains the collaborative signature certificate from the collaborative signature client and triggers the collaborative signature client and the collaborative signature server to perform national cryptographic signature on the obtained transaction information based on the collaborative signature certificate to generate the final signature.

[0021] Specifically, "National Cryptographic Signature" refers to digital signature technology based on "National Cryptographic Algorithms" (i.e., the SM series algorithms). This includes: the National Cryptographic Digital Signature Algorithm SM2, an asymmetric encryption algorithm based on elliptic curve cryptography. In signature scenarios, it uses a private key to encrypt information (or its digest) to generate a signature, and then uses the corresponding public key to decrypt it to verify the signature. The National Cryptographic Hash Algorithm SM3 is a cryptographic hash function used to compress and calculate a fixed-length (256-bit) hash value, i.e., the "message digest," from an input message of arbitrary length. Before performing an SM2 signature, a digest of the information to be signed is usually generated using SM3, and then the digest is signed using the SM2 private key. This step ensures data integrity. The National Cryptographic Symmetric Encryption Algorithm SM4 is mentioned as a symmetric encryption algorithm used to protect the security of data transmission channels. Although it does not directly participate in the generation of the "signature," it is an indispensable part of building a complete and secure "National Cryptographic" application system, providing confidentiality protection for the transmission of sensitive information such as signature data and certificates.

[0022] Among them, such as Figure 5 As shown, step S130 includes steps S131-S134: S131. The payment terminal obtains the collaborative signature certificate from the collaborative signature client and sends the obtained transaction information to the collaborative signature client. S132. The collaborative signature client, based on the collaborative signature certificate, performs a first-level national cryptographic signature on the transaction information using the first private key component to obtain a first signature result. S133. The co-signing client sends the first signature result to the co-signing server. S134. The collaborative signature server, based on the collaborative signature certificate, uses the second private key component to perform a second-level national cryptographic signature on the first signature result to generate the final signature.

[0023] Specifically, first, the payment terminal obtains a currently valid user token from the payment server to authenticate the legitimacy of the operation. Then, the payment terminal, carrying this user token, sends a request to the co-signing client module to retrieve the co-signing certificate successfully downloaded and securely stored locally during the previous certificate application process. After successfully obtaining the co-signing certificate, the payment terminal constructs complete transaction information including elements such as the payer, payee, transaction amount, and timestamp. Next, the payment terminal securely sends this transaction information, along with the user token and the obtained co-signing certificate, to the co-signing client, formally initiating the digital signature request. Upon receiving the digital signature request from the payment terminal, the co-signing client does not immediately execute the signature operation. It first uses the user token attached to the digital signature request to interact with the payment server again to verify whether the signature operation is authorized. Only after receiving a successful verification response from the payment server does the co-signing client enter the core signature process. Based on the co-signing certificate, it determines the cryptographic context associated with the transaction and retrieves the first private key component bound to the certificate from its local hardware security zone. The co-signing client uses the SM3 (Simplified Chinese Cryptographic Algorithm) to calculate the original transaction information, generating a fixed-length transaction digest. Then, using the first private key component, it performs cryptographic operations on this transaction digest based on the SM2 (Simplified Chinese Cryptographic Digital Signature Algorithm), generating a first signature result. This result is a cryptographic credential obtained by hashing the transaction information and signing it with the client's private key. After generating the first signature result, the co-signing client does not directly return it to the payment terminal but instead sends it as an intermediate product to the co-signing server via a secure channel. Upon receiving the first signature result from a specific co-signing client, the co-signing server, based on the co-signing certificate associated with this transaction, retrieves the corresponding second private key component from its secure storage. Using this second private key component, the co-signing server again performs a second-level national cryptographic signature on the received first signature result based on the SM2 algorithm. This second round of operations is not a direct signature of the original data but a re-signing and authoritative endorsement of the co-signing client's signature result. After this operation, the final digital signature, or "final signature," is generated. This final signature combines the cryptographic properties of both the client's and server's private keys, making it impossible for either party to generate independently, thus forming a strongly secure collaborative signature. Finally, this final signature is returned from the co-signing server to the co-signing client, who then submits it to the payment terminal for use in subsequent payment transaction processes. Understandably, by implementing steps S131-S134, through a two-level national cryptographic signature system requiring the collaborative participation of both the co-signing client and server, the risk of transaction forgery due to a single point of private key leakage is completely eliminated. This establishes a robust tamper-proof and non-repudiation security mechanism, thereby significantly improving the overall security and trustworthiness of payment transactions from the root.

[0024] S140. The payment server receives the signed transaction information containing the final signature sent by the payment terminal, and verifies the final signature in the signed transaction information using the stored certificate public key to determine whether to continue the transaction process.

[0025] Specifically, prior to step S140, the process includes: the co-signing client initiating a verification request carrying a user token to the payment server, and receiving a successful verification response from the payment server. More specifically, at key operational nodes in the transaction processing flow, to ensure security and the legitimacy of the operation, the co-signing client will not immediately execute any instructions received from the payment terminal involving cryptographic signatures or access to sensitive data. It will first extract a valid user token from the current session and then proactively initiate a dedicated verification request carrying this user token to the payment server. Upon receiving the request, the payment server will immediately verify the authenticity, validity, and authorization of the token to perform the requested operation. Only after the verification process is fully completed will the payment server return a response clearly indicating "verification successful" to the co-signing client.

[0026] Among them, such as Figure 6 As shown, step S140 includes steps S141-S143: S141. The payment server receives the signature transaction information containing the final signature sent by the payment terminal; S142. The payment server retrieves the certificate public key corresponding to the signed transaction information from its own secure storage; S143. The payment server uses the certificate public key to perform a national cryptographic verification operation on the final signature in the signed transaction information to determine whether to continue the transaction process.

[0027] Specifically, step S143 includes: the payment server uses the certificate public key to perform a verification operation on the final signature based on the national cryptographic verification algorithm to obtain a verification result; when the verification result is successful, the payment server determines that the transaction information is legal and continues to execute payment settlement; when the verification result is unsuccessful, the payment server terminates the current transaction. More specifically, firstly, the payment server receives the signed transaction information containing the final signature from the payment terminal, and performs preliminary parsing of the signed transaction information to accurately extract the final signature generated by the two-level collaborative signing by the collaborative signing client and the collaborative signing server, as well as the original information elements of this transaction (such as transaction serial number, payer, payee, amount, timestamp, etc.). After obtaining the final signature, the payment server quickly retrieves it from its own secure storage (such as an encrypted database) based on key indexes such as user identifier, device identifier, or transaction serial number in the transaction information. When the payment server issues a collaborative signature certificate, it has already securely stored the public key portion of the certificate here. At this point, it retrieves from the secure storage the public key of the collaborative signature certificate that is uniquely bound to the payer user and their device initiating the transaction.

[0028] Next, using the obtained certificate public key and based on the national cryptographic signature verification algorithm (which is the same as the national cryptographic digital signature algorithm, SM2), a strict cryptographic signature verification operation is performed on the received final signature. This operation essentially uses the certificate public key to decrypt and compare the final signature to verify whether it was indeed generated by the correct combination of private key components paired with the certificate public key (i.e., the first and second private key components), and to confirm that the original transaction information has not been tampered with since signing. The output of this step is a clear verification result, typically "success" or "failure." When the verification result is "successful," the payment server technically confirms the following facts: 1) the transaction information was jointly authorized and signed by a legitimate, certified payment terminal and the co-signing server; 2) the information remained intact during transmission and was not tampered with. Based on this, the payment server determines that the transaction information is legal and valid, and the credit is established. Subsequently, it transmits the instruction to the core payment clearing system to continue executing subsequent payment clearing processes such as fund deduction and settlement recording. Conversely, if the signature verification result is "verification failed," it means that at least one of the above technical verifications failed. Possible reasons include: the signature is forged, the transaction information has been tampered with after signing, the public key used in the certificate does not match (possibly due to an unauthorized device attempting a transaction), or the signature format is incorrect. Regardless of the reason, the payment server, prioritizing security, immediately terminates the current transaction processing flow. It generates a transaction failure message, records it in the security audit log, and returns a clear failure message to the payment terminal, without initiating any fund transfer operations. Through this rigorous, cryptographically-based strong verification mechanism, the payment server ensures the authenticity, integrity, and non-repudiation of every payment transaction, effectively preventing fraudulent transactions.

[0029] For ease of understanding, the transaction processing method of this invention will now be illustrated with one example each from the fields of fintech and healthcare: In the fintech field, particularly in scenarios such as digital asset trading, cross-border payments, and wealth management for high-net-worth clients, there are stringent requirements for transaction security, non-repudiation, and auditability. Taking "NFC-based offline transfer of large-value digital assets using national cryptographic collaborative signatures" as an example, this method can construct an asset near-field transfer system designed to achieve a high level of security and prevent single-point-of-failure risks. Imagine this scenario: a high-net-worth client needs to instantly and securely transfer a contract prepayment worth several million yuan in digital currency to a partner during an offline business meeting. Traditional mobile payment or single-device signature solutions face specific risks in this scenario: if the client's mobile phone is infected with malware, leading to the leakage of the payment private key, attackers may forge transfer instructions, resulting in financial losses; or the transaction information may be hijacked and tampered with during transmission, leading to incorrect recipients or amounts, causing financial and legal disputes. The application process of this method aims to specifically mitigate these risks. First, when a customer first activates the NFC large-amount transfer function of their digital wallet app, the "collaborative signature certificate" preparation process is triggered: the security chip built into their phone (acting as the collaborative signature client) and the collaborative signature server of the digital asset issuing institution securely collaborate. Both parties generate a first private key component and a second private key component, and jointly generate a certificate signature request based on these. After the customer authorizes this request on the app, it is submitted to the asset registration and settlement system (payment server), which issues a collaborative signature certificate representing the joint identity of "the customer, this device, and the issuing institution". The public key of the certificate is securely stored in the asset registration and settlement system, while the private key components are securely stored in the customer's phone chip and the institution's server, respectively. Without the private key component of either party, a valid and complete signature cannot be generated. When the customer actually makes a transfer, they enter the amount in the app, select the recipient, and trigger NFC payment. The system will execute the following key steps: 1) Real-time authorization verification: The app (payment terminal) obtains a temporary session token from the settlement system and initiates a signature request to the local security chip. The security chip does not sign immediately, but instead sends a real-time verification request to the payment server with this token. This is to ensure that the operation is authorized by the central system and to improve the transaction security threshold in scenarios where the terminal may be maliciously manipulated. 2) Two-level collaborative signature: After successful verification, the security chip uses its first private key component to perform a first-level SM2 national cryptographic signature on the transaction information containing transfer details, generating an intermediate signature result. This intermediate result is then sent to the co-signing server of the asset issuing institution, which uses its second private key component to perform a second-level SM2 national cryptographic signature on it, ultimately generating a unique final signature that can serve as a strong authentication and integrity verification credential. This process requires the joint participation and mutual constraints of the client device and the financial institution's server. 3) Near-field delivery and on-chain verification: The complete transaction information package carrying the final signature is transmitted to the payee's device via NFC and finally submitted to the asset registration and settlement chain.The settlement chain node (payment server) uses a pre-stored certificate public key to verify the final signature using the national cryptographic standard SM2. Successful verification indicates that the large-value transfer instruction was generated through collaborative confirmation between an authorized client device and a trusted financial institution, and that the transaction content (amount and object) has remained intact since the signature. The system then completes the atomic transfer of asset ownership on the distributed ledger. If verification fails, the transaction is immediately rejected and an alert is issued. The advantages of this scheme are: it extends the security trust anchor from a single client device to a "client-institution" collaboration, aiming to prevent risks caused by single-point private key leakage; its "end-to-cloud collaboration, two-level signature" mechanism means that forging a legitimate transaction requires simultaneously breaching the client terminal's security hardware and the institution's cloud server protection, significantly increasing the complexity and cost of attacks; and the use of national cryptographic algorithms throughout the process helps achieve independent control over core financial cryptographic technologies.

[0030] In the healthcare field, issues involving the security of medical insurance funds, patient privacy protection, and medication safety place extremely high demands on the accuracy, tamper-proofing, and end-to-end traceability of identity authentication, payment instructions, and medical data operations. Taking the "Application of NFC-based Electronic Medical Insurance Vouchers with National Cryptographic Collaborative Signatures in the Entire Process of In-Clinic Settlement and Smart Pharmacies" as an example, this method enables closed-loop security management from identity verification and medical insurance payment to medication dispensing, aiming to effectively address risks such as impersonation, medical insurance fraud, prescription information tampering, and medication errors that may exist in traditional methods. Imagine this scenario: an insured patient applies for an NFC-based electronic medical insurance voucher using the National Medical Insurance Service Platform APP and goes to a designated hospital for treatment. After the doctor issues an electronic prescription in the information system, the patient can directly complete the mixed payment of medical insurance funds and personal account in the consultation room or at a self-service terminal, and accurately and securely collect the prescription medication at the smart pharmacy using the same voucher. This method provides a core security mechanism for the above process. During the certificate application and activation phase, a process similar to the "certificate download process" described in the document is completed: the security chip (co-signing client) in the patient's mobile phone or dedicated social security card collaborates with the medical insurance bureau's co-signing service to generate a co-signing certificate representing the insured person's legal identity. The public and private key pairs are thus generated and stored in two separate locations. During in-clinic settlement, the specific process is as follows: The patient brings their mobile phone or card close to the NFC card reader area of ​​the hospital's settlement terminal. The terminal (payment terminal) reads the certificate identifier and obtains the transaction information for this treatment from the hospital information system, including patient ID, prescription details, drug code, total cost, medical insurance reimbursement policy, and the amount payable by the individual. Subsequently, the terminal triggers the signature process: 1) Strong identity and authorization verification: The terminal requests and obtains a dynamic token bound to the patient's current treatment from the core medical insurance business system (payment service) through a secure channel. Then, it requests the security chip in the patient's certificate to sign the transaction information. The security chip does not sign directly but first initiates a verification request carrying the dynamic token to the medical insurance payment service. This step aims to verify the legitimacy of "this person, this certificate, this medical visit" in real time, reducing the risk of certificate misuse. 2) Collaborative signing of medical insurance payment instructions: After verification, the security chip uses its first private key component to perform a first-level SM2 national cryptographic signature on the transaction message that aggregates payment details and prescription information. The generated intermediate signature result is immediately sent to the medical insurance bureau's collaborative signing server. The server uses its second private key component to perform a second-level SM2 national cryptographic signature on the intermediate result, generating a final signature that requires collaborative authorization from both the insured person's end and the medical insurance bureau's end. This signature mechanism aims to ensure that core data such as payment amount, reimbursement ratio, and drug list are difficult to be tampered with by a single link during transmission and processing, because any tampering will destroy the validity of the collaborative signature. 3) Payment execution and fund settlement: The payment information carrying the final signature is transmitted back to the hospital terminal and uploaded to the medical insurance core system for clearing.The payment server uses the public key of the patient's credential certificate stored in the database to verify the final signature using the national cryptographic standard SM2. If the verification is successful, the system automatically transfers the medical insurance fund to the individual's account based on the verification result, and stores the payment result along with the signature information, forming an auditable electronic voucher. After completing the payment, the patient goes to the smart pharmacy to pick up their medication. The pharmacist clicks "swipe card to pick up medication" on the dispensing system, and the patient presents their NFC medical insurance voucher again. The pharmacy system reads the voucher information via NFC and initiates a "medication pickup verification" request to the core medical insurance system. The request may include the transaction serial number or final signature generated during payment. The medical insurance system verifies the association between the signature and the current medication pickup request. After confirming that everything is correct, it returns a "dispensing allowed" instruction and a medication list to the pharmacy system. The pharmacist dispenses the medication according to the system instructions. The technological advantages of this solution are as follows: First, it upgrades medical insurance payment from "unilateral confirmation" to "joint signature by the insured and the medical insurance bureau" through "end-to-end collaborative signature," significantly increasing the difficulty of tampering with transaction information on the terminal side and successfully committing fraud, as any tampering will cause the collaborative signature verification to fail. Second, it strongly binds the payment signature to specific prescription information, making the "payment voucher" simultaneously a "medication-related voucher," achieving a seamless connection from "funds flow" to "medication flow." This helps reduce the risk of patients receiving medications that do not match the signed and verified payment information, thereby improving medication safety. Finally, the entire process uses national cryptographic algorithms, employing high-strength cryptographic algorithms to ensure the confidentiality and integrity of massive amounts of electronic medical insurance vouchers, payment data, and health privacy information at each stage of generation, transmission, and verification.

[0031] The transaction processing method of this invention involves the payment server generating a collaborative signature certificate based on a certificate signature request file jointly generated by the collaborative signature client and the collaborative signature server; the payment terminal triggering the collaborative signature client and the collaborative signature server to perform national cryptographic signature on the obtained transaction information based on the collaborative signature certificate to generate a final signature; and the payment server verifying the final signature to determine whether to continue the transaction process. This method not only effectively solves the security bottleneck caused by single-key signature in traditional transactions but also eliminates the risk of forging transactions due to a single point of private key leakage, thereby improving the security of transaction processing.

[0032] It should be understood that the sequence number of each step in the above embodiments 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 the present invention.

[0033] The software tools or components not belonging to our company that appear in the embodiments of this application are merely examples and do not represent actual use.

[0034] In one embodiment, a transaction processing system 200 is provided, which corresponds one-to-one with the transaction processing methods described in the above embodiments. For example... Figure 7 As shown, the transaction processing system 200 includes a generation unit 100 configured in the co-signing client 10 and the co-signing server 20, a transmission generation unit 301 and an acquisition trigger unit 302 configured in the payment terminal 30, and a verification unit 401 configured in the payment server 40. Detailed descriptions of each functional module are as follows: The generation unit 100 is used for the collaborative signing client and the collaborative signing server to jointly generate a certificate signature request file; The transmission generation unit 301 is used by the payment terminal to transmit the certificate signing request file obtained from the co-signing client to the payment server to generate a co-signing certificate; The acquisition trigger unit 302 is used by the payment terminal to acquire the collaborative signature certificate from the collaborative signature client, and trigger the collaborative signature client and the collaborative signature server to perform national cryptographic signature on the acquired transaction information based on the collaborative signature certificate to generate the final signature; The verification unit 401 is used by the payment server to receive the signed transaction information containing the final signature sent by the payment terminal, and to verify the final signature in the signed transaction information using the stored certificate public key to determine whether to continue the transaction process.

[0035] In one embodiment, the generation unit 100 is specifically used for: The co-signing client generates a first private key component and generates a first part of the certificate signing request file based on the first private key component; The co-signing server generates a second private key component and generates a second part of the certificate signing request file based on the second private key component; The co-signing server generates the certificate signing request file based on the second part of the certificate signing request file and the first part of the certificate signing request file sent by the co-signing client.

[0036] In one embodiment, the transmission generation unit 301 is specifically used for: The payment terminal obtains the certificate signature request file from the co-signing client; The payment terminal transmits the certificate signing request file to the payment server, so that the payment server, after verifying the validity of the certificate signing request file, generates the collaborative signature certificate based on the certificate signing request file.

[0037] In one embodiment, the trigger unit 302 is specifically used for: The payment terminal obtains the collaborative signature certificate from the collaborative signature client and sends the obtained transaction information to the collaborative signature client; The collaborative signature client, based on the collaborative signature certificate, performs a first-level national cryptographic signature on the transaction information using the first private key component to obtain a first signature result. The collaborative signing client sends the first signature result to the collaborative signing server; The collaborative signature server, based on the collaborative signature certificate, uses the second private key component to perform a second-level national cryptographic signature on the first signature result, generating the final signature.

[0038] In one embodiment, the trigger unit 302 is further configured to: A transaction digest is generated from the transaction information using the national cryptographic hash algorithm.

[0039] In one embodiment, the trigger unit 302 is further configured to: Using the first private key component, a first-level national cryptographic signature is performed on the transaction digest based on the national cryptographic digital signature algorithm.

[0040] In one embodiment, the verification unit 401 is specifically used for: The payment server receives the signature transaction information containing the final signature sent by the payment terminal; The payment server retrieves the certificate public key corresponding to the signed transaction information from its own secure storage; The payment server uses the certificate public key to perform a national cryptographic verification operation on the final signature in the signed transaction information to determine whether to continue the transaction process.

[0041] In one embodiment, the verification unit 401 is further configured to: The payment server uses a certificate public key and performs a signature verification operation on the final signature based on the national cryptographic signature verification algorithm to obtain the signature verification result. When the signature verification result is successful, the payment server determines that the transaction information is legal and continues to execute the payment settlement. When the signature verification result is a signature verification failure, the payment server terminates the current transaction.

[0042] In one embodiment, the transaction processing system 200 further includes a return unit configured on the co-signing server and an initiation and reception unit configured on the co-signing client, wherein: The return unit is used by the co-signing server to return the generated certificate signing request file to the co-signing client; The initiating and receiving unit is used by the co-signing client to initiate a verification request carrying a user token to the payment server, and to receive a verification success response returned by the payment server. In this invention, the transaction processing system generates a collaborative signature certificate by the payment server based on a certificate signature request file jointly generated by the collaborative signature client and the collaborative signature server. The payment terminal triggers the collaborative signature client and the collaborative signature server to perform national cryptographic signature on the obtained transaction information based on the collaborative signature certificate to generate a final signature. The payment server verifies the final signature to determine whether to continue the transaction process. This not only effectively solves the security bottleneck caused by single-key signature in traditional transactions, but also eliminates the risk of forging transactions due to a single point of private key leakage, thus improving the security of transaction processing.

[0043] For specific limitations regarding the transaction processing system, please refer to the limitations on the transaction processing methods above, which will not be repeated here. Each unit in the aforementioned transaction processing system can be implemented entirely or partially through software, hardware, or a combination thereof. These units can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each of the above modules.

[0044] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 8 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a transaction processing method on the server side.

[0045] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 9 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a transaction processing method on the client side.

[0046] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: The client and server collaborate to generate a certificate signing request file. The payment terminal will transmit the certificate signing request file obtained from the co-signing client to the payment server to generate a co-signing certificate; The payment terminal obtains the collaborative signature certificate from the collaborative signature client and triggers the collaborative signature client and the collaborative signature server to perform national cryptographic signature on the obtained transaction information based on the collaborative signature certificate to generate the final signature; The payment server receives the signed transaction information containing the final signature sent by the payment terminal, and uses the stored certificate public key to verify the final signature in the signed transaction information to determine whether to continue the transaction process.

[0047] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor: The client and server collaborate to generate a certificate signing request file. The payment terminal will transmit the certificate signing request file obtained from the co-signing client to the payment server to generate a co-signing certificate; The payment terminal obtains the collaborative signature certificate from the collaborative signature client and triggers the collaborative signature client and the collaborative signature server to perform national cryptographic signature on the obtained transaction information based on the collaborative signature certificate to generate the final signature; The payment server receives the signed transaction information containing the final signature sent by the payment terminal, and uses the stored certificate public key to verify the final signature in the signed transaction information to determine whether to continue the transaction process.

[0048] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0049] Those skilled in the art will understand 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 can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0050] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0051] It should be noted that any AI models, software tools, or components not belonging to this company appearing in the embodiments of this application are merely illustrative examples and do not represent actual use. All user personal information involved in the embodiments of this application has been authorized (with the knowledge and consent) by the relevant parties or has been fully authorized by all parties, and the executing entity may obtain it through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with relevant laws and regulations and do not violate public order and good morals.

[0052] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A transaction processing method, characterized in that, include: The client and server collaborate to generate a certificate signing request file. The payment terminal will transmit the certificate signing request file obtained from the co-signing client to the payment server to generate a co-signing certificate; The payment terminal obtains the collaborative signature certificate from the collaborative signature client and triggers the collaborative signature client and the collaborative signature server to perform national cryptographic signature on the obtained transaction information based on the collaborative signature certificate to generate the final signature; The payment server receives the signed transaction information containing the final signature sent by the payment terminal, and uses the stored certificate public key to verify the final signature in the signed transaction information to determine whether to continue the transaction process.

2. The transaction processing method as described in claim 1, characterized in that, The steps for the collaborative signing client and server to jointly generate a certificate signing request file include: The co-signing client generates a first private key component and generates a first part of the certificate signing request file based on the first private key component; The co-signing server generates a second private key component and generates a second part of the certificate signing request file based on the second private key component; The co-signing server generates the certificate signing request file based on the second part of the certificate signing request file and the first part of the certificate signing request file sent by the co-signing client.

3. The transaction processing method as described in claim 2, characterized in that, Before the step of the payment terminal transmitting the certificate signing request file obtained from the co-signing client to the payment server to generate a co-signing certificate, the method further includes: The co-signing server returns the generated certificate signing request file to the co-signing client; The steps by which the payment terminal transmits the certificate signing request file obtained from the co-signing server to the payment server to generate a co-signing certificate include: The payment terminal obtains the certificate signature request file from the co-signing client; The payment terminal transmits the certificate signing request file to the payment server, so that the payment server, after verifying the validity of the certificate signing request file, generates the collaborative signature certificate based on the certificate signing request file.

4. The transaction processing method as described in claim 2, characterized in that, The payment terminal obtains the collaborative signature certificate from the collaborative signature client and triggers the collaborative signature client and the collaborative signature server to perform national cryptographic signature on the obtained transaction information based on the collaborative signature certificate to generate the final signature, including the following steps: The payment terminal obtains the collaborative signature certificate from the collaborative signature client and sends the obtained transaction information to the collaborative signature client; The collaborative signature client, based on the collaborative signature certificate, performs a first-level national cryptographic signature on the transaction information using the first private key component to obtain a first signature result. The collaborative signing client sends the first signature result to the collaborative signing server; The collaborative signature server, based on the collaborative signature certificate, uses the second private key component to perform a second-level national cryptographic signature on the first signature result, generating the final signature.

5. The transaction processing method as described in claim 4, characterized in that, Before the step of performing a first-level national cryptographic signature on the transaction information using the first private key component, the method further includes: A transaction digest is generated from the transaction information using the national cryptographic hash algorithm.

6. The transaction processing method as described in claim 5, characterized in that, The step of performing a first-level national cryptographic signature on the transaction information using the first private key component includes: Using the first private key component, a first-level national cryptographic signature is performed on the transaction digest based on the national cryptographic digital signature algorithm.

7. The transaction processing method as described in claim 1, characterized in that, Before the payment server receives the signed transaction information containing the final signature sent by the payment terminal, and verifies the final signature in the signed transaction information using the stored certificate public key to determine whether to continue the transaction process, the process further includes: The co-signing client initiates a verification request carrying the user token to the payment server and receives a verification success response from the payment server.

8. The transaction processing method as described in claim 1, characterized in that, The payment server receives the signed transaction information containing the final signature sent by the payment terminal, and verifies the final signature in the signed transaction information using the stored certificate public key to determine whether to continue the transaction process. This includes the following steps: The payment server receives the signature transaction information containing the final signature sent by the payment terminal; The payment server retrieves the certificate public key corresponding to the signed transaction information from its own secure storage; The payment server uses the certificate public key to perform a national cryptographic verification operation on the final signature in the signed transaction information to determine whether to continue the transaction process.

9. The method according to claim 8, characterized in that, The payment server uses the certificate public key to perform a national cryptographic verification operation on the final signature in the signed transaction information to determine whether to continue the transaction process, including: The payment server uses a certificate public key and performs a signature verification operation on the final signature based on the national cryptographic signature verification algorithm to obtain the signature verification result. When the signature verification result is successful, the payment server determines that the transaction information is legal and continues to execute the payment settlement. When the signature verification result is a signature verification failure, the payment server terminates the current transaction.

10. A transaction processing system, characterized in that, include: The generation unit configured in the co-signing client and co-signing server, the transmission generation unit and acquisition trigger unit configured in the payment terminal, and the verification unit configured in the payment server, wherein: The generation unit is used for the collaborative signing client and the collaborative signing server to generate a certificate signature request file. The transmission generation unit is used by the payment terminal to transmit the certificate signing request file obtained from the co-signing client to the payment server to generate a co-signing certificate; The acquisition triggering unit is used by the payment terminal to acquire the collaborative signature certificate from the collaborative signature client, and trigger the collaborative signature client and the collaborative signature server to perform national cryptographic signature on the acquired transaction information based on the collaborative signature certificate to generate the final signature; The verification unit is used by the payment server to receive the signed transaction information containing the final signature sent by the payment terminal, and to verify the final signature in the signed transaction information using the stored certificate public key to determine whether to continue the transaction process.

Images