A payment and immediate invoicing method and system for a trusted transaction environment

Abstract

The application discloses a payment and invoice opening method and system for a trusted transaction environment, and belongs to the technical field of computers. The existing payment and invoice opening scheme is based on a centralized architecture, payment data and invoice data belong to different systems, and lacks trusted association and is easy to be tampered with. A user terminal initiates a payment request, a payment gateway verifies the request and assembles a standardized transaction data packet to be submitted to a consensus node of a consortium chain, the consensus node verifies and packs the transaction data packet into a new block and writes the new block into a distributed ledger, an invoice opening smart contract listens to a transaction confirmation event, creates an invoice opening task and sends the invoice opening task to an invoice opening service module when conditions are met, the invoice opening service module generates invoice data, performs a hash operation to obtain a hash value, uses a private key to perform a digital signature, and the invoice opening smart contract assembles the invoice data, the hash value, a signature value and an associated transaction hash value into a proof storage structure and submits the proof storage structure to the consortium chain for storage. The application realizes trusted connection of payment and invoice opening, and ensures data cryptographic association and non-tamperability.

Description

Technical Field

[0001] This application belongs to the field of computer technology, and specifically relates to a payment and invoicing method and system for a trusted transaction environment. Background Technology

[0002] With the increasing popularity of e-invoices, consumers have a growing demand for instant invoices after completing payments. "Payment and invoicing" has become an important direction for improving user experience and tax management efficiency. Currently, there are technical solutions that connect the payment system and the invoicing system to automatically trigger the invoicing process after payment. The basic idea of ​​this type of solution is that after the transaction is completed, the payment system transmits the transaction information to the invoicing system through the application programming interface. The invoicing system then generates an e-invoice based on the received transaction information and pushes it to the consumer.

[0003] However, the aforementioned existing solutions are all based on traditional centralized system architectures, with payment systems and invoicing systems deployed independently. Payment data and invoice data are stored in different centralized databases, resulting in a lack of a unified and reliable data association mechanism between payment information and invoicing information. Data consistency is difficult to guarantee, and the data stored in a centralized manner is at risk of being tampered with or forged. The authenticity and integrity of invoices lack cryptographic technical protection. In addition, the association between payment and invoicing behaviors depends on interface calls between systems. This association does not form an immutable chain of evidence at the technical level, making it difficult to meet the high reliability requirements of payment-invoicing services in a trusted transaction environment.

[0004] Therefore, there is an urgent need in the existing technology for a payment invoice method and system that can automatically and reliably generate invoices after a payment transaction is completed, and ensure that there is a cryptographic link and immutability between the payment data and the invoice data. Summary of the Invention

[0005] The purpose of this invention is to provide a payment and invoicing method and system for a trusted transaction environment, which can effectively solve the problems mentioned in the background art.

[0006] To achieve the above objectives, the technical solution adopted by the present invention is as follows: Firstly, a payment-invoicing method for trusted transaction environments includes: The payment gateway receives a payment request initiated by a user terminal, verifies the payment request, and after the verification is successful, assembles the payment request into a standardized transaction data packet and submits it to the consensus node of the consortium blockchain. The consensus node verifies the transaction data, and after the verification is successful, packages the transaction data into a new block and writes it into the distributed ledger. The invoicing smart contract deployed on the consortium blockchain listens for transaction confirmation events on the consortium blockchain. When it hears a transaction confirmation event for a payment transaction and determines that the payment transaction meets the preset invoicing trigger conditions, the invoicing smart contract creates an invoicing task and sends it to the invoicing service module. The invoicing service module receives the invoicing task, generates invoice data based on the transaction information in the invoicing task, performs a hash operation on the invoice data to obtain an invoice hash value, and uses the invoicing party's private key to perform a digital signature operation on the invoice hash value to obtain a digital signature value. The invoicing smart contract receives the invoice data, the invoice hash value, and the digital signature value returned by the invoicing service module, assembles the invoice data, the invoice hash value, the digital signature value, and the associated transaction hash value into a storage structure, submits it to the consortium blockchain, and writes it into the distributed ledger after verification by the consensus node.

[0007] Secondly, a payment-instant-invoice system for a trusted transaction environment, used to execute the above method, includes: The user terminal is used to initiate payment requests and receive invoice results. The payment gateway is used to receive the payment request initiated by the user terminal, perform necessary format and legality checks on the request data, and after the checks are passed, assemble the payment request into a standardized transaction data packet and submit it to the consortium blockchain. A consortium blockchain consists of multiple consensus nodes and uses a Byzantine fault-tolerant consensus mechanism to store transaction data and invoice evidence data and execute smart contracts deployed on the chain. The invoicing smart contract is deployed on the consortium blockchain to continuously monitor on-chain payment events. When a transaction confirmation event for a payment transaction is detected and it is determined that the payment transaction meets the preset invoicing conditions, an invoicing task is created and sent to the invoicing service module. The invoicing service module is deployed on the backend server accessible by the consortium blockchain. It is used to receive the invoicing task, generate complete invoice data based on transaction information and merchant tax configuration, perform hash operation on the invoice data to obtain the invoice hash value, perform digital signature operation on the invoice hash value using the invoicing party's private key to obtain the digital signature value, and return the invoice data, the invoice hash value and the digital signature value to the invoicing smart contract. The invoicing smart contract is also used to assemble the complete invoice data, the invoice hash value, the digital signature value and the associated transaction hash value into a notarization structure and submit it to the consortium blockchain. After verification by the consensus node, it is written into the distributed ledger. The verification interface, deployed on the consortium blockchain node, is used to receive verification requests, retrieve the corresponding evidence storage structure from the distributed ledger based on the invoice identifier, and return the evidence storage data. Tax supervision nodes are tax agency nodes that join the network as participants in the consortium blockchain. They have full ledger synchronization and query permissions and are used to obtain all on-chain evidence data in real time and conduct regulatory verification.

[0008] In summary, this application includes at least one of the following beneficial technical effects: 1. This invention assembles payment requests into standardized transaction data packets through a payment gateway and submits them to a consortium blockchain to be written into a distributed ledger. Additionally, the invoicing smart contract assembles invoice data, invoice hash values, digital signature values, and associated transaction hash values ​​into a notarization structure and writes it into the distributed ledger. This allows payment transactions and invoice notarization to be stored in the same distributed ledger. The transaction hash value enables a cryptographic link between payment information and invoice information, forming an immutable chain of evidence. This overcomes the technical shortcomings of traditional centralized architectures, where the payment system and invoicing system are independent, resulting in poor data correlation and difficulty in ensuring invoice accuracy.

[0009] 2. This invention uses a smart contract deployed on a consortium blockchain to monitor transaction confirmation events and automatically creates an invoicing task and sends it to the invoicing service module when the payment transaction meets the preset invoicing trigger conditions. This allows the invoicing process to be automatically triggered and executed by the smart contract on the consortium blockchain, without relying on the interface calls between the payment system and the invoicing system in the traditional centralized architecture. This overcomes the technical defect in the prior art where the invoicing process cannot proceed normally due to the interruption of the centralized interface service, and improves the stability and reliability of the payment-invoicing system.

[0010] 3. This invention uses an invoice service module to perform hash operations on invoice data to obtain an invoice hash value, uses the invoice issuer's private key to perform digital signature operations on the invoice hash value to obtain a digital signature value, and the invoice smart contract assembles the above data together with the transaction hash value into a notarization structure and submits it to the consortium blockchain to be written into the distributed ledger. This makes the invoice data protected by hash solidification, signature authentication and blockchain notarization, making it difficult to tamper with, and overcoming the technical defects of existing centralized systems where invoice data is easily forged or tampered with.

[0011] 4. This invention assembles invoice data, invoice hash value, digital signature value, and associated transaction hash value into a notarization structure through an invoicing smart contract and submits it to the consortium blockchain to be written into the distributed ledger. This allows the verification party to directly obtain the notarization data from the distributed ledger and independently complete hash comparison and signature verification without relying on a centralized verification system. The verification process is only affected by hash calculation and signature decryption operations, overcoming the technical defects of the prior art that the verification process is time-consuming and lengthy due to the reliance on a centralized system to query each item. Attached Figure Description

[0012] Figure 1 This is a diagram illustrating the architecture of the instant payment invoicing system provided in this application embodiment.

[0013] Figure 2 The overall flowchart of the payment and invoicing method provided in the embodiments of this application is shown.

[0014] Figure 3 The flowchart for smart contract triggering and invoicing task distribution provided in this application embodiment is shown.

[0015] Figure 4 A flowchart illustrating the invoice generation, signing, and on-chain evidence storage process provided in this application embodiment.

[0016] Figure 5 A flowchart illustrating the on-chain verification and privacy-preserving verification modes provided in this application embodiment. Detailed Implementation

[0017] To further illustrate the technical means and effects adopted by the present invention to achieve the intended purpose, the following detailed description of specific embodiments based on the present invention is provided in conjunction with the accompanying drawings and preferred embodiments.

[0018] like Figure 1 As shown, the payment-instant-invoicing system for a trusted transaction environment proposed in this invention includes a user terminal, a payment gateway, a consortium blockchain, an invoicing service module, a smart contract, a verification interface, and a tax supervision node.

[0019] The user terminal is used to initiate payment requests and receive invoice results, and supports electronic devices with network communication capabilities such as smartphones, personal computers, and tablets. Users initiate payment operations through a client or webpage on the terminal and send the payment request to the payment gateway.

[0020] The payment gateway acts as a communication bridge between the user terminal and the consortium blockchain. It is responsible for receiving payment requests, performing necessary format and legality checks on the request data, generating standardized transaction data packets, and submitting these packets to the consortium blockchain. The transaction data packet must include at least a unique transaction identifier, merchant identifier, merchant tax registration number, transaction amount, transaction timestamp, and product details. The payment gateway communicates with the consortium blockchain consensus nodes via the gRPC protocol.

[0021] A consortium blockchain is a distributed ledger network composed of multiple consensus nodes. It employs a Byzantine fault-tolerant consensus mechanism, with each node jointly maintaining the integrity and consistency of the distributed ledger. The consortium blockchain is responsible for storing transaction data and invoice notarization data, and executing smart contracts deployed on the chain. Consensus nodes synchronize blocks and exchange consensus messages via a P2P protocol.

[0022] A smart contract is program logic deployed on a consortium blockchain. It continuously monitors on-chain payment events in an event-driven manner. Once a payment transaction is detected as completed and confirmed on the blockchain, the invoicing process is automatically triggered. The smart contract internally includes an event monitoring module, a rule judgment module, and a cross-chain call module. These modules are used to monitor on-chain events, determine whether a transaction meets preset invoicing conditions, and call the invoicing service module via a cross-chain interface, respectively.

[0023] The invoicing service module is deployed on a backend server accessible by the consortium blockchain. It is responsible for generating invoice data, performing digital signature calculations, and managing the invoicing party's key pair. The module has a built-in security module for storing private keys, and access to these private keys requires authentication and permission verification. This module provides a standard API interface. After receiving invoicing task parameters from the smart contract, it assembles the invoice data, calculates the invoice hash value, digitally signs it using the private key, and finally returns the signed invoice data to the smart contract.

[0024] The verification interface is deployed on consortium blockchain nodes, providing standardized query services that allow verification parties to retrieve invoice storage data by invoice number, invoice hash value, or associated transaction hash value. Secure communication between the verification interface and the verification terminal is achieved through two-way authentication via the HTTPS protocol.

[0025] Tax supervision nodes are tax agency nodes that join the network as participants in the consortium blockchain. They have full ledger synchronization and query permissions and can obtain all on-chain evidence data in real time for supervision and verification.

[0026] In the above system, the user terminal communicates with the payment gateway via the HTTPS protocol, the payment gateway communicates with the consortium blockchain consensus nodes via the gRPC protocol, the smart contract interacts with the invoicing service module through the consortium blockchain's internal message passing mechanism, and the consensus nodes synchronize blocks and exchange consensus messages via the P2P protocol.

[0027] like Figure 2 As shown, the payment-instant-invoice method for a trusted transaction environment proposed in this invention includes the following steps: Step S1: Record the payment transaction on the blockchain.

[0028] This embodiment realizes the receipt of user payment requests, format verification, standardized encapsulation of transaction data, digital signature, and submission to the consortium blockchain to complete consensus and on-chain, forming an on-chain transaction record that can trigger the subsequent invoicing process.

[0029] S101: The user initiates a payment request to the payment gateway through the user terminal. The payment request must include at least the necessary fields such as merchant identifier, transaction amount, product information and buyer information.

[0030] After receiving a payment request, the payment gateway performs format validation on the request data. The validation includes field integrity checks, data type validation, numerical range validation, and merchant identifier validity validation. Among them, the numerical range validation requires that the transaction amount be a positive number with a precision of no more than two decimal places. The merchant identifier validity validation ensures that the merchant identifier conforms to the unified coding standard and has been registered in the payment gateway. The product information format must conform to the predefined JSON template requirements. If any validation fails, the payment gateway directly rejects the request and returns an error message.

[0031] S102: After the verification is successful, the payment gateway will assemble the request data into a standardized transaction data packet. The transaction data packet adopts JSON format and contains information fields such as transaction unique identifier, merchant unique identifier, merchant tax registration number, transaction amount, transaction timestamp, product details list and buyer identifier. The transaction unique identifier is generated by the payment gateway according to the UUID v4 rule to ensure global uniqueness.

[0032] The specific format of the transaction JSON data packet is defined as follows: txId is a UUID v4 format string (required), merchantId is an 18-digit unified social credit code string (required), merchantTaxRegNo is a 15-digit tax registration number string (required), amount is a positive numeric type accurate to the cent (required), timestamp is an ISO 8601 format time string (required), items is a product detail array, each element containing fields such as itemName (product name), specification (specification model), quantity, and unitPrice (unit price), and buyerId is a buyer identifier string (optional).

[0033] The payment gateway uses a pre-configured and securely stored private key of the payer to digitally sign the transaction data packet. The digital signature algorithm adopts the elliptic curve digital signature algorithm, and the elliptic curve is selected as secp256k1 curve. The signature operation generates a 64-byte signature value. The private key is generated by the payer through a key generation algorithm during system initialization and stored in the secure storage area of ​​the payment gateway. The payment gateway encapsulates the transaction data packet together with the calculated digital signature value into a transaction request and submits the transaction request to any consensus node of the consortium blockchain.

[0034] S103: After receiving a transaction request, the consensus node first uses the payer's public key to verify the validity of the digital signature. If the signature verification fails, the transaction request is rejected directly and a failure log is recorded. If the signature verification passes, the authenticity of the transaction source is confirmed.

[0035] After the signature verification is successful, the consensus node broadcasts the transaction request to the entire consortium blockchain network, triggering the consensus mechanism. Each consensus node in the network independently verifies the received transaction. The verification includes signature validity verification, transaction data packet format standardization verification, and business rule verification. The business rule verification includes confirming that the transaction amount is not lower than the invoicing amount threshold pre-configured in this embodiment, and that the merchant's status is normal operation and not frozen. After all consensus nodes have verified the transaction, the PBFT (Practical Byzantine Fault Tolerance) consensus algorithm is used to reach a consensus. The number of consensus nodes is configured as 3f+1 (f is the number of tolerable malicious nodes). The consensus process goes through three stages: pre-prepare, prepare, and commit. Each node enters the commit stage after collecting 2f+1 valid prepare messages. Finally, after collecting 2f+1 valid commit messages, the block is confirmed to have reached a consensus. The transaction is packaged into a new block and the new blockchain is connected to the end of the main blockchain, completing the on-chain process of the payment transaction.

[0036] Step S2: The smart contract is triggered.

[0037] In this embodiment, after the payment transaction is recorded and confirmed on the blockchain, the invoicing smart contract on the consortium blockchain automatically detects the confirmation event, generates an invoicing task after rule judgment, and sends it to the invoicing service module, thereby realizing the automatic connection between the payment behavior and the invoicing process.

[0038] S201: The invoicing smart contract deployed on the consortium blockchain continuously runs its internal event listening module after initialization. The event listening module registers event filters with the consensus nodes by calling the subscription interface provided by the consortium blockchain (such as WebSocket or gRPC streaming interface) to subscribe to the transaction confirmation events of the consortium blockchain, thereby sensing the writing of new blocks in real time.

[0039] Once the payment transaction in step S1 is successfully packaged into a block and consensus confirmation is completed, the consortium blockchain triggers a transaction confirmation event. The message body of the transaction confirmation event contains at least the transaction hash, transaction content, transaction timestamp, and block height.

[0040] S202: After receiving a transaction confirmation event, the event listening module parses the event content and extracts the transaction hash and key fields from the transaction content.

[0041] The invoicing smart contract determines whether a transaction meets the invoicing trigger conditions based on preset event filtering rules. The invoicing trigger conditions include a confirmed transaction status, a payment transaction type, and a transaction amount not lower than the minimum invoicing amount threshold pre-configured in this embodiment. The minimum invoicing amount threshold can be adjusted through the consortium blockchain's management contract. If any condition is not met, the transaction confirmation event is ignored and subsequent events are monitored. If all conditions are met, the task generation process begins.

[0042] S203: The invoicing smart contract parses the basic information required for invoicing, such as the merchant's tax registration number, transaction amount, and transaction timestamp, from the transaction content.

[0043] The invoicing smart contract calls its internal preset invoicing rule engine. The invoicing rule engine maintains the merchant invoicing configuration database, which records the invoicing qualification status, invoicing permission scope, and applicable invoicing tax items of each merchant.

[0044] The merchant invoicing configuration database uses a key-value storage structure, with the merchant's tax registration number (taxId) as the primary key. Each record contains the following fields: status (an enumeration type, with values ​​of active, suspended, and revoked), maxSingleAmount (a decimal value, the maximum amount limit for a single invoice), monthlyQuota (a decimal value, the maximum monthly cumulative invoicing amount), and allowedTaxItems (a string array, a list of allowed tax item codes). The invoicing rule engine queries the database using the getMerchantConfig(taxId) method, using the merchant's tax registration number as the primary key to complete the query and return the corresponding rule configuration.

[0045] S204: If the query results show that the merchant does not have the qualifications to issue invoices or the invoicing permission is frozen, the invoicing smart contract records the failure log and stops the invoicing process; if the merchant has the qualifications to issue invoices, the invoicing smart contract creates an invoicing task object, assigns a globally unique task identifier to the invoicing task object, and fills in parameters such as the merchant's tax registration number, transaction amount, transaction timestamp, and unique transaction identifier into the invoicing task object.

[0046] The invoicing smart contract serializes the invoicing task object into JSON format and sends it to the invoicing service module through a pre-established cross-chain call interface (specifically a standard API interface based on HTTP / REST or gRPC protocol) between the consortium blockchain and the invoicing service module. It then waits for the response from the invoicing service module, thereby triggering the subsequent invoice generation and signing logic.

[0047] S205: Deep verification of the finality of payment transactions.

[0048] Upon receiving a transaction confirmation event, the event listening module does not immediately execute the invoicing trigger logic. Instead, it first parses the block height information in the event message body and obtains the latest block height that has reached final confirmation in the consortium blockchain. The invoicing smart contract calculates the difference between the two, i.e., the confirmation depth. Only when the confirmation depth of the payment transaction in the block reaches the preset security threshold in this embodiment is the subsequent invoicing condition judgment process allowed.

[0049] In this embodiment, the security threshold is preset to 6 blocks. This threshold is determined based on the following security analysis: In a consortium blockchain network using the PBFT consensus mechanism, with 3f+1 consensus nodes and allowing a maximum of f Byzantine nodes, a confirmation depth of 6 blocks can provide more than 10⁻ 9 The transaction finality guarantee is at the probabilistic level, meaning the probability of a transaction being rolled back is less than one in a billion. It meets the irreversibility security requirements of financial-grade applications, which requires that at least 6 new blocks must be generated on-chain and reach network consensus after a payment transaction. If the current confirmation depth does not reach the security threshold, the invoicing smart contract will temporarily store the transaction event in the pending event buffer inside the contract, and trigger the depth check again when a new block is generated later.

[0050] The confirmation depth mechanism is used to avoid the risk of temporary forks that may occur in consortium blockchains under extreme network partitions or malicious node behavior. It ensures that the legally valid electronic invoice issuance process is triggered only after the transaction is irreversibly and finally confirmed by the entire network, thus guaranteeing the certainty of the transaction basis on which the invoice evidence data depends.

[0051] S206: Task idempotency guarantee based on on-chain precise mapping table.

[0052] The invoicing smart contract maintains a processed transaction mapping table in the contract storage area. The processed transaction mapping table uses the transaction hash value as the key and the corresponding processing status identifier (including "pending", "processing", "completed" and "permanently failed") and operation timestamp as the value.

[0053] When the event listening module receives a new transaction confirmation event and passes the confirmation depth verification in S205, it first queries the processed transaction mapping table. If the status corresponding to the transaction hash is "completed", it is determined to be a duplicate event, ignored and the subsequent process is terminated. If the status is "processing", it is determined that the transaction has triggered the invoicing task but has not yet received a callback. The invoicing smart contract updates its last attempt timestamp and waits, without re-distributing the task. If the status is "permanently failed" or does not exist in the processed transaction mapping table, it is determined to be a valid trigger request and enters the invoicing condition judgment process in S202.

[0054] All state changes are persisted in the consortium blockchain as the ledger state of the invoicing smart contract. By leveraging the inherent distributed consistency of blockchain state, it ensures that the contract instances on each consensus node have a completely synchronized understanding of the task processing state, without the need to introduce additional external distributed locks or centralized coordination nodes.

[0055] The transition conditions for each state are as follows: (1) Pending → In Process: When the invoicing task event log is successfully written to the chain, the status is updated to "In Process" and a timestamp is recorded; (2) Processing → Completed: After receiving a valid callback from the invoicing service module and completing the evidence storage, the status is updated to "Completed"; (3) Processing → Permanent Failure: When the status is “Processing” and the timeout threshold of 30 seconds from the last attempt has been exceeded, and the number of consecutive retries has reached 3 without success, the status is updated to “Permanent Failure”.

[0056] The mapping table data is persistently stored in the contract state database of the consortium blockchain. When the smart contract restarts or a node fails and recovers, the complete mapping table data is automatically loaded from the on-chain state without the need for an additional recovery mechanism.

[0057] S207: Asynchronous distribution and status callback mechanism under the invoicing task chain.

[0058] To avoid on-chain resource blockage or timeout caused by synchronous calls to the invoicing service module (off-chain system) by the invoicing smart contract, this method adopts an asynchronous decoupled architecture. After the invoicing smart contract determines that the invoicing conditions are met in S204, it does not directly wait for the response of the invoicing service module. Instead, it encapsulates the necessary parameters required for invoicing (at least including transaction hash, merchant tax registration number, transaction amount, and transaction timestamp) into an invoicing task object, writes the invoicing task object into the log receipt of the consortium chain in the form of a structured event log, and immediately ends the current invoicing smart contract call, releasing on-chain computing resources.

[0059] The invoicing service module, independently deployed on the backend of the consortium blockchain and subscribed to the event log, parses the event content and executes the invoice data assembly, hash calculation, and digital signature operation in step S3 after listening to a new invoicing task event. After the signature is completed, the invoicing service module calls the authorization callback interface exposed in advance in the invoicing smart contract through the pre-configured consortium blockchain client. The callback interface method is submitInvoiceResult(bytes32 taskId, bytes32invoiceHash, bytes memory signature). The caller must be the address of the pre-registered invoicing service module. When calling, a valid signature must be carried to verify the identity. The calculated invoice hash value and digital signature value are submitted back to the consortium blockchain as parameters.

[0060] The structured event log is named InvoiceTaskCreated and contains the following indexed parameters: taskId (bytes32, unique task identifier) ​​and txHash (bytes32, associated transaction hash); non-indexed parameters include: merchantTaxId (string), amount (uint256, unit: cents), and timestamp (uint64). The invoicing service module subscribes to the event filtering interface of the consortium blockchain node via WebSocket to listen for the InvoiceTaskCreated event in real time.

[0061] After receiving a callback request, the invoicing smart contract first verifies whether the caller is an authorized invoicing service module. Specifically, it verifies whether the digital signature carried in the callback request matches the pre-registered public key of the invoicing service module. Then, it executes the on-chain notarization writing logic in step S4 using the callback parameters and updates the corresponding mapping table status in S206 to "completed". If the invoicing smart contract does not receive a valid callback from the invoicing service module within the preset timeout window (set to 30 seconds in this embodiment), the determination of this timeout value takes into account the following factors: the baseline time for the invoicing service module to perform invoice assembly, hash calculation, and HSM signature operation is about 5-10 seconds; the network round-trip time (RTT) for consortium blockchain transaction submission and callback is about 5-15 seconds; and about 2 times the security redundancy is reserved. The timeout parameter can be dynamically adjusted according to the actual operating environment through the system configuration management contract. The "processing" status and timestamp recorded in S206 allow nodes with system management privileges to manually trigger task replay through external transactions, or the off-chain monitoring service to periodically scan timed-out tasks and re-push event logs, thereby achieving reliable task delivery based on eventual consistency and ensuring that invoicing tasks are not lost under any abnormal circumstances.

[0062] S208: Dynamic configuration and real-time effect of invoicing conditions rules.

[0063] In this embodiment, a system configuration management contract is deployed independently on the consortium blockchain. The system configuration management contract is specifically used to store global invoicing business rule parameters (including at least the minimum invoicing amount threshold, the whitelist of invoicable transaction types, and the confirmation depth security threshold). The system configuration management contract maintains data in the form of configuration version number (monotonically increasing integer) and specific parameter key-value pairs, and has an access control mechanism that only allows transactions digitally signed by the system administrator to initiate configuration changes.

[0064] The system configuration management contract provides the following standard interfaces: getVersion() returns (uint256): Returns the current latest configuration version number; getConfig (string memory key) returns (bytes memory): Returns the corresponding configuration value based on the configuration key name; updateConfig (string memory key, bytes memory value): Updates configuration items; only administrators can call this function.

[0065] Configuration items are stored in the contract state mapping as key-value pairs. Each configuration item is associated with the effective starting block height (validFrom). Administrator privileges are controlled by a whitelist of administrator addresses specified during contract initialization. Configuration change transactions must carry the administrator's valid digital signature.

[0066] When the ticket smart contract performs the event filtering rule judgment in S202, it first reads the latest configuration version number stored in the system configuration management contract through inter-contract calls and compares it with the version number cached in the memory of the ticket smart contract. If the comparison results are inconsistent, the latest parameters are synchronized from the system configuration management contract to the memory cache. If they are consistent, the cached parameters are used directly for condition judgment.

[0067] Version comparison and cache synchronization mechanisms (such as) Figure 3 As shown, this ensures that once business rule changes are written into the system configuration management contract through consortium blockchain consensus, they take effect in real time on all subsequently triggered events without stopping the invoicing service or redeploying the invoicing smart contract code, thereby improving the system's operational flexibility in responding to dynamic adjustments in tax policies.

[0068] Step S3: Invoice generation and signing.

[0069] In this embodiment, the invoicing service module receives the invoicing task dispatched by the smart contract, generates complete invoice data based on transaction information and merchant tax configuration, performs hash operation on the invoice data and digitally signs it using the invoicing party's private key, and finally assembles the complete invoice data, invoice hash value, digital signature value and invoicing party's public key into an invoicing response object and returns it to the smart contract, thus preparing an invoice certificate with verification capabilities for subsequent on-chain notarization.

[0070] S301: After receiving the invoicing task object sent by the smart contract, the invoicing service module parses the invoicing task object to obtain parameters such as the merchant's tax registration number, transaction amount, transaction timestamp, and unique transaction identifier. The invoicing service module then queries the locally maintained tax registration database based on the merchant's tax registration number to obtain the merchant's complete invoicing information. The query results include at least the merchant's name, address, bank account number, and applicable invoicing tax rate rules. The invoicing tax rate rules record the VAT rate and other tax rates corresponding to different product categories.

[0071] S302: The invoicing service module calculates the invoice tax amount based on the transaction amount and the queried invoicing tax rate rules. The specific calculation method is as follows: the tax-exclusive amount is separated from the transaction amount. The separation method is to calculate the tax-exclusive amount by dividing the transaction amount by 1 and adding the tax rate. The tax-exclusive amount is multiplied by the applicable tax rate to obtain the tax amount. If the transaction involves multiple product categories, the tax amount of each product is calculated according to its respective tax rate and then summarized.

[0072] The invoicing service module generates a globally unique invoice number according to a preset invoice number generation rule. The invoice number generation rule adopts a combination of the invoice issuer code, the current timestamp, and a random serial number. The invoice issuer code is a unique identifier assigned to each invoice issuer during initialization in this embodiment. The timestamp is accurate to milliseconds, and the random serial number is a 6-digit number. The three are concatenated to form the invoice number. For example, the invoice issuer code is concatenated with the timestamp and then concatenated with the random serial number.

[0073] S303: The invoicing service module assembles an invoice JSON data object. The invoice JSON data object contains fields such as invoice code, invoice number, invoice issuer name, invoice issuer tax registration number, invoice issuer address and bank account, buyer name, buyer tax registration number, product details list, tax rate information, amount excluding tax, tax amount, total price including tax, and invoicing time. Each product item in the product details list further includes product name, product specifications, product unit, product quantity, unit price, tax rate, and amount.

[0074] After assembly, the invoicing service module performs normalization processing on the invoice JSON data object, converting all field values ​​in the invoice JSON data object into standard string format. Specifically, this includes rounding numeric fields to two decimal places and converting them into strings, converting time fields into ISO format strings, and converting boolean fields and null fields into fixed strings according to the following conventions: boolean value true is uniformly converted to the uppercase string "TRUE", false is uniformly converted to "FALSE"; null value is uniformly converted to "NULL"; and empty string is uniformly converted to "EMPTY".

[0075] For any newly added fields that are not predefined in the invoice JSON, they are stringified according to their original JSON data type and then used for hash calculation. The fields are serialized after being sorted alphabetically by key name to ensure the determinism of the hash input, thereby ensuring the reproducibility of subsequent hash calculations.

[0076] S304: The invoicing service module uses a cryptographically secure hash function to perform a hash operation on the normalized invoice JSON data string. The hash algorithm used is SHA256, and the operation outputs a fixed-length invoice hash value of 32 bytes. The invoice hash value serves as a digital digest of the invoice content and is used for subsequent signature operations and integrity verification.

[0077] S305: The invoicing service module obtains the invoicing party's private key from the built-in security module. The security module uses a Hardware Security Module (HSM) compliant with the FIPS 140-2 Level 3 standard, providing a PKCS#11 standard interface. The private key is stored in the security module's key storage area. Each access to the private key requires two-way authentication based on an X.509 client certificate and role-based access control (RBAC) permission verification, granting only the "Invoicing Operator" role the permission to perform the signature operation. The private key is generated internally by a true random number generator within the HSM and stored in encrypted form. The private key itself cannot be exported outside the HSM, and the entire signature operation is completed within the HSM's security boundary.

[0078] The invoicing service module uses the private key to perform an asymmetric cryptographic signature operation on the invoice hash value calculated in the previous step. The signature algorithm can be either an elliptic curve digital signature algorithm or an RSA algorithm. If an elliptic curve digital signature algorithm is used, a 64-byte signature value is generated; if an RSA algorithm is used, a 256-byte signature value is generated. After signing, the invoicing service module obtains the public key paired with the private key from the security module. The public key is publicly distributed to support subsequent signature verification. The invoicing service module assembles the invoice JSON data object (i.e., the complete invoice data), the invoice hash value, the digital signature value, and the invoicing party's public key assembled in S303 into an invoicing response object, and returns the invoicing response object to the smart contract (e.g., ...). Figure 4 (As shown).

[0079] In hash operations, the mathematical expression is H = SHA256(InvoiceData), where H represents the invoice hash value, which is 32 bytes of binary data, SHA256 represents the secure hash algorithm, and InvoiceData represents the normalized JSON data string of the invoice.

[0080] In signature operations, the mathematical expression is: ; Where Signature represents the digital signature value, the length of which depends on the selected signature algorithm; Sign represents the asymmetric signature operation process; privateKey represents the invoice issuer's private key; and H represents the invoice hash value calculated in step S304. The signature algorithm used is ECDSA, with an elliptic curve of secp256k1.

[0081] In summary, step S3 transforms the original payment transaction information into an invoice certificate with cryptographic verification capabilities through a series of operations, including querying tax configuration, calculating tax amount, generating unique number, assembling structured invoice data, normalization processing, hash digest, and digital signature. Furthermore, the invoice response object output by step S3 contains both a publicly verifiable public key and an immutable signature value, enabling the subsequent on-chain evidence storage process to write the complete invoice information and its cryptographic fingerprint into the distributed ledger, thereby ensuring the authenticity, integrity, and source credibility of the invoice data.

[0082] Step S4: On-chain evidence storage.

[0083] In this embodiment, the smart contract receives the invoicing response returned by the invoicing service module, extracts the complete invoice data, invoice hash value, digital signature value and invoicing party's public key from it, and then assembles it into a storage structure by combining the current invoicing timestamp and the associated transaction hash value. After consensus by the consortium blockchain, it is written into the distributed ledger, and finally an invoice identifier is generated and the invoicing result is notified to the payment gateway through an event mechanism.

[0084] S401: After receiving the invoicing response object returned by the invoicing service module, the smart contract parses the invoicing response object to obtain the complete invoice data, invoice hash value, digital signature value, and invoicing party's public key; the smart contract obtains the current timestamp as the invoicing timestamp, which is accurate to milliseconds; the smart contract extracts the associated transaction hash value from the transaction event in step S1 to establish the correspondence between the invoice and the original payment transaction.

[0085] S402: The smart contract assembles six data items into a storage structure: complete invoice data, invoice hash value, digital signature value, invoice issuer's public key, invoice timestamp, and associated transaction hash value. The complete invoice data is used for integrity comparison during subsequent verification. The invoice hash value serves as the digital digest benchmark value of the invoice content. The digital signature value and the invoice issuer's public key are used together to verify the authenticity of the invoice's source. The invoice timestamp is used to accurately record the invoice's generation time. The transaction hash value is used to bind the invoice to the original payment transaction.

[0086] The evidence storage structure is serialized using a binary encoding format. The length of each data item is fixedly allocated during encoding based on its data type. The evidence storage structure is serialized in binary according to the following field order and fixed length, using little-endian encoding. Text fields are uniformly encoded using UTF-8: (1) Invoice data length prefix: 2 bytes (uint16), indicating the byte length of the subsequent complete invoice data; (2) Complete invoice data: variable length, specified by the aforementioned length prefix; (3) Invoice hash value: 32 bytes (SHA256 output); (4) Digital signature value: 64 bytes (ECDSA signature, secp256k1 curve); (5) Invoice issuer public key: 65 bytes (uncompressed elliptic curve public key); (6) Invoice timestamp: 8 bytes (int64, millisecond-level Unix timestamp); (7) Transaction hash value: 32 bytes, to save storage space in the consortium blockchain.

[0087] S403: The smart contract calls the ledger writing interface provided by the consortium blockchain to submit the serialized evidence structure as the transaction content to the consortium blockchain. After receiving the write request, the consortium blockchain starts the consensus process. Each consensus node verifies the smart contract's calling permission and the validity of the evidence structure format in turn to confirm that the smart contract has write permission and that all fields of the evidence structure are complete and compliant.

[0088] After each consensus node verifies the data, a consensus is reached through the Byzantine fault-tolerant consensus algorithm. The evidence storage structure is then packaged into a new block and written into the distributed ledger. The new block is connected to the previous blockchain through a hash pointer, thus forming an immutable evidence storage chain.

[0089] S404: After the evidence data is successfully written, the smart contract generates a unique invoice identifier to point to the invoice. The unique invoice identifier can be the invoice number generated in step S302, or it can be generated by a cryptographic algorithm, such as taking the first 16 bytes of the invoice hash value and encoding it into a hexadecimal string.

[0090] The smart contract then triggers an invoice success event. The invoice success event message contains the invoice identifier, invoice timestamp, and transaction hash information. The invoice success event is then sent to the consortium blockchain's event bus. The payment gateway, as a subscriber to the event bus, extracts and saves the invoice identifier after receiving the invoice success event. At the same time, it sends the invoice success message and the invoice identifier back to the user terminal via the original communication link.

[0091] In summary, step S4 assembles the invoice data and its cryptographic fingerprint into a storage structure, writes it into the distributed ledger after consensus on the consortium blockchain, and realizes on-chain storage of invoice vouchers. At the same time, the invoicing result is fed back to the payment gateway and user terminal in real time through the event notification mechanism to ensure the closed-loop integrity of the invoicing process.

[0092] Step S5: On-chain verification.

[0093] In this embodiment, the verifier initiates a verification request carrying an invoice identifier to the verification interface of the consortium blockchain through a verification terminal. The verification interface retrieves the evidence storage structure in the distributed ledger according to the invoice identifier type and returns the complete invoice data, the invoice hash value, the digital signature value, and the invoice issuer's public key. The verification terminal uses the invoice issuer's public key to decrypt the digital signature value to obtain the original hash value, recalculates the hash value of the complete invoice data, and compares it to verify the integrity of the invoice content and the authenticity of its source. Finally, a verification report is output.

[0094] S501: The verification party initiates a verification request to the verification interface of the consortium blockchain through the verification terminal. The verification request carries an invoice identifier, which can be any one of the invoice number, invoice hash value, or associated transaction hash value. The verification terminal and the verification interface establish a secure communication channel through the HTTPS protocol and perform two-way identity authentication during the communication process. That is, the verification terminal verifies the server certificate of the verification interface, and the verification interface verifies the client certificate of the verification terminal to ensure that the identities of both parties are legitimate.

[0095] S502: After receiving the verification request, the verification interface first parses the type of the invoice identifier and selects the corresponding retrieval strategy according to the type. If it is an invoice number, it will be retrieved through the pre-established invoice number index. If it is an invoice hash value, it will be retrieved through the invoice hash index. If it is a transaction hash value, it will first retrieve the associated invoice identifier through the transaction hash index and then locate the evidence record.

[0096] After retrieving the corresponding evidence record, the verification interface sends a query request to the distributed ledger to obtain four data items from the evidence storage structure: complete invoice data, invoice hash value, digital signature value, and the invoice issuer's public key.

[0097] S503: The verification interface assembles the four data items it has obtained into a verification response and returns it to the verification terminal via an HTTPS connection. After receiving the verification response, the verification terminal begins to execute the cryptographic signature verification process. First, it uses the obtained invoice issuer's public key to decrypt the digital signature value. The result of the decryption operation is the original invoice hash value calculated during the signature. If the signature algorithm is an elliptic curve digital signature algorithm, the decryption is completed through elliptic curve dot multiplication and dot addition operations. If the signature algorithm is an RSA algorithm, the decryption is completed through modular exponentiation.

[0098] S504: The verification terminal simultaneously recalculates the hash value of the obtained complete invoice data. The calculation process is the same as the hash calculation process in step S3, that is, first, the invoice JSON data is normalized according to the same rules (converting each field into a standard string format), and then the SHA256 algorithm is used to calculate the new hash value.

[0099] The verification terminal compares the original hash value obtained from decryption with the recalculated hash value. If they match, it indicates that the invoice content has not been tampered with since it was stored. If they do not match, it indicates that the invoice data has been modified.

[0100] S505: Provided that the hash values ​​match, the verification terminal further verifies the validity of the digital signature, that is, confirms that the decryption process was successfully completed and that the digital signature was indeed generated by the private key corresponding to the invoice issuer's public key, thereby ensuring the credibility of the invoice's source.

[0101] The verification terminal outputs a verification report based on the verification results. The verification report includes the verification status and detailed verification information (such as...). Figure 5 As shown in the figure, if the hash values ​​are consistent and the signature verification is valid, the verification status is "verification passed". If the hash values ​​are inconsistent, the verification status is "verification failed" and the data is marked as tampered. If the signature verification fails, the verification status is "verification failed" and the signature is marked as invalid.

[0102] During the verification process, the mathematical expression for integrity verification is: ; Where Verify represents the signature verification process; publicKey represents the invoice issuer's public key, used to decrypt the signature; and Signature represents the digital signature value obtained from the stored evidence. This represents the hash value obtained by the verification terminal after recalculating the complete invoice data; This represents the hash value of the original invoice stored in the evidence, which serves as the comparison benchmark.

[0103] The expression indicates that the signature verification result is true only if the recalculated hash value is equal to the original hash value.

[0104] Step S5 employs a dual verification mechanism of cryptographic signature verification and hash comparison, enabling any third party to independently verify the integrity and authenticity of the invoice. The verification process does not rely on a centralized verification system, and the verification time is only affected by hash calculation and signature decryption operations. This can meet the real-time verification needs in large-scale transaction scenarios, thereby providing technical assurance for the trusted circulation of electronic invoices.

[0105] Based on steps S1 to S5, this embodiment also includes a privacy protection enhancement module, which is used to selectively disclose invoice information in specific business scenarios. The privacy protection enhancement module is integrated into the invoicing service module. Its core component is a zero-knowledge proof generator. The zero-knowledge proof generator supports zk-SNARKs or zk-STARKs zero-knowledge proof protocols and has built-in public reference strings or trusted setting parameters required for proof generation. The public reference strings and trusted setting parameters are configured during the system initialization phase.

[0106] This embodiment uses the zk-SNARKs protocol, employs the Groth16 proof system, and selects BLS12-381 elliptic curves. During the system initialization phase, a Trusted Setup ceremony is performed, in which multiple independent participants jointly generate a Common Reference String (CRS) and separate the Proving Key and Verification Key, which are deployed in the zero-knowledge proof generator of the invoicing service module and the zero-knowledge proof verifier of the consortium blockchain node, respectively.

[0107] The circuit design corresponding to each proof target is as follows: (1) For the target of "proving that the transaction amount is within the compliance range", a range proof circuit is adopted. The private input is the plaintext amount of the transaction amount, and the public input is the upper and lower bound commitment of the amount. The circuit constraint is amount≥minThreshold and amount≤maxThreshold. The circuit is described in R1CS format; (2) For the target of "proving that the transaction occurred within the valid time window", a timestamp range proof circuit is adopted. The private input is the precise transaction timestamp, and the public input is the start and end values ​​of the time window. The timestamp is verified to be within the specified interval through arithmetic constraints; (3) For the target of "proving that the commodity details meet the tax declaration compliance requirements", the commodity tax code and tax rate are used as public inputs, and the commodity detail hash is used as private inputs. The circuit constraints verify that the correspondence between the tax rate and tax item of each commodity is correct.

[0108] In the invoice generation stage of step S3, while assembling the standard invoice storage data, the invoicing service module calls the zero-knowledge proof generator to generate zero-knowledge proof information associated with the current invoice. The zero-knowledge proof generator receives sensitive fields that need to be protected in the original invoice data as private inputs. Sensitive fields include the buyer's identity information (such as name and tax registration number) and the specific product name and specifications in the product details list. At the same time, it receives non-sensitive fields that do not need to be protected in the invoice (such as transaction amount range, invoicing time interval and merchant tax registration number) as public inputs.

[0109] The zero-knowledge proof generator converts the above input into an arithmetic circuit or a polynomial constraint system according to the preset proof objective, and outputs a proof value after being calculated by the proof generation algorithm specified in the protocol. The proof value can prove to the verifier that a specific statement is true without disclosing any private original input data. For example, it can prove that the buyer has completed the payment for a specific amount of transaction, prove that the transaction occurred within a valid time window, or prove that the details of the goods meet the compliance requirements of tax declaration.

[0110] In the verification stage of step S5, the verifier can choose between the full verification mode or the privacy protection verification mode according to the specific verification needs. If the privacy protection verification mode is selected, the verifier initiates a verification request carrying zero-knowledge proof to the consortium blockchain verification interface through the verification terminal. The consortium blockchain verification interface forwards the verification request to the built-in zero-knowledge proof verifier. The zero-knowledge proof verifier uses the same public reference string and verification algorithm as in the proof generation stage to verify the validity of the proof value.

[0111] Once the verification is successful, the verification interface only returns the verification result and necessary non-sensitive metadata to the verification terminal, without returning the complete invoice data. The verification terminal can confirm the authenticity and compliance of the transaction without obtaining the original invoice data.

[0112] The enhanced privacy protection module supports various typical application scenarios. For example, when consumers verify transactions afterward, they only need to prove to a third party that they have paid a specific amount without exposing their personal identity information or the specific content of the purchase. When tax auditors conduct batch audits, they can simultaneously verify the set of zero-knowledge proofs for a group of transactions that meet specific conditions, without having to obtain complete details of each transaction individually, thereby ensuring audit efficiency while reducing contact with taxpayers' trade secrets. In supply chain audits, merchants can prove to the auditor that their total payments and invoices to upstream suppliers meet specific ratio requirements without having to disclose the specific identity of each supplier and the details of the purchase for each transaction.

[0113] In summary, the privacy protection enhancement module selectively introduces zero-knowledge proof technology into the standard payment and invoicing process. This allows the embodiment to maintain the original on-chain verification capabilities while providing an additional verification path that supports the hiding of sensitive information. The privacy protection enhancement module complements the invoice generation process in step S3 and the verification process in step S5, enabling the embodiment to flexibly switch verification modes according to different business scenarios and verification needs. This achieves a balance between invoice data availability and privacy protection, meeting the needs of data security and trade secret protection in real-world business environments.

[0114] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the present invention can be implemented in other specific forms without departing from the spirit or essential characteristics of the present invention. Therefore, the embodiments should be regarded as exemplary and non-limiting in all respects.

[0115] Furthermore, it should be understood that although this specification describes embodiments, not every embodiment includes only one independent technical solution. This narrative style is merely for clarity. Those skilled in the art should consider the specification as a whole, and the technical solutions in each embodiment can also be appropriately combined to form other embodiments that can be understood by those skilled in the art.

Claims

1. A payment-instant invoicing method for a trusted transaction environment, characterized in that, include: The payment gateway receives a payment request initiated by a user terminal, verifies the payment request, and after the verification is successful, assembles the payment request into a standardized transaction data packet and submits it to the consensus node of the consortium blockchain. The consensus node verifies the transaction data, and after the verification is successful, packages the transaction data into a new block and writes it into the distributed ledger. The invoicing smart contract deployed on the consortium blockchain listens for transaction confirmation events on the consortium blockchain. When it hears a transaction confirmation event for a payment transaction and determines that the payment transaction meets the preset invoicing trigger conditions, the invoicing smart contract creates an invoicing task and sends it to the invoicing service module. The invoicing service module receives the invoicing task, generates invoice data based on the transaction information in the invoicing task, performs a hash operation on the invoice data to obtain an invoice hash value, and uses the invoicing party's private key to perform a digital signature operation on the invoice hash value to obtain a digital signature value. The invoicing smart contract receives the invoice data, the invoice hash value, and the digital signature value returned by the invoicing service module, assembles the invoice data, the invoice hash value, the digital signature value, and the associated transaction hash value into a storage structure, submits it to the consortium blockchain, and writes it into the distributed ledger after verification by the consensus node.

2. The method according to claim 1, characterized in that, The invoicing smart contract determines that the payment transaction meets preset invoicing trigger conditions, including: The invoicing smart contract parses the block height information in the transaction confirmation event, obtains the latest block height of the consortium blockchain that has reached final confirmation, and calculates the confirmation depth of the payment transaction in the block; When the confirmation depth reaches a preset security threshold, the invoicing smart contract allows the subsequent invoicing condition judgment process to proceed; when the confirmation depth does not reach the security threshold, the invoicing smart contract temporarily stores the transaction confirmation event in the pending event buffer, and performs the confirmation depth check again when a new block is generated.

3. The method according to claim 1, characterized in that, Before the invoicing smart contract sends the invoicing task to the invoicing service module, it also includes: The invoicing smart contract obtains the transaction hash value of the payment transaction and uses the transaction hash value as the key to query the processed transaction mapping table maintained by the invoicing smart contract in the contract storage area; If the status corresponding to the transaction hash value in the processed transaction mapping table is "completed", then the invoicing smart contract determines it as a duplicate event, ignores the transaction confirmation event, and terminates the subsequent process. If the status corresponding to the transaction hash value in the processed transaction mapping table is "processing", then the invoicing smart contract updates the last attempt timestamp and waits. If the status corresponding to the transaction hash value in the processed transaction mapping table is permanent failure or does not exist in the processed transaction mapping table, then the invoicing smart contract is determined to be a valid trigger request and enters the invoicing condition judgment process.

4. The method according to claim 1, characterized in that, The invoicing smart contract sends the invoicing task to the invoicing service module, including: The invoicing smart contract writes the invoicing task into the log receipt of the consortium blockchain in the form of a structured event log and ends the current contract call. The invoicing service module subscribes to the event log, listens to the event log of the invoicing task, parses the event content, and executes the invoice generation and signature logic. After the invoicing service module completes the invoice generation and signing, it calls the authorization callback interface of the invoicing smart contract to submit the calculated invoice hash value and digital signature value back to the consortium blockchain. If the invoicing smart contract does not receive a valid callback from the invoicing service module within a preset timeout window, it triggers task replay.

5. The method according to claim 1, characterized in that, Before the invoicing smart contract determines that the payment transaction meets the preset invoicing trigger conditions, it also includes: The invoicing smart contract reads the latest configuration version number stored in the system configuration management contract deployed on the consortium blockchain through inter-contract calls, and compares the latest configuration version number with the version number cached in the memory of the invoicing smart contract; If the comparison results are inconsistent, the invoicing smart contract synchronizes the latest parameters from the system configuration management contract to the memory cache; if the comparison results are consistent, the cached invoicing condition rule parameters are used directly for condition judgment.

6. The method according to claim 1, characterized in that, The invoicing service module generates invoice data based on the transaction information in the invoicing task, performs a hash operation on the invoice data to obtain an invoice hash value, and uses the invoicing party's private key to perform a digital signature operation on the invoice hash value to obtain a digital signature value, including: The invoicing service module parses the invoicing task object to obtain transaction information, assembles an invoice JSON data object based on the transaction information, and performs normalization processing on the invoice data object; The invoicing service module uses a cryptographically secure hash function to perform a hash operation on the normalized invoice JSON data string and outputs the invoice hash value. The invoicing service module obtains the invoicing party's private key from the built-in security module, performs asymmetric encryption signature operation on the invoice hash value using the invoicing party's private key to generate the digital signature value, and obtains the public key paired with the invoicing party's private key from the security module; the private key is stored in the key storage area of ​​the security module, and each access to the private key requires identity authentication and permission verification, and the private key itself cannot be exported.

7. The method according to claim 1, characterized in that, The invoicing smart contract assembles the invoice data, the invoice hash value, the digital signature value, and the associated transaction hash value into a storage structure, including: The invoicing smart contract obtains the current timestamp as the invoicing timestamp and extracts the associated transaction hash value from the payment transaction; The invoicing smart contract assembles six data items—complete invoice data, invoice hash value, digital signature value, invoicing party's public key, invoicing timestamp, and transaction hash value—into the evidence storage structure. The evidence storage structure is serialized using a binary encoding format, and each data item is allocated a fixed storage length according to its data type during encoding.

8. The method according to claim 6, characterized in that, After assembling the invoice data object, the invoicing service module also includes: The invoicing service module calls the built-in zero-knowledge proof generator, takes the sensitive fields in the invoice data object as private inputs and the non-sensitive fields as public inputs, and the zero-knowledge proof generator converts the inputs into arithmetic circuits or polynomial constraint systems according to the preset proof target, and outputs the proof value after calculation by the proof generation algorithm. The objectives of the proof include proving that the buyer has completed payment for a specific amount of the transaction, proving that the transaction occurred within a valid time window, proving that the details of the goods meet the compliance requirements for tax declaration, and proving that the total amount of payments made to upstream suppliers and the total amount of invoices issued meet at least one of the following: The invoicing smart contract assembles the proof value together with the invoice data, the invoice hash value, and the digital signature value into the evidence storage structure.

9. The method according to claim 1, characterized in that, The payment gateway submits the transaction data packet to the consensus node of the consortium blockchain, and the consensus node verifies the transaction data, including: The payment gateway uses a pre-configured and securely stored private key of the payer to digitally sign the transaction data packet, encapsulates the transaction data packet together with the digital signature into a transaction request, and submits it to the consensus node of the consortium blockchain; the payment gateway and the consensus node communicate via the gRPC protocol; After receiving the transaction request, the consensus node uses the payer's public key to verify the validity of the digital signature. If the signature verification fails, the transaction request is rejected. After the signature verification is successful, the consensus node broadcasts the transaction request to the entire consortium blockchain network. Each consensus node independently verifies the received transaction, including signature validity verification, transaction data packet format standardization verification, and business rule verification. After all consensus nodes have verified the transaction, they reach a consensus through the Byzantine fault-tolerant consensus algorithm and package the transaction into a new block. The consensus nodes synchronize blocks and exchange consensus messages through the P2P protocol.

10. A payment-based invoicing system for a trusted transaction environment, characterized in that: For performing the method according to any one of claims 1-9, comprising: The user terminal is used to initiate payment requests and receive invoice results. The payment gateway is used to receive the payment request initiated by the user terminal, perform necessary format and legality checks on the request data, and after the checks are passed, assemble the payment request into a standardized transaction data packet and submit it to the consortium blockchain. A consortium blockchain consists of multiple consensus nodes and uses a Byzantine fault-tolerant consensus mechanism to store transaction data and invoice evidence data and execute smart contracts deployed on the chain. The invoicing smart contract is deployed on the consortium blockchain to continuously monitor on-chain payment events. When a transaction confirmation event for a payment transaction is detected and it is determined that the payment transaction meets the preset invoicing conditions, an invoicing task is created and sent to the invoicing service module. The invoicing service module is deployed on the backend server accessible by the consortium blockchain. It is used to receive the invoicing task, generate complete invoice data based on transaction information and merchant tax configuration, perform hash operation on the invoice data to obtain the invoice hash value, perform digital signature operation on the invoice hash value using the invoicing party's private key to obtain the digital signature value, and return the invoice data, the invoice hash value and the digital signature value to the invoicing smart contract. The invoicing smart contract is also used to assemble the complete invoice data, the invoice hash value, the digital signature value and the associated transaction hash value into a notarization structure and submit it to the consortium blockchain. After verification by the consensus node, it is written into the distributed ledger. The verification interface, deployed on the consortium blockchain node, is used to receive verification requests, retrieve the corresponding evidence storage structure from the distributed ledger based on the invoice identifier, and return the evidence storage data. Tax supervision nodes are tax agency nodes that join the network as participants in the consortium blockchain. They have full ledger synchronization and query permissions and are used to obtain all on-chain evidence data in real time and conduct regulatory verification.

Images