A blockchain distributed payment reconciliation platform for small and micro businesses

Abstract

The application discloses a small and micro merchant-oriented blockchain distributed payment reconciliation platform, and relates to the technical field of blockchains.The platform is composed of a four-party alliance chain architecture formed by a merchant node, an aggregated payment service provider node, a third-party payment channel node and a fund custodian bank node, and comprises a bottom-layer alliance chain ledger module and an off-chain private data storage module.The off-chain private data storage module is respectively arranged in each node locally, each node independently stores original bill plaintext files corresponding to its own business, and the data of each party is mutually isolated and cannot be directly called across nodes.The small and micro merchant-oriented blockchain distributed payment reconciliation platform generates key message authentication codes for order amounts and transaction states respectively and stores the codes on a chain based on daily negotiation and rotation of alliance keys, and original transaction data is always stored in each node locally and is not transmitted externally.

Description

Technical Field

[0001] This invention relates to the field of blockchain technology, specifically to a blockchain-based distributed payment reconciliation platform for micro and small merchants. Background Technology

[0002] Currently, small and micro-sized merchants typically connect to multiple payment channels, relying on aggregated service providers to complete payment processing and fund collection. Merchants, payment service providers, payment channels, and custodian banks generate massive transaction volumes daily, making cross-entity reconciliation a necessary step to ensure fund security. Traditional reconciliation often employs a centralized aggregation model, where all parties' bills are uniformly collected in plaintext and compared at a central node. This not only easily leads to the leakage of sensitive data such as merchant revenue and transaction records but also poses risks of single points of failure and human tampering, making it difficult to guarantee the credibility of reconciliation results.

[0003] Blockchain technology is used to solve the trust problem in reconciliation, but existing applications all have significant shortcomings:

[0004] On the one hand, the original bills are all recorded in plaintext on the blockchain, making the data completely public and failing to protect the business privacy of merchants;

[0005] Another advantage is that only the overall hash value of the statement is stored on the blockchain for evidence, which can only verify whether the document has been tampered with, but cannot distinguish the differences in amount or transaction status, and cannot achieve cross-party account reconciliation;

[0006] Furthermore, the solution combining Merkle tree notarization can only achieve batch data integrity verification, and still cannot balance privacy protection and accounting content comparison.

[0007] Based on the above, this invention proposes a blockchain-based distributed payment reconciliation platform for micro and small merchants, which can effectively solve the above problems. Summary of the Invention

[0008] To address the shortcomings of existing technologies, this invention provides a blockchain-based distributed payment reconciliation platform for micro and small merchants, resolving the defects and deficiencies in existing technologies.

[0009] To achieve the above objectives, the present invention provides the following technical solution:

[0010] A blockchain-based distributed payment reconciliation platform for micro and small merchants comprises a four-party consortium blockchain architecture consisting of merchant nodes, aggregated payment service provider nodes, third-party payment channel nodes, and fund custody bank nodes. The platform includes an underlying consortium blockchain ledger module and an off-chain private data storage module. The off-chain private data storage module is deployed locally on each node, and each node independently stores the original plaintext invoice files corresponding to its own business. Data from each party is isolated and cannot be directly accessed across nodes. Its key features are:

[0011] The platform also includes an evidence storage gateway Oracle module, a smart reconciliation contract module, and a traceable query service module, all of which are deployed within a four-party consortium blockchain architecture.

[0012] The field-level commitment unit located inside the Oracle module of the evidence storage gateway establishes data interaction with the local private storage and the consortium blockchain ledger, retrieves the encrypted original bill, generates field-level commitments based on the order flow calculation, and only pushes the order index and commitments to the chain. The original bill is stored in plaintext locally on the node and is not transmitted to the outside.

[0013] The smart reconciliation contract module is deployed on the underlying consortium blockchain ledger module and includes an isolated collaborative comparison unit and a layered error handling unit.

[0014] The isolated collaborative comparison unit reads the field-level commitments of each party on the chain, uses the order number as the unified alignment key, does not retrieve any business plaintext, cross-compares the amount and status commitments of the merchant, the aggregate service provider, and the payment channel, and locates the error based on the data inconsistency.

[0015] The hierarchical error handling unit, integrated with the isolation and collaborative comparison unit, receives error judgment signals, outputs supplementary instructions or collaborative work orders according to the error type, and transmits all handling data back to the consortium blockchain ledger.

[0016] The traceability query service module receives query requests from merchants and regulators, reads on-chain commitments, and retrieves local data as needed to complete traceability verification. The traceability query service module has a built-in anti-tampering verification unit with two working modes: complete verification and commitment consistency.

[0017] Preferably, the key business fields include standardized amount and transaction status;

[0018] The per-order field-level commitment unit generates two types of HMAC message authentication codes—amount commitment and status commitment—based on the alliance shared key for each single order.

[0019] The daily key is negotiated and rotated daily by the merchant, the aggregate service provider, and the payment channel. The fund depository bank and the regulatory read-only node do not participate in the key negotiation and do not hold the daily key. The key rotation is performed with forward confidentiality. After the historical key is destroyed, the old commitment cannot be recalculated, but the validity of the on-chain timestamp is not affected.

[0020] The isolated collaborative comparison unit compares the two types of commitments separately, independently distinguishes between amount errors and status errors, and accurately locates the single business field of the order.

[0021] Preferably, the per-item field-level commitment unit uses the order number as the alignment key to organize all field-level commitments obtained from splitting the same bill into a Merkle tree, and submits the Merkle tree root, block height, timestamp, and bill metadata to the underlying consortium blockchain ledger module for on-chain storage. The Merkle path corresponding to each field-level commitment is stored in the off-chain private data storage module of the corresponding node.

[0022] The isolated collaborative comparison unit generates an error status vector representing the reconciliation status of a single order. The error status vector includes a merchant existence bit, a channel existence bit, a service provider existence bit, and a field consistency bit.

[0023] Preferably, the hierarchical error handling unit generates a replacement order instruction carrying a unique idempotent key combining the order number and the error discovery block height for clear errors. It maintains a handling state machine with multiple nodes in the process of pending handling, replacement in progress, replacement successful, replacement failed, manual review, and closure. Duplicate idempotent instructions will be intercepted by the contract. After the replacement order is completed, the receipt is sent to the chain to close the loop.

[0024] Preferably, the hierarchical error handling unit generates multi-party collaborative work orders with comparison records, error tags, and handling timers for fuzzy errors. The work order needs to be signed and confirmed by the node threshold before it is uploaded to the chain. If the preset number of signatures is not reached within the time limit, it will be automatically pushed to the supervisory read-only node. The entire handling log is synchronously stored and evidence is stored. Long and short items are classified as clear errors and handled automatically.

[0025] Preferably, the smart reconciliation contract integrates a near real-time incremental reconciliation unit. This unit listens for promised incremental on-chain events, dynamically initiates reconciliation, splits reconciliation shards by merchant and date, performs parallel operations through multiple contracts, configures incremental cursors for each shard, and can resume progress without full recalculation after a failure.

[0026] Preferably, the traceable query service module includes an anti-tampering verification unit, a merchant self-certification tool unit, and a regulatory read-only query unit;

[0027] The anti-tampering verification unit connects to the consortium blockchain ledger and the local storage of each node. In the full verification mode, it retrieves on-chain commitments and Merkel tree roots, requests off-chain Merkel paths from the relevant nodes, reconstructs and compares the local tree roots, and simultaneously retrieves the original bill to recalculate commitments to complete dual verification. In the commitment consistency verification mode, it only compares on-chain commitments from multiple parties and does not require retrieving the original bill.

[0028] Preferably, the consortium blockchain ledger stores field commitments and Merkel tree roots in shards according to merchant and date. The platform includes merchant light nodes, which only synchronize their own business shard data and do not need to synchronize the entire ledger.

[0029] Preferably, the off-chain private data storage uses AES-encrypted local bills, which can be decrypted by the local node holding the corresponding decryption private key;

[0030] The evidence storage Oracle module also includes a multi-source bill retrieval unit that connects to various payment channels and service provider APIs, automatically parses and cleans CSV and XML bills, and outputs them to the commitment unit.

[0031] Preferably, the off-chain private data storage module is equipped with a remote data integrity proof unit. After each accounting period ends, each node calculates the hash of all local bills, binds the merchant, date, node identifier, and attaches a timestamp to the blockchain for proof.

[0032] This invention provides a blockchain-based distributed payment reconciliation platform for micro and small merchants. It offers the following advantages:

[0033] 1. The blockchain-based distributed payment reconciliation platform for micro and small merchants of this invention relies on a daily negotiated and rotated consortium key to generate key message authentication codes for order amounts and transaction statuses, which are then stored on the blockchain. The original transaction data remains locally on each node and is never transmitted externally. On-chain reconciliation is completed solely using encrypted credentials, preventing third parties from reverse engineering the actual business transactions. This not only complies with data security regulations but also solves the problem of the incompatibility between privacy protection and verifiable accounting through a lightweight cryptographic mechanism.

[0034] 2. This platform uses a four-bit identifier to form an error status vector, which automatically distinguishes normal bills from various reconciliation errors based on different bit combinations. Orders with clear discrepancies can be automatically issued with a replacement order instruction carrying a unique idempotent identifier, effectively avoiding duplicate operations. Disagreements in accounts are automatically generated into multi-party collaborative work orders with set processing deadlines. If no agreement is reached within the deadline, regulatory intervention is automatically pushed. The entire error handling process is logged and recorded on the blockchain, adapting to the limited staffing of small and micro merchants.

[0035] 3. This platform employs two mechanisms: First, it constructs a Merkle tree for all fields in a single batch and locks the root on the blockchain, ensuring timely detection of any modification to individual transaction data. Second, at the end of each reconciliation cycle, each node calculates the hash value of all local invoices in sequence and stores it on the blockchain, using this as a time verification anchor to accurately identify invoice tampering after the snapshot is generated. These two mechanisms work together to ensure the trustworthiness of individual transactions while also achieving complete and traceable historical accounting throughout the entire cycle.

[0036] 4. The platform has two verification operation modes: the full verification mode integrates Merkel path verification and commitment value comparison, which is rigorous and can issue compliant reconciliation vouchers for use as evidence in transaction disputes; the commitment comparison mode only retrieves on-chain encrypted information to complete the verification, without reading the local original invoice, which has a fast response speed and is suitable for large-scale daily inspections by regulators. Attached Figure Description

[0037] Figure 1This is a schematic diagram of the overall layered architecture of the blockchain-based distributed payment reconciliation platform for micro and small merchants of this invention.

[0038] Figure 2 This is a complete flowchart of the blockchain-based distributed payment reconciliation platform for micro and small merchants, which generates field-level commitments for each transaction and aggregates Merkle trees onto the blockchain.

[0039] Figure 3 This is a schematic diagram illustrating the execution process of two verification modes of the traceability query service module of the blockchain distributed payment reconciliation platform for micro and small merchants described in this invention. Detailed Implementation

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

[0041] Example 1: Overall Structure of a Four-Party Consortium Blockchain Platform

[0042] refer to Figure 1 As shown, this invention provides a blockchain-based distributed payment reconciliation platform for micro and small merchants, comprising a consortium blockchain network consisting of merchant nodes, aggregated payment service provider nodes, third-party payment channel nodes, and fund custodian bank nodes. Each node is deployed on its own local server and configured with a corresponding local off-chain billing storage area. The specific implementation methods for each node are described below.

[0043] The network in this embodiment includes four types of consensus nodes: merchant nodes, aggregated payment service provider nodes, third-party payment channel nodes, and fund custody bank nodes, as well as non-consensus nodes such as regulatory read-only nodes. The node composition is synchronized with the ledger. The network in this embodiment is a permissioned consortium blockchain based on PBFT (Practical Byzantine Fault Tolerance Protocol), which only allows nodes holding consortium CA digital certificates to access. The PBFT practical Byzantine fault-tolerance consensus protocol only allows three types of business nodes holding consortium CA certificates—merchants, aggregated service providers, and payment channels—to participate in the ledger consensus. Banks and regulatory read-only nodes will not participate in consensus voting.

[0044] Merchant nodes only synchronize all shards corresponding to their own merchant identifier, without needing to synchronize the complete consortium blockchain ledger data; aggregated payment service provider nodes and third-party payment channel nodes synchronize the entire ledger; fund custody bank nodes synchronize the entire ledger but do not perform any operations on the ledger. Regulatory read-only nodes synchronize the entire ledger, and all their access operations are marked as read-only, with the access control list layer and smart contract layer jointly rejecting any write operations. Merchant light nodes have the same synchronization scope as merchant nodes, only performing query functions and not participating in network consensus computation.

[0045] Furthermore, regarding off-chain billing storage, each node has its own local raw billing storage area (i.e., Figure 1 The off-chain private data storage module in this invention can employ a local file system with AES-256-GCM (Advanced Encryption Standard 256-bit Galois / Counter Mode) symmetric encryption, or it can be a distributed storage system built on a private IPFS (InterPlanetary File System) cluster. The corresponding encryption private key is generated and persisted in a hardware secure carrier by the HSM (Hardware Cryptographic Machine) or TEE (Trusted Execution Environment, such as Intel SGX, ARM TrustZone, etc.) of each node. Application layer software cannot export the plaintext private key; that is, only the node holding the decryption private key can decrypt and read the original local ledger. This allows the off-chain local storage space of this invention to work with the underlying consortium blockchain ledger to achieve the dual effect of ledger notarization and original data remaining only on the local node.

[0046] Furthermore, regarding the cryptographic infrastructure, this invention employs HMAC-SHA256 (Hash Message Authentication Code based on SHA256) as the core cryptographic tool for field-level commitments. The input to the HMAC-SHA256 algorithm consists of two core parts: first, a byte string combining the order number and business fields from the original invoice; and second, a shared working key for the day, jointly negotiated by the merchant node, the aggregated payment service provider node, and the third-party payment channel node. This working key is negotiated through three rounds of the Diffie-Hellman key negotiation protocol, and the key material is processed using the HKDF-SHA256 (key derivation function based on HMAC-SHA256) key derivation function to ultimately generate a 256-bit shared session key for the day. .

[0047] In practical applications, in addition to AES-256-GCM, the SM4 national cryptographic symmetric encryption algorithm can also be used to store local bills during the implementation phase. In addition to SHA256, the hash operation can also be replaced by the national cryptographic SM3 hash algorithm to adapt to domestic financial regulatory requirements.

[0048] After the tripartite negotiation is completed, the fund custody bank node and the regulatory read-only node do not participate in the key negotiation process, nor do they hold the key for that day. At midnight Beijing time every day, the three parties jointly destroy the working key of the previous day. The three copies of the key are sequentially overwritten and erased in the storage area. The destruction operation is considered complete only after all three copies are successfully erased. At the same time, after the destruction is completed, the historical commitments corresponding to the old key cannot be re-verified and calculated, but the timestamps attached to the commitments that have been stored on the blockchain have the evidentiary effect and will not change with the destruction.

[0049] Through the cooperation of the above system modules, the four-party consortium blockchain architecture provided in this embodiment has the following technical effects: On the one hand, the original billing data is always stored locally off-chain on each node, and plaintext is never transmitted on the chain. The original billing data of each node is isolated from each other and cannot be directly retrieved across nodes. This fundamentally avoids the risk of unauthorized access to specific monetary data in the operation of micro and small merchants. On the other hand, the fund custody bank and the regulatory read-only node do not participate in the key negotiation on the same day. This makes it impossible to decrypt and read the billing commitment, fundamentally avoiding the compliance risks of regulatory agencies retrieving the plaintext of merchant transactions with the key. Finally, the merchant's light node only synchronizes its own business shard ledger, which greatly reduces the storage overhead and ledger synchronization bandwidth overhead of the micro and small merchant client.

[0050] Example 2: Generation and Merkel-based On-chain Process of Transaction-by-Transaction Field-Level Commitments

[0051] refer to Figure 2 As shown, this embodiment details the complete execution process of a single transaction order, from multi-source invoice retrieval, standardized cleaning, and field-level privacy commitment calculation, to Merkle tree aggregation and final on-chain notarization. This embodiment employs a dual-field independent HMAC-SHA256 commitment mechanism for transaction amount and transaction status to achieve off-chain retention of plaintext data and on-chain notarization of verification digests. Simultaneously, it accurately isolates amount and status errors, solving the technical problems of data leakage and coarse error localization in traditional centralized reconciliation systems.

[0052] Every day at 11:30 PM Beijing time (preferably 11:30 PM in this embodiment, but can be flexibly adjusted according to actual circumstances in practical applications), the Oracle module of the evidence storage gateway starts batch data collection and parsing. Specifically, the module connects to third-party payment channels through an HTTPS secure interface, then pulls official reconciliation CSV format billing files from WeChat, Alipay, etc., and simultaneously connects to aggregated payment service providers through a RESTful interface (a mainstream front-end and back-end interaction interface design specification used for standardized data communication calls between platform nodes and between clients and consortium blockchain gateways) to obtain aggregated billing data in XML format. After all the original billing files are stored locally on each node, they are uniformly encrypted and saved using the AES-256-GCM algorithm, achieving off-chain private retention of the original transaction plaintext.

[0053] To avoid invalid data, duplicate data, and floating-point calculation errors, the system cleans the original invoices. This removes invalid states, duplicate transactions, fake refund marks, and other abnormal transactions. It also removes timestamp records that are outside the current reconciliation period. Then, all transaction amounts are converted into integer values ​​in cents instead of using floating-point numbers for storage and calculation. This solves the precision distortion problem inherent in binary floating-point numbers, thus preventing small discrepancies in reconciliation. Finally, the system uses globally unique order numbers to deduplicate the data and outputs a standardized invoice dataset that is suitable for cryptographic calculations.

[0054] To ensure that the commitment values ​​calculated by the merchant node, the aggregation service provider node, and the payment channel node for the same order are completely consistent, all business fields involved in the hash operation must be preprocessed into fixed-length, fixed-type, and unambiguous standard byte strings. The specific standardization rules are as follows:

[0055] 1) Order ID field: UTF-8 encoding is used, leading and trailing whitespace characters are removed, and if the length is less than 32 bytes, 0x00 zero bytes are added to the left to make it 32 bytes. If it exceeds 32 bytes, it is first compressed into a 32-byte fixed-length digest by SHA-256 operation to ensure the uniformity of the global length.

[0056] 2) Amount field: Convert to positive integers in cents, then format as a 12-digit fixed-length decimal string (padded with 0s at the highest digits), and configure a dedicated fixed single-byte tag. =0xA1 is used for field isolation to prevent obfuscation.

[0057] 3) Status field: Maps text statuses such as "Payment Successful," "Pending Payment," "Refund," and "Transaction Failed" to single-byte numeric codes using predefined enumeration rules, and configures dedicated fixed single-byte labels. =0xA2, independently distinguishing the operation space of the status field.

[0058] This invention targets the two core dimensions of a single order: amount and transaction status. It employs independent key hashing to generate immutable and irreversible field-level commitment values. The two sets of formulas are processed in parallel with completely isolated inputs, eliminating field comparison confusion at the underlying level. The specific calculation formula for the field commitment in this invention is as follows:

[0059] It should be noted that before performing the commitment calculation, the order number, amount, and status fields are first standardized into fixed-length, fixed-type byte strings according to predetermined rules, and then concatenated according to the formula.

[0060]

[0061]

[0062] Among them, in the formula This represents the byte string concatenation operator;

[0063] The meanings of the parameters in the other formulas are as follows:

[0064] : Encrypted commitment value for the order amount field;

[0065] : Encrypted commitment value for the order transaction status field;

[0066] Merchant nodes, aggregated payment service provider nodes, and third-party payment channel nodes negotiate daily using the Elliptic Curve Diffie-Hellman Key Exchange Protocol (ECDH) to generate the consortium shared key for that day. Banks and regulatory nodes do not have access to this protocol. Specifically, each node generates a temporary public-private key pair (using the secp256r1 curve). Each node broadcasts its public key to the consortium blockchain ledger module. Other nodes read this public key and combine it with their own private key to calculate the shared key seed, then derive the consortium shared key for that day using HKDF. ;

[0067] : A standardized 32-byte fixed-length order number string;

[0068] Amount fields have their own fixed-byte tags;

[0069] : A fixed-byte label specific to the transaction status field;

[0070] : A 12-digit fixed-length standardized monetary string;

[0071] : Single-byte transaction status code.

[0072] The representative performs HMAC-SHA256 key hashing using the shared key of the day, and finally outputs a fixed 32-byte hash digest.

[0073] To prevent interference between amount and transaction status data during hash operations, the solution assigns dedicated identifier bytes to each type of field, thereby isolating their input structures and completely decoupling the calculation processes for amount and status commitments. Based on this design, subsequent cross-reconciliation can identify amount-related errors and status-related errors separately, directly pinpointing the corresponding fields that caused the accounting discrepancies, resulting in finer-grained error localization.

[0074] To illustrate the calculation process intuitively, this example uses a sample transaction order: Merchant M2025xxxx generates a WeChat Pay order, order number ON20260723001234, transaction amount 128.50 yuan, and transaction status "payment successful". The entire process is calculated according to the standardized rules and formulas described above:

[0075] Step S1: Field standardization processing: The order number is encoded in UTF-8 and padded with zeros to form a 32-byte fixed-length string; the amount of 128.50 yuan is converted to 12850 fen and formatted as a 12-digit fixed-length string "000000012850"; the payment success status is mapped to a single-byte encoding 0x01.

[0076] Step S2, message byte string concatenation: The amount calculation message is composed of the standardized order byte string, the tag 0xA1, and the 12-bit amount string concatenated in sequence; the status calculation message is composed of the standardized order byte string, the tag 0xA2, and the status code 0x01 concatenated in sequence.

[0077] Step S3, Commitment Value Generation: Using the negotiated key of the day. Perform HMAC-SHA256 operations on the two sets of messages respectively to obtain a 32-byte monetary commitment value. With 32-byte state commitment value This constitutes the complete field-level commitment pair for this order.

[0078] Step S4, Merkel leaf node construction: Construct the order's leaf nodes. and After sequential concatenation, the bottom-level leaf nodes of the Merkle tree are obtained through SHA-256 hashing. ,Right now = SHA256( || ).

[0079] Repeat the above standardization and calculation process for all orders in the same payment period to obtain N leaf nodes, and then construct a binary Merkle tree. The specific construction rules are as follows:

[0080] After completing the dual-field commitment calculation for a single order, the commitment pairs of all orders within the same reconciliation period are aggregated to construct a binary Merkle tree for batch storage and compression.

[0081] (a) Formula for constructing leaf nodes:

[0082] = SHA256( || )

[0083] in The hash value of the underlying leaf node. and These are the amount commitment value and status commitment value for the same order, respectively.

[0084] (ii) Recursive formula for parent node:

[0085]

[0086] in Let be the hash value of the parent node at level i. and It is the hash value of its next-next adjacent child nodes.

[0087] (III) Root node formula:

[0088]

[0089] During the construction process, if the number of nodes in a certain layer is odd, the last node is automatically copied to complete the pairing, ensuring that the number of nodes in each layer is even, and finally iteratively converges to generate a unique top-level Merkle root.

[0090] This invention adopts a layered evidence storage strategy of on-chain root and off-chain path: the final generated Merkel root, block height, UTC timestamp, and bill metadata are packaged and on-chained, and written into the consortium blockchain ledger for permanent evidence storage, making it tamper-proof and traceable; while the Merkel verification path corresponding to each order is only encrypted and stored in the local private storage module of each node, and will not participate in on-chain synchronization and transmission.

[0091] The above mechanism can greatly reduce the on-chain storage pressure and node synchronization overhead of the consortium blockchain, and adapt to the lightweight deployment needs of small and micro merchants' light nodes. Merchant light nodes only need to synchronize the sharded ledger corresponding to their own business, without synchronizing the full on-chain data.

[0092] Through the above-described process of generating and Merkel-based on-chain commitments at the field level, this embodiment has the following technical advantages: First, the original plaintext of the transaction is stored locally on the node throughout the entire process, and only the encrypted digest is uploaded to the chain, eliminating the risk of leakage of merchant business data from the transmission and storage layers, and meeting the requirements of data compliance supervision; Second, the independent commitment calculation of the amount and status fields enables error location to be accurate down to a single business field, abandoning the inefficient mode of traditional whole-order reconciliation and batch review, and greatly improving the accuracy and efficiency of reconciliation; Third, the Merkel tree aggregation compression mechanism enables lightweight on-chain storage of massive transaction flows, the system has strong scalability, and can be adapted to business scenarios with different transaction throughputs of micro and small merchants.

[0093] Example 3: Collaborative Reconciliation and Handling under Multiple Error Types

[0094] Reference Appendix Figure 3As shown, this embodiment describes in detail the specific implementation of layered processing for various error types that the smart reconciliation contract module may identify during the reconciliation process.

[0095] The core execution unit for error localization is the isolated collaborative comparison unit. This unit reads the field-level commitments stored on-chain by each party's node from the consortium blockchain ledger, using the order number as the globally unified alignment primary key. Without obtaining the original plaintext of any node's bill, it sequentially performs three-way cross-comparison. For each order, the system verifies whether the amount commitments of the merchant, third-party payment channel, and aggregated payment service provider are consistent, and whether the transaction status commitments of the three parties are consistent. If both types of commitments match, the order is determined to be reconciled correctly; if there are discrepancies in the commitments, an error status vector is generated based on the dimension of the discrepancy and the subject involved in the error.

[0096] The error state vector consists of 4 bits, and the definition of each bit is shown in the table below:

[0097] Table 1. Definition of Bits in Error State Vector

[0098] Bit sequence number Bit identifier name The meaning of a bit value of 1 The meaning of a bit value of 0 Bit0 Merchants exist The merchant node has uploaded the order field commitment. The merchant has no record of this transaction. Bit1 Channel Existence The third-party payment channel node has uploaded the order commitment. The payment channel did not have a record of this transaction. Bit2 Service Provider Existence The payment aggregation service provider node has uploaded the order commitment. The aggregation service provider does not have the transaction record for this transaction. Bit3 Field consistency bit The amount and status of the two sets of commitments are completely consistent among the three parties. At least one of the tripartite commitments regarding monetary amount or status is inconsistent.

[0099] Based on different bit combinations of this vector, the system can automatically distinguish all reconciliation scenarios, including reconciliation matching, order loss, overpayment / underpayment, amount error, and status error.

[0100] Error state vectors identify clearly defined and quantifiable errors, categorizing them as explicit errors. Overpayment errors, underpayment errors, and one-sided order drops all fall into this category. The hierarchical error handling unit automatically generates and issues a replacement order instruction carrying a globally unique idempotent key. The idempotent key is generated by combining the order number with the error discovery block height. Regardless of how many times the replacement order instruction corresponding to the same idempotent key is triggered, the smart reconciliation contract can identify and refuse repeated execution, thus significantly avoiding inconsistencies in fund accounts caused by duplicate replacement orders. Furthermore, after the aggregated payment service provider completes the replacement order operation, it uploads the replacement order receipt to the underlying consortium blockchain ledger for evidence storage, thus completing the closed-loop flow of the handling state machine. The overall state machine flow nodes are as follows: pending handling, replacement in progress, replacement successful / failed, manual review, and finally, closure.

[0101] In the above verification, if the three parties' commitments are inconsistent and the responsibility for the error cannot be automatically determined, the scenario is classified as an ambiguous error. The system will automatically generate a multi-party collaborative work order. This work order will simultaneously include the three parties' commitment comparison record, the error type label, and a processing time limit timer. Furthermore, the processing result requires the relevant business nodes to complete threshold signature confirmation (in this embodiment, the default threshold is 2 signatures; any two signatures from the three parties are sufficient for the result to be effective, and the threshold signature uses the ECDSA threshold signature algorithm based on elliptic curves, with a preset threshold of 2. In actual applications, the threshold signature threshold can be flexibly configured according to the number of alliance nodes). After the signature confirmation, the confirmation result will be simultaneously uploaded to the blockchain for storage. If the required threshold signatures are not collected by the processing time limit, the work order will be automatically escalated and pushed to a regulatory read-only node for intervention and supervision. The entire process processing log will be uploaded to the blockchain for evidence storage in real time.

[0102] The overall handling rules for the two types of errors are summarized as follows:

[0103] Table 2. Comparison Table of Graded Handling of Reconciliation Errors

[0104] Error Classification Includes error scenarios Specific handling methods Clearly identify the error Long style, short style, single-sided order drop Smart contracts automatically issue idempotent order completion commands, achieving fully automated closed-loop processing through state machines, requiring no manual intervention throughout the entire process. Fuzzy error Disagreements among the three parties regarding transaction details, missing partial transaction data, and inability to automatically define responsibilities. Generate a multi-party collaborative handling work order and set a handling time limit; if the parties fail to reach a consensus within the time limit, the order will be automatically pushed to the regulatory node for supervision.

[0105] In summary, through the above reconciliation and error handling processes, this embodiment achieves the following technical effects at the intelligent reconciliation contract module level: Clear errors rely on an idempotent key deduplication mechanism to eliminate duplicate order issues; error self-healing is fully automated, adapting to the operational reality of staff shortages in micro and small businesses; ambiguous errors rely on work order time limit control and threshold signature mechanisms to achieve cross-organizational collaborative accountability; overdue errors are automatically reported to regulators, balancing business self-healing capabilities with regulatory oversight capabilities; thirdly, all handling node switching records, receipts, and work order logs are stored on the blockchain, ensuring the entire error handling process is traceable and tamper-proof. If the platform connects to the fund custody bank node with synchronized field commitments, the bank node can participate in ledger verification as a fourth-party witness, and the reconciliation determination is still completed by the three-party nodes through cross-comparison.

[0106] Example 4: Implementation of Dual-Mode Query Validation

[0107] refer to Figure 2 and Figure 3 As shown in the figure, this embodiment focuses on the traceability query service module and explains the specific implementation of the two working modes provided by its internal anti-tampering verification unit.

[0108] The complete verification mode is suitable for scenarios such as evidence collection in single-transaction disputes and compliance tracing. In this mode, after receiving a query request from a merchant or regulator, the traceability query service module first reads the on-chain field commitment value and the root hash value of the Merkle tree of the order from the consortium blockchain ledger module. Then, the query service module initiates off-chain shard path retrieval requests to the merchant nodes, aggregated payment service provider nodes, and third-party payment channel nodes involved in the order. The request only carries the triplet information of order number, merchant identifier, and transaction date. Each node retrieves the Merkle path of the order from the corresponding position in its off-chain private storage space according to the request and sends it back to the query service module. The query service module jointly reconstructs the collected three-party Merkle paths to calculate the local Merkle tree root. Finally, by comparing the local Merkle tree root with the on-chain Merkle tree root, it can preliminarily determine whether the on-chain data has been tampered with.

[0109] Based on this, the key holder, using the shared key held for the day, recalculates the amount commitment value and status commitment value of the original order plaintext and performs a second comparison with the on-chain commitment value. The specific calculation method for recalculating the amount commitment value and status commitment value is as described in Example 2 above, using the shared key for the day. The standardized order number byte string, amount tag byte, and standardized amount value (or status code byte) are concatenated in sequence and then processed by HMAC-SHA256. If both comparisons pass, the transaction is deemed to have been successfully verified; if either comparison fails, the specific error type and error subject are located based on the failed commitment dimension and the corresponding subject.

[0110] The commitment consistency verification mode is suitable for scenarios such as high-frequency regulatory inspections and batch compliance audits. In this mode, after the traceable query service module receives a query request from the regulatory read-only node, it only needs to read the field-level commitments and sharded evidence records stored on the consortium blockchain ledger module, and perform batch cross-comparison of the commitments of the multiple parties involved by order number for massive order data.

[0111] Specifically, for each order, the system compares whether the monetary commitments of the three nodes are completely equal, and also compares whether the status commitments are completely equal. This process requires neither collecting any off-chain private Merkel paths nor retrieving the original plaintext of any node's invoice. In scenarios involving massive order commitment comparisons, regulatory batch inspections can complete the consistency verification of commitments for hundreds of thousands or even more orders within tens of minutes.

[0112] The traceability query service module is designed with two independent verification processes, which are adapted to two scenarios: dispute evidence collection and batch regulatory audit, respectively, each with its own unique advantages.

[0113] For single-transaction dispute evidence collection scenarios, the complete verification mode adopts dual verification logic to realize off-chain data reverse verification, which can accurately locate the erroneous business fields in abnormal orders and form complete and credible evidence materials. The dual verification consists of two steps: Merkle root integrity verification and commitment value recalculation comparison based on shared key. The superposition of dual verification can fully verify that the transaction data has not been tampered with.

[0114] This commitment consistency verification model, designed for batch regulatory inspections, relies solely on on-chain encrypted digests for reconciliation, without accessing the original, locally encrypted transaction records on each node. In contrast to traditional auditing methods, where regulators previously had to retrieve complete transaction details from merchants, easily exceeding their legal authority and excessively collecting sensitive information about merchant operations, this solution eliminates the compliance risks of unauthorized access to merchant privacy by relying solely on on-chain encrypted digests.

[0115] Example 5: Implementation of Near Real-Time Incremental Reconciliation Sharding

[0116] This embodiment supplements the specific implementation of the near real-time incremental reconciliation unit integrated into the smart reconciliation contract module. This unit monitors the incremental commitment on-chain events reported by the evidence storage gateway Oracle module to the consortium blockchain ledger module in real time, and adaptively adjusts the reconciliation batch processing level according to the real-time throughput of the current transaction flow, dynamically initiating reconciliation tasks.

[0117] Specifically, this unit segments the overall reconciliation task according to merchant identification and transaction date, and executes the segmented reconciliation work in parallel through multiple contract instances. During the parallel operation, each contract instance is configured with an incremental cursor to record the reconciliation progress. After a node fails and recovers, it can continue the previous round of reconciliation based on the cursor, thus avoiding the need to repeat the reconciliation from the beginning and greatly saving manpower.

[0118] Example 6: Implementation of Off-Chain Storage and Data Integrity

[0119] This embodiment illustrates the specific implementation of the off-chain private storage space and the remote proof unit for data integrity.

[0120] Regarding the encrypted storage of off-chain invoices: As described in the preceding embodiments, the node's local private storage space uses AES-256-GCM symmetric encryption to store the original plaintext invoice files. The corresponding encryption private key is generated and persisted in the hardware security carrier by each node's HSM (Hardware Security Module, an independent tamper-proof encryption hardware device used for secure key generation and persistent storage) or TEE (Trusted Execution Environment, a secure computing area isolated by CPU hardware; representative solutions include Intel SGX and ARM TrustZone). The application layer calls the encryption interface to complete transparent encryption and decryption operations; the decryption private key is not stored in plaintext form in the file system. Nodes are isolated from each other through network access control policies; both logically and physically, direct cross-node access to each other's local private invoice data is prohibited.

[0121] At the end of each reconciliation cycle, the remote data integrity proof unit (RAP) independently calculates the SHA-256 hash digest value for all original billing files in its local storage. The hash value, timestamp, and node identifier are then packaged and uploaded to the blockchain via the Oracle module of the proof gateway for proof storage. The specific execution time is 00:30 Beijing time every day. After the nodes complete the local billing integrity hash calculation in batches, they will uniformly submit it to the underlying consortium blockchain ledger.

[0122] Through the above implementation methods, the off-chain storage and data integrity mechanism provided by this invention has the following technical effects: The AES-256-GCM high-strength encryption scheme ensures that even if the billing file is leaked and copied, it cannot be decrypted and read without the hardware private key. The overall hash of periodic bills is stored on the chain, and third parties can verify the integrity of the local bills on the node at any time. This process will not leak any plaintext transactions. This mechanism, combined with the aforementioned field commitments and key privacy system, completes the overall construction of a compliance protection system for the business data of micro and small merchants that ensures "plaintext is not entered into the chain, plaintext is not leaked, and the entire chain is traceable".

[0123] In summary, this invention can be widely applied to real-time reconciliation scenarios for aggregated payment transactions targeting micro and small merchants, especially for batch settlement scenarios of micro and small merchants that access multiple third-party payment channels (including WeChat, Alipay, UnionPay, and various local aggregated payment service providers).

[0124] Example 7: Complete Business Application Scenario of a Payment Reconciliation Platform for Micro and Small Merchants

[0125] This embodiment takes a small and micro-sized merchant that accesses multiple third-party payment channels as an example to illustrate in detail the complete application process of the blockchain distributed payment reconciliation platform provided by this invention in a real business scenario.

[0126] A small business simultaneously uses both WeChat Pay and Alipay, two major payment channels, generating a total of 500 transactions in a single day (approximately the average daily transaction volume, consistent with typical business scenarios for small businesses), including 300 transactions via WeChat Pay and 200 via Alipay. Using traditional reconciliation methods, this merchant would need to log into the WeChat Pay merchant platform and the Alipay merchant center respectively after the end of each business day to download reconciliation statement files, and then manually verify that the two sets of statements match the records in the merchant's own POS system.

[0127] After connecting to this platform, the four parties—merchants, payment aggregators, WeChat channels, and Alipay channels—form a consortium blockchain network. Merchant nodes are deployed locally and are responsible for calculating their own order field commitments. Payment aggregators' cloud nodes aggregate transaction data from multiple merchants and handle order replenishment operations. The two types of payment channel nodes are deployed in the channel's data center and synchronize their own transaction records. All nodes independently deploy off-chain encrypted private storage and synchronize encrypted digests through the consortium blockchain ledger.

[0128] Merchant nodes, aggregated payment service provider nodes, and WeChat and Alipay payment channel nodes negotiate and generate the alliance shared key at midnight Beijing time every day. The fund custody bank node and the regulatory read-only node do not participate in the key negotiation process, do not hold the session key, and the key is valid for 24 hours. It will be destroyed and a new key will be renegotiated at midnight the next day. During daily operations, each merchant node calculates the committed value of an order amount in real time for every transaction that occurs. With state commitment value The calculation method is as described in Example 2.

[0129] Taking a successful WeChat payment order with order number ON20260724000123 and amount of 88.50 yuan as an example, after processing according to the field standardization rules described in Example 2, the system uniformly converts the amount into an integer in cents, and generates two independent commitments by combining the order number and the exclusive field tag byte. The two are concatenated and hashed to obtain the Merkel leaf node. The merchant, channel and aggregation service provider independently execute the same calculation process.

[0130] After all 500 orders for the day have completed their field commitment calculations, all leaf nodes are hashed layer by layer according to the rules of a complete binary Merkle tree. If the number of nodes is less than an even number, they are automatically paired to generate a unique Merkle tree root for the day. The root, block height, timestamp, and bill metadata are then packaged together and permanently stored on the blockchain. At 23:30 Beijing time every day, the Oracle module of the evidence storage gateway automatically pulls and cleans the original bills from all channels and starts uploading the commitments to the blockchain. The smart reconciliation contract continuously monitors incremental evidence storage events and automatically starts three-party cross-reconciliation after all commitments from the three-party nodes have been uploaded for the day.

[0131] During the reconciliation phase, a globally unified order identifier is used as the alignment primary key. The contract only reads the on-chain encrypted commitments and does not retrieve any node's original plaintext to complete the three-way cross-comparison. The system verifies two sets of data: the amount and the status commitments of the three parties. If the three parties' values ​​match perfectly, the reconciliation is correct; if the three parties' commitment values ​​differ, the accounting discrepancy is determined.

[0132] If the order coding rules of merchants and channels are not consistent, the aggregation service provider node will pre-establish a mapping relationship between merchant order numbers and channel order numbers on the blockchain, and complete the transaction alignment with a unified global identifier during reconciliation.

[0133] Taking order ON20260724000456 as an example, after verification by the isolated collaborative comparison unit, all three nodes have corresponding transaction records, but the promised amount does not match. The error state vector Bit0, Bit1, and Bit2 are all 1, and Bit3 is 0. Based on the three-bit definition in the embodiment, it can be determined to be a clear error of the amount. For this type of error, automatic handling is possible. The hierarchical error handling unit generates a globally unique idempotent order replacement instruction carrying "order number + error block height". The contract automatically intercepts duplicate requests. After the aggregation service provider completes the order replacement, it will upload the receipt to the chain. The entire handling follows the state machine flow of pending handling, order replacement in progress, order replacement success / order replacement failure, manual review, and closure.

[0134] If the responsibilities cannot be automatically divided after comparison, a multi-party collaborative work order with a handling time limit is generated. The work order is accompanied by a complete comparison record and error label. The work order conclusion needs to be confirmed by the business node through ECDSA threshold signature. In this embodiment, the signature threshold is set to 2 (system preset parameter, which can be configured and adjusted). Signatures from any two of the three parties are sufficient to close the loop. If no valid signatures are collected within the time limit, the work order will be automatically pushed to the supervisory read-only node for supervision. All handling logs are uploaded to the blockchain in real time and cannot be tampered with.

[0135] After implementation, the merchant's complete reconciliation time has been reduced from the traditional 2 hours to less than 10 minutes. Various accounting errors can be automatically identified by the contract. Clear errors are automatically corrected without manual intervention. Disagreements are resolved through online collaborative work orders. The original bills are stored locally at each node, and cross-chain transmission uses only encrypted digests. Merchants' business privacy will not be leaked, and reconciliation records are permanently stored and have compliant evidentiary value.

[0136] The entire four-party alliance reconciliation architecture can uniformly process merchant transactions from multiple channels. The field-level commitment mechanism takes into account both privacy protection and accurate error location. The smart contract automatic reconciliation greatly reduces the manpower input of small and micro merchants. Error handling is traceable throughout the entire chain, and the overall compliance and accounting efficiency are significantly improved.

[0137] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Any simple modifications or equivalent changes made to the above embodiments based on the technical essence of the present invention shall fall within the protection scope of the present invention.

Claims

1. A blockchain-based distributed payment reconciliation platform for micro and small merchants, comprising a four-party consortium blockchain architecture consisting of merchant nodes, aggregated payment service provider nodes, third-party payment channel nodes, and fund custody bank nodes. The platform includes an underlying consortium blockchain ledger module and an off-chain private data storage module. The off-chain private data storage module is deployed locally on each node, and each node independently stores the original plaintext file of its own business transaction. Data from each party is isolated and cannot be directly accessed across nodes. Its key features are: The platform also includes an evidence storage gateway Oracle module, a smart reconciliation contract module, and a traceable query service module, all of which are deployed within a four-party consortium blockchain architecture. The field-level commitment unit located inside the Oracle module of the evidence storage gateway establishes data interaction with the local private storage and the consortium blockchain ledger, retrieves the encrypted original bill, generates field-level commitments based on the order flow calculation, and only pushes the order index and commitments to the chain. The original bill is stored in plaintext locally on the node and is not transmitted to the outside. The smart reconciliation contract module is deployed on the underlying consortium blockchain ledger module and includes an isolated collaborative comparison unit and a layered error handling unit. The isolated collaborative comparison unit reads the field-level commitments of each party on the chain, uses the order number as the unified alignment key, does not retrieve any business plaintext, cross-compares the amount and status commitments of the merchant, the aggregate service provider, and the payment channel, and locates the error based on the data inconsistency. The hierarchical error handling unit, integrated with the isolation and collaborative comparison unit, receives error judgment signals, outputs supplementary instructions or collaborative work orders according to the error type, and transmits all handling data back to the consortium blockchain ledger. The traceability query service module receives query requests from merchants and regulators, reads on-chain commitments, and retrieves local data as needed to complete traceability verification. The traceability query service module has a built-in anti-tampering verification unit with two working modes: complete verification and commitment consistency.

2. The blockchain-based distributed payment reconciliation platform for micro and small merchants according to claim 1, characterized in that: The key business fields include standardized amount and transaction status; The per-order field-level commitment unit generates two types of HMAC message authentication codes—amount commitment and status commitment—based on the alliance shared key for each single order. The daily key is negotiated and rotated daily by the merchant, the aggregate service provider, and the payment channel. The fund depository bank and the regulatory read-only node do not participate in the key negotiation and do not hold the daily key. The key rotation is performed with forward confidentiality. After the historical key is destroyed, the old commitment cannot be recalculated, but the validity of the on-chain timestamp is not affected. The isolated collaborative comparison unit compares the two types of commitments separately, independently distinguishes between amount errors and status errors, and accurately locates the single business field of the order.

3. A blockchain-based distributed payment reconciliation platform for micro and small merchants according to claim 2, characterized in that: The per-item field-level commitment unit uses the order number as the alignment key to organize all field-level commitments obtained from splitting the same bill into a Merkle tree. The Merkle tree root, block height, timestamp, and bill metadata are submitted to the underlying consortium blockchain ledger module for on-chain storage. The Merkle path corresponding to each field-level commitment is stored in the off-chain private data storage module of the corresponding node. The isolated collaborative comparison unit generates an error status vector representing the reconciliation status of a single order. The error status vector includes a merchant existence bit, a channel existence bit, a service provider existence bit, and a field consistency bit.

4. The blockchain-based distributed payment reconciliation platform for micro and small merchants according to claim 1, characterized in that: The hierarchical error handling unit generates a replacement order instruction for clear errors, carrying a unique idempotent key that combines the order number and the height of the error discovery block. It maintains a handling state machine with multiple nodes in the process of pending handling, replacement in progress, replacement successful, replacement failed, manual review, and closure. Duplicate idempotent instructions will be intercepted by the contract. After the replacement order is completed, a receipt is sent to the chain to close the loop.

5. A blockchain-based distributed payment reconciliation platform for micro and small merchants according to claim 3, characterized in that: The hierarchical error handling unit generates multi-party collaborative work orders with comparison records, error tags, and handling timers for fuzzy errors. The work order needs to be signed and confirmed by the node threshold before it is uploaded to the blockchain. If the preset number of signatures is not reached within the time limit, it will be automatically pushed to the supervisory read-only node. The entire handling log is synchronously stored and evidenced. Overages and underages are classified as clear errors and handled automatically.

6. A blockchain-based distributed payment reconciliation platform for micro and small merchants according to claim 4, characterized in that: The smart reconciliation contract integrates a near real-time incremental reconciliation unit. This unit listens for promised incremental on-chain events, dynamically initiates reconciliation, splits reconciliation shards by merchant and date, performs parallel operations through multiple contracts, configures incremental cursors for each shard, and can resume progress without full recalculation after a failure.

7. A blockchain-based distributed payment reconciliation platform for micro and small merchants according to claim 1 or 3, characterized in that: The traceability query service module includes an anti-tampering verification unit, a merchant self-certification tool unit, and a regulatory read-only query unit. The anti-tampering verification unit connects to the consortium blockchain ledger and the local storage of each node. In the full verification mode, it retrieves on-chain commitments and Merkel tree roots, requests off-chain Merkel paths from the relevant nodes, reconstructs and compares the local tree roots, and simultaneously retrieves the original bill to recalculate commitments to complete dual verification. In the commitment consistency verification mode, it only compares on-chain commitments from multiple parties and does not require retrieving the original bill.

8. A blockchain-based distributed payment reconciliation platform for micro and small merchants according to claim 3, characterized in that: The consortium blockchain ledger stores field commitments and Merkel tree roots in shards based on merchants and dates. The platform includes merchant light nodes, which only synchronize their own business shard data and do not need to synchronize the entire ledger.

9. A blockchain-based distributed payment reconciliation platform for micro and small merchants according to claim 1, characterized in that: The off-chain private data storage uses AES to encrypt local bills, which can be decrypted by the local node holding the corresponding decryption private key; The evidence storage Oracle module also includes a multi-source bill retrieval unit that connects to various payment channels and service provider APIs, automatically parses and cleans CSV and XML bills, and outputs them to the commitment unit.

10. A blockchain-based distributed payment reconciliation platform for micro and small merchants according to claim 1, characterized in that: The off-chain private data storage module is equipped with a remote data integrity proof unit. After each accounting period ends, each node calculates the hash of all local bills, binds the merchant, date, node identifier, and attaches a timestamp to the blockchain for proof.

Images