A distributed transaction consistency guarantee method, device, equipment and medium
By automating the processing of reconciliation data from multiple channels, the problem of inconsistent transaction status in distributed payment systems has been solved, ensuring fund consistency and creating a closed loop for error handling, thereby improving reconciliation efficiency and accuracy.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- HENAN HONGYOU TECHNOLOGY CO LTD
- Filing Date
- 2026-04-22
- Publication Date
- 2026-06-26
AI Technical Summary
In distributed payment systems, factors such as network latency, lost callbacks, and system anomalies can lead to inconsistencies in transaction status between different payment channels and the core system, resulting in fund consistency issues. Existing technologies rely on manual reconciliation methods, which are inefficient, prone to omissions, and lack standardized processes.
By pulling reconciliation data from multiple channels at preset cycles, channel adapters are used to standardize heterogeneous data into a unified structure, and the data is automatically matched with internal transaction records. This process identifies overages, shortages, or abnormal statuses, triggers automatic processing operations, and records the processing status until the loop is closed.
It shortens the reconciliation cycle, reduces labor costs and the risk of omissions, ensures the consistency and security of fund status, and handles fund discrepancies through automated processes.
Smart Images
Figure CN122288697A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of payment reconciliation technology, specifically to a method, apparatus, device, and medium for ensuring consistency of distributed transactions. Background Technology
[0002] In distributed payment systems, the core payment platform typically needs to connect to multiple external payment channels (such as Alipay, WeChat Pay, and UnionPay). Because each payment channel and the core system use an asynchronous callback mechanism to confirm transaction results, inconsistencies in transaction status can easily arise due to factors such as network latency, lost callbacks, system anomalies, and timeouts, leading to fund consistency issues. Common scenarios include: the payment channel successfully completes the transaction, but the core system does not receive the callback or fails to process it, resulting in excess funds on the channel side (commonly known as "overpayment"); or the core system marks the transaction as successful, but the channel side actually fails, causing a fund shortfall in the core system (commonly known as "underpayment").
[0003] In existing technologies, ensuring fund consistency primarily relies on manual reconciliation. Specifically, finance or operations personnel periodically download reconciliation statements from various payment channels and compare them item by item with the core system's transaction records. If discrepancies are found, they manually contact the channel or technology provider for verification and resolution. This method has the following drawbacks: poor timeliness, as manual reconciliation typically operates on a daily basis, making it difficult to promptly detect and correct fund discrepancies; prone to omissions, as manual comparison struggles to guarantee accuracy and completeness when dealing with massive transaction volumes; and a lack of standardized error handling procedures, with different personnel employing varying methods, making it difficult to establish a traceable closed-loop management system. Summary of the Invention
[0004] In view of this, this application aims to provide a method, apparatus, device and medium for ensuring the consistency of distributed transactions, in order to solve the technical problem of how to achieve automated comparison, intelligent identification and standardized processing of transaction flows from multiple channels, so as to systematically ensure the consistency of funds in a distributed payment environment.
[0005] A first aspect of this application provides a method for ensuring consistency in distributed transactions, the method comprising: Retrieve statement data for the corresponding billing period from multiple payment channels according to a preset cycle; The heterogeneous reconciliation statements from various channels are converted into a unified statement data structure through the channel adapter, forming a standardized channel statement flow. The standardized channel billing records are automatically matched with the payment core internal records according to preset matching rules. For transactions that fail to match, the system identifies them as overpayment, underpayment, or abnormal status based on the transaction status and amount difference, and triggers the corresponding processing rules based on the identified difference type to perform automatic processing operations. Record the processing status until the error handling loop is completed.
[0006] In one possible implementation of this application, the automatic matching of the standardized channel billing records with the payment core internal records according to a preset matching rule includes: One-to-one exact matching is performed based on priority, with the priority order being: channel order number + amount, merchant order number + amount, and merchant order number + amount + status. If an exact match fails, a combined match will be initiated: for scenarios where a single internal transaction corresponds to multiple channel transactions, a matching strategy based on amount aggregation will be used; for scenarios where multiple internal transactions correspond to a single channel transaction, a matching strategy based on group aggregation will be used. The matching process is based on a sliding time window, which is from day T to day T+N, where T is the date the transaction occurred and N is a configurable parameter. During the window period, multiple rounds of incremental reconciliation are performed on unmatched transactions. If the transaction fails to match within the window period, it is marked as unmatched and enters the error handling stage.
[0007] In one possible implementation of this application, the step of triggering the corresponding processing rule and performing the corresponding operation based on the identified difference type includes: When the item is identified as an oversized item, a replacement order is triggered. When the item is identified as being out of stock, a refund will be triggered. When an abnormal status is identified, the transaction is suspended and an error handling work order is generated.
[0008] In one possible implementation of this application, triggering the order replenishment operation when the item is identified as an overage includes: Construct a replacement order request that includes the channel order number, transaction amount, transaction time, and channel status; Call the internal order replenishment interface to perform accounting or status correction, and establish the association between the original channel transaction data and the order replenishment record; The order completion system has idempotent control. When an order completion fails, it is handled according to the failure type: if data verification fails, it is transferred to the exception handling process; if the interface call fails, it is entered into the retry queue; if the preset number of retries is exceeded, a manual work order is generated.
[0009] In one possible implementation of this application, triggering a refund process when a shortage is identified includes: In the event of a complete shortage, a full refund will be issued. When the status is abnormal, a refund of the difference is executed or the refund amount is calculated according to preset rules. The refund amount can be configured through the rule engine. Automatic refunds are executed for small, low-risk transactions; refunds are processed after manual approval for transactions exceeding a preset threshold or high-risk transactions. The refund process is idempotent and records the mapping between the refund and the original transaction.
[0010] In one possible implementation of this application, the error handling work order determines its priority based on transaction amount, error type, suspension duration, and business level, and supports dynamic priority adjustment and alarm notification.
[0011] A second aspect of this application provides a distributed transaction consistency guarantee device, comprising: The channel bill retrieval module is used to retrieve statement data for the corresponding billing period from multiple payment channels according to a preset cycle; The bill parsing and standardization module is used to convert heterogeneous reconciliation statements from various channels into a unified bill data structure through the channel adapter, forming a standardized channel bill transaction record. The automatic reconciliation and matching module is used to automatically reconcile and match the standardized channel billing records with the internal payment core records according to preset matching rules. The error detection module is used to identify unmatched transactions as overpayments, underpayments, or abnormal statuses based on the transaction status and amount differences. The automatic processing module is used to trigger corresponding processing rules based on the identified difference type and execute automatic processing operations; The error handling management module suspends error logs that cannot be handled automatically, generates error handling work orders, and records the handling status until the error handling loop is completed.
[0012] A third aspect of this application provides an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor to cause the at least one processor to perform a distributed transaction consistency guarantee method as described in the first aspect and possible implementations thereof.
[0013] The fourth aspect of this application provides a computer storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement a distributed transaction consistency guarantee method as described in the first aspect and possible implementations of the first aspect.
[0014] The fifth aspect of this application provides a computer program product comprising: a computer program that, when executed by a processor, implements a distributed transaction consistency guarantee method as described in the first aspect and possible implementations of the first aspect.
[0015] The distributed transaction consistency assurance method provided in this application can systematically replace the manual reconciliation process by automatically pulling reconciliation statements from multiple channels at preset cycles, standardizing heterogeneous data into a unified structure using channel adapters, and automatically matching it with internal transaction records. Furthermore, it automatically identifies unmatched transactions as overpayments, underpayments, or abnormal statuses based on transaction status and amount differences, triggering corresponding automatic processing operations according to the type of difference, and finally recording the processing status until the loop is closed. This achieves full automation of the reconciliation and error handling process, significantly shortening the reconciliation cycle, reducing labor costs and the risk of omissions, and enabling differentiated automatic correction measures for different types of fund differences, thus ensuring the consistency and security of fund status in a distributed transaction environment as a whole. Attached Figure Description
[0016] To more clearly illustrate the technical solutions in the specific embodiments or related technologies of this application, the drawings used in the description of the specific embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0017] Figure 1 This is a schematic diagram of the overall architecture of the distributed transaction consistency guarantee system provided in the embodiments of this application.
[0018] Figure 2 This is a flowchart illustrating the distributed transaction consistency guarantee method provided in an embodiment of this application.
[0019] Figure 3 This application provides a schematic diagram of the structure of a distributed transaction consistency guarantee device.
[0020] Figure 4 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation
[0021] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0022] Exemplary system: The distributed transaction consistency guarantee method of this embodiment is applied to a unified payment platform, on which a distributed transaction consistency guarantee system is deployed. In one example, such as... Figure 1As shown, the entire system is divided into 4 levels, forming a complete data processing chain from left to right and top to bottom: 1. Payment Channel Side: The data source layer is the data source of the entire system, including external payment platforms such as WeChat Pay, Alipay, and other payment channels, which are responsible for providing transaction flow and reconciliation data.
[0023] 2. Channel Adaptation and Bill Parsing Layer: This layer includes a bill retrieval adapter and a bill parsing and standardization module. The bill retrieval adapter is used to uniformly connect to different payment channels, retrieving reconciliation data according to a preset period, thus resolving the issue of inconsistent interface protocols and data formats across different channels. The bill parsing and standardization module parses and converts heterogeneous bills from WeChat Pay, Alipay, and other payment platforms into a unified data structure containing merchant order number, channel order number, transaction amount, transaction status, and transaction time, eliminating data format differences and preparing for subsequent reconciliation.
[0024] 3. Reconciliation Processing Core: This is the core processing layer of the system, including the payment transaction management module, the automatic reconciliation and matching engine, the discrepancy identification module, and the rules engine. Among them: The payment transaction management module is used to store and manage transaction data within the payment platform, serving as the baseline data source for reconciliation.
[0025] The automatic reconciliation and matching engine is used to automatically match standardized channel billing records with internal records according to preset rules (such as order number + amount matching, sliding time window matching, etc.), and identify successfully matched and unmatched records.
[0026] The discrepancy identification module is used to identify unmatched transactions into three categories based on transaction status and amount differences: overpayment, underpayment, and abnormal status, providing a basis for subsequent error handling.
[0027] The rules engine is used to trigger preset processing rules based on the type of discrepancy, such as triggering order replenishment for overpayment, triggering refund for underpayment, and triggering alarms for anomalies.
[0028] 4. Handling and Supervision Layer: This includes the error order system, alarm and notification module, and financial / risk control interface; among which: Error Work Order System: Generates work orders for errors that cannot be processed automatically, records processing status, priority, and responsible person, and realizes full-process tracking and closed-loop error handling.
[0029] Alarm and notification module: Sends alarm notifications for abnormal transactions, high-risk errors, and overdue unprocessed work orders to promptly reach relevant personnel.
[0030] Finance / Risk Control Interface: Connects to the finance system to complete accounting adjustments, and connects to the risk control system to complete risk review and monitoring, realizing the integration of reconciliation results with the company's finance and risk control processes.
[0031] Data flows out from the payment channel, and after adaptation and standardization, it enters the reconciliation core and internal flow records for matching and discrepancy identification. Then, it is processed by the rule engine, and finally completes the error closure loop through the work order system and alarm module. It is also connected to the finance and risk control system to form a complete link from data retrieval to fund consistency assurance.
[0032] Exemplary method: The distributed transaction consistency guarantee method in this embodiment is applied to a unified payment platform. This platform needs to connect to multiple external payment channels (such as Alipay, WeChat Pay, UnionPay QuickPass, etc.). Through a distributed deployment approach, it provides upper-level merchants with a unified transaction entry point and fund clearing services, achieving automated payment transaction reconciliation, closed-loop error handling, and ensuring the consistency of distributed transaction funds. Figure 2 As shown, it includes the following steps: S201: Retrieve statement data for the corresponding billing period from multiple payment channels according to a preset cycle.
[0033] Specifically, in this embodiment, after the end of each daily billing cycle (e.g., 2:00 AM), a bill retrieval task is automatically triggered to retrieve the statement files for the previous billing cycle from the FTP servers or API interfaces of each payment channel. A unified scheduling interface is provided for different retrieval methods (e.g., HTTP download, SFTP retrieval, message queue push), supporting channel-level configuration.
[0034] S202: Through the channel adapter, the heterogeneous reconciliation statements of various channels are converted into a unified billing data structure to form a standardized channel billing flow.
[0035] Specifically, this application embodiment sets up multiple channel adapters (such as AlipayAdapter, WechatAdapter, UnionPayAdapter), each adapter parses the corresponding channel's billing format (such as CSV, TXT, JSON, XML), and maps the fields to a standard billing object. The standard billing object contains at least five core fields: channel order number, merchant order number, transaction amount, transaction status, and transaction time.
[0036] Taking Alipay bills as an example, their original format is CSV, containing fields such as: transaction number, merchant order number, actual payment amount, transaction status (e.g., "transaction successful"), and creation time. After reading the CSV file, the Alipay adapter extracts these fields line by line and populates them into a standard bill object. Channel order number ← Transaction number; Merchant order number ← Merchant order number; Transaction amount ← Actual payment amount; Transaction Status ← Maps "Transaction Successful" to "SUCCESS"; Transaction time ← Creation time.
[0037] Similarly, the WeChat Pay adapter parses its JSON format bills, and the UnionPay adapter parses its TXT format bills. Ultimately, all channel data is converted into a unified internal data structure for subsequent matching.
[0038] S203: Automatically match the standardized channel billing records with the payment core internal records according to preset matching rules.
[0039] This application supports one-to-one exact matching, combined matching (one-to-many / many-to-one), and sliding time window matching. Specifically, this application loads standardized channel billing data (denoted as set A) and payment core internal data (denoted as set B) onto the platform, and performs matching according to the following logic, including the following steps: S2031: Perform one-to-one exact matching according to priority, where the priority order is: channel order number + amount, merchant order number + amount, merchant order number + amount + status. The system attempts to match sequentially according to the preset priority: First priority: The channel order number and transaction amount must be completely consistent; Second priority: Merchant order number and transaction amount must be exactly the same; Third priority: Merchant order number + transaction amount + transaction status must be completely consistent.
[0040] Once either priority is matched, both flows are marked as "matched" and removed from the set of unmatched flows, while the matching relationship is recorded.
[0041] S2032: After an exact match fails, proceed to combined matching: For scenarios where a single internal transaction corresponds to multiple channel transactions (one-to-many), match according to the amount aggregation strategy; for scenarios where multiple internal transactions correspond to a single channel transaction, match according to the group aggregation strategy (many-to-one).
[0042] In one example, for a one-to-many scenario: for an unmatched single internal transaction in set B, the system searches for candidate channel transactions in set A whose transaction time falls within a preset window (default 24 hours before and after). If multiple candidate transactions exist, and their sum equals the amount of the internal transaction, and the number of transactions in the combination does not exceed a preset limit (e.g., 5 transactions), then the combination is considered a successful match. For example: if the internal transaction amount is 200 yuan, and a matching channel transaction of 30 yuan + 70 yuan is found, totaling 200 yuan, then the match is successful, and a one-to-many relationship is established.
[0043] For many-to-one scenarios: For a single channel transaction that is not matched in set A, the system searches for candidate transactions within the time window in the unmatched internal transactions of set B. If the sum of the amounts of multiple internal transactions equals the amount of the single channel transaction, then the match is considered successful. For example: If the channel transaction amount is 200 yuan, and an internal transaction of 120 yuan + 80 yuan is matched, then the match is successful, and a many-to-one relationship is established.
[0044] When multiple candidate combinations meet the amount matching conditions (e.g., for an internal transaction of 200 yuan, there are two candidate combinations: 30+70 and 40+60), the transaction is marked as "overdue and unmatched" and will not be automatically matched; instead, it will be transferred to the manual review process.
[0045] This application sets a reconciliation window for each internal transaction, defaulting to T (transaction date) to T+N days, where T is the transaction date and N is a configurable parameter (preferably 1-3 days). Within this window, the transaction continuously participates in the daily incremental reconciliation task, repeatedly matching unmatched transactions within the window to improve the matching success rate. For scenarios with delayed arrival (e.g., a transaction on day T, but the channel transaction is generated on day T+2), the system will automatically reconcile and match successfully in the reconciliation task on day T+2. Transactions that remain unmatched beyond day T+3 are marked as "overdue and unmatched" and enter the subsequent exception handling process.
[0046] In this embodiment of the application, the window period can be dynamically configured according to the settlement cycle of different payment channels. For example, different window periods can be set for T+1 and T+2 settlement channels respectively.
[0047] S204: For unmatched transactions, identify them as overpayment, underpayment, or abnormal status based on the transaction status and amount difference.
[0048] After automatic reconciliation and matching, the system will have the following transaction types remaining: "channel-side one-sided transactions" that exist in the channel billing but have no corresponding record in the internal core system; "core-side one-sided transactions" that exist in the internal core system but have no corresponding record in the channel billing; and "conflicting transactions" where both parties have records but the status or amount is inconsistent. For these unmatched transactions, the system does not simply classify them as "reconciliation failures," but further refines their classification based on two dimensions: transaction status and amount differences.
[0049] Specifically, for a transaction that exists on the channel side but not on the core side or has failed to be processed, if the channel side's transaction status is "successful," it is classified as an overpayment, indicating that the channel side has deducted the payment but it has not been recorded locally, posing a risk of fund stagnation. For a transaction marked as "successful" on the core side but not existing on the channel side or with a status of "failed," it is classified as a underpayment, indicating that the local system considers the transaction successful but the channel side has not actually recorded it, posing a risk of fund loss. For cases where both sides have transaction records but conflicting statuses (e.g., successful on the channel side, failed locally) or inconsistent amounts (e.g., the channel amount is not equal to the local amount), it is classified as an abnormal status. Through the above rule-driven classification method, the system can transform the originally vague "reconciliation discrepancies" into error types with clear business meanings, providing a precise decision-making basis for the subsequent rule engine to perform differentiated automatic processing (e.g., overpayment triggers supplementation, underpayment triggers rollback, and abnormality triggers suspension alarm).
[0050] S205: Trigger the corresponding processing rule based on the identified difference type and execute automatic processing operation.
[0051] Specifically, when an item is identified as long, the rules engine triggers a replacement order: 1. Construct a replacement order request that includes the channel order number, transaction amount, transaction time, and channel status; 2. Call the internal order replenishment interface to perform accounting or status correction, and establish the association between the original channel transaction data and the order replenishment record for subsequent auditing.
[0052] When a replacement order fails, the following processing strategy is implemented in this embodiment: (1) If data verification fails (e.g., the amount is inconsistent), proceed to the status exception handling process; (2) If the system fails or the interface call fails, the system will enter the retry queue to attempt to complete the order multiple times. (3) If the failure still occurs after exceeding the preset number of retries, an error work order will be generated and transferred to manual processing.
[0053] The above-mentioned order replenishment operation has idempotent control. Orders from the same channel number will only be replenished once. Duplicate requests will be returned as successful to prevent duplicate entries.
[0054] When a shortage is detected, the rules engine triggers a refund process, including: 1. The refund amount is determined based on the error type, including: when there is a complete shortage, a full refund is executed; that is, if the amount on the core side is not generated on the channel side at all, a full refund is executed; or the internal refund interface is called to return the transaction funds to the user's account. When there is an abnormal status or a partial error, a refund of the difference is executed or the refund amount is calculated according to preset rules, and the refund amount can be configured through the rule engine.
[0055] 2. Regarding refund execution methods, small, low-risk transactions are automatically refunded, while transactions exceeding a preset threshold or high-risk transactions require manual approval before refunding. In one example, for large transactions exceeding 20,000 yuan, the system defaults to a semi-automatic mode: automatically initiating a refund request, but requiring manual approval from the finance manager before execution; for small transactions (e.g., below 200 yuan), the system automatically executes the refund without manual intervention. The refund operation has idempotent control, records the mapping relationship between the refund and the original transaction, ensuring traceability and preventing duplicate refunds.
[0056] S206: Suspend error logs that cannot be processed automatically, generate error processing work orders, and record the processing status until the error processing loop is completed.
[0057] In this embodiment of the application, the priority of the error handling work order is determined comprehensively based on the transaction amount, error type, suspension duration, and business level. Specifically: Amount-based: The larger the transaction amount, the higher the priority. Error types: Errors involving financial risks (such as shortages or duplicate payments) have a higher priority than general errors; Time dimension: The longer the suspension time, the higher the priority. Business level: Transactions from key businesses or core merchants have higher priority.
[0058] This application embodiment also supports a dynamic priority adjustment mechanism, which automatically increases the priority and sends an alarm notification when an error remains unprocessed or a preset rule is triggered.
[0059] The system sets an initial priority for each unprocessed error work order and continuously monitors the processing status and dwell time. Specifically, when an error work order is not processed within a preset time, or when preset rules such as amount threshold, risk level, or merchant level are triggered, the system automatically raises the priority of the work order and simultaneously sends alarm notifications to the corresponding maintenance and finance personnel to ensure that high-risk and time-sensitive errors are handled with priority.
[0060] For example, a shortfall error of 50,000 yuan initially has a medium priority. If the work order remains unprocessed for more than 2 hours, the system automatically upgrades its priority from medium to high and sends alerts via in-system messages, SMS, and email. If it remains unprocessed for more than 4 hours, it is further upgraded to the highest priority and a telephone alert is added until the work order is accepted and processed, thus ensuring timeliness and risk control throughout the entire error handling process.
[0061] Exemplary system: Figure 3 This is a schematic diagram of the distributed transaction consistency guarantee device provided in the embodiments of this application, as shown below. Figure 3 As shown: The channel bill retrieval module 301 is used to retrieve statement data for the corresponding billing period from multiple payment channels according to a preset cycle; The bill parsing and standardization module 302 is used to convert heterogeneous reconciliation statements from various channels into a unified bill data structure through the channel adapter, forming a standardized channel bill transaction record. The automatic reconciliation and matching module 303 is used to automatically reconcile and match the standardized channel billing flow with the internal flow of the payment core according to a preset matching rule. The error identification module 304 is used to identify unmatched transactions as overpayments, underpayments, or abnormal statuses based on the transaction status and amount differences. Automatic processing module 305 is used to trigger corresponding processing rules based on the identified difference type and perform automatic processing operations; The error handling management module 306 suspends error flows that cannot be handled automatically, generates error handling work orders, and records the handling status until the error handling loop is completed.
[0062] In one or more embodiments of this application, the bill parsing and standardization module 302 includes: The precise matching unit is used to perform one-to-one precise matching according to priority, wherein the priority order is: channel order number + amount, merchant order number + amount, and merchant order number + amount + status; The combined matching unit is used to enter combined matching after exact matching fails: for scenarios where a single internal transaction corresponds to multiple channel transactions, matching is performed according to the amount aggregation strategy; for scenarios where multiple internal transactions correspond to a single channel transaction, matching is performed according to the group aggregation strategy. The sliding matching unit is used to perform the matching process based on a sliding time window, with the window period being from day T to day T+N, where T is the transaction occurrence day and N is a configurable parameter. During the window period, multiple rounds of incremental reconciliation are performed on unmatched transactions. If the unmatched transactions expire, they are marked as expired and enter the error processing stage.
[0063] In one or more embodiments of this application, the automatic processing module 305 includes: The long item automatic processing unit is used to trigger a replacement order operation when the item is identified as long. The automatic shortage handling unit is used to trigger a refund operation when a shortage is detected.
[0064] In one or more embodiments of this application, the long-length automatic processing unit includes: Construct a replacement order request that includes the channel order number, transaction amount, transaction time, and channel status; Call the internal order replenishment interface to perform accounting or status correction, and establish the association between the original channel transaction data and the order replenishment record; The order completion system has idempotent control. When an order completion fails, it is handled according to the failure type: if data verification fails, it is transferred to the exception handling process; if the interface call fails, it is entered into the retry queue; if the preset number of retries is exceeded, a manual work order is generated.
[0065] In one or more embodiments of this application, the automatic shortage processing unit includes: In the event of a complete shortage, a full refund will be issued. When the status is abnormal, a refund of the difference is executed or the refund amount is calculated according to preset rules. The refund amount can be configured through the rule engine. Automatic refunds are executed for small, low-risk transactions; refunds are processed after manual approval for transactions exceeding a preset threshold or high-risk transactions. In one or more embodiments of this application, the priority of error handling work orders is determined comprehensively based on transaction amount, error type, suspension duration, and business level, and dynamic priority adjustment and alarm notification are supported.
[0066] The system provided in this application embodiment can be used to execute the technical solutions of the above method embodiments. Its implementation principle and technical effect are similar, and will not be repeated here.
[0067] Exemplary device: Figure 4 This is a schematic diagram of the hardware structure of the electronic device provided in an embodiment of this application. Figure 4 As shown, the electronic device of this embodiment includes a processor 401 and a memory 402.
[0068] The memory 402 stores computer execution instructions; the processor 401 executes the computer execution instructions stored in the memory to implement the various steps performed by the electronic device in the above embodiments. For details, please refer to the relevant descriptions in the foregoing method embodiments.
[0069] Alternatively, the memory 402 can be either standalone or integrated with the processor 401.
[0070] When the memory 402 is set up independently, the electronic device also includes a bus 403 for connecting the memory 402 and the processor 401.
[0071] Exemplary media and products: This application also provides a computer storage medium storing computer execution instructions. When the processor executes the computer execution instructions, the above-described distributed transaction consistency guarantee method is implemented.
[0072] This application also provides a computer program product, including a computer program, which, when executed by a processor, implements the above-described distributed transaction consistency guarantee method.
[0073] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or modules, and may be electrical, mechanical, or other forms.
[0074] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to implement the solution of this embodiment according to actual needs.
[0075] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing unit, or each module can exist physically separately, or two or more modules can be integrated into one unit. The unit composed of the above modules can be implemented in hardware or in the form of hardware plus software functional units.
[0076] The integrated modules described above, implemented as software functional modules, can be stored in a computer-readable storage medium. These software functional modules, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods of the various embodiments of this application.
[0077] It should be understood that the aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly manifested as execution by a hardware processor, or execution by a combination of hardware and software modules within the processor.
[0078] The memory may include high-speed RAM, and may also include non-volatile storage (NVM), such as at least one disk storage device, and may also be a USB flash drive, external hard drive, read-only memory, disk or optical disc, etc.
[0079] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.
[0080] The aforementioned storage medium can be implemented using any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The storage medium can be any available medium accessible to a general-purpose or special-purpose computer. An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and storage medium can reside in application-specific integrated circuits (ASICs). Alternatively, the processor and storage medium can exist as discrete components in an electronic device or host device.
[0081] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.
[0082] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.
Claims
1. A distributed transaction consistency guarantee method, characterized in that, The method includes: Retrieve statement data for the corresponding billing period from multiple payment channels according to a preset cycle; The heterogeneous reconciliation statements from various channels are converted into a unified statement data structure through the channel adapter, forming a standardized channel statement flow. The standardized channel billing records are automatically matched with the payment core internal records according to preset matching rules. For transactions that fail to match, they are identified as overpayment, underpayment, or abnormal status based on the transaction status and amount difference. Based on the identified difference type, the corresponding processing rule is triggered to execute automatic processing operations; For error logs that cannot be processed automatically, suspend them, generate error processing work orders, and record the processing status until the error processing loop is completed.
2. The method of claim 1, wherein, The step of automatically matching the standardized channel billing records with the payment core internal records according to preset matching rules includes: One-to-one exact matching is performed based on priority, with the priority order being: channel order number + amount, merchant order number + amount, and merchant order number + amount + status. If an exact match fails, a combined match will be initiated: for scenarios where a single internal transaction corresponds to multiple channel transactions, a matching strategy based on amount aggregation will be used; for scenarios where multiple internal transactions correspond to a single channel transaction, a matching strategy based on group aggregation will be used. The matching process is based on a sliding time window, which is from day T to day T+N, where T is the date the transaction occurred and N is a configurable parameter. During the window period, multiple rounds of incremental reconciliation are performed on unmatched transactions. If the transaction fails to match within the window period, it is marked as unmatched and enters the error handling stage.
3. The method of claim 1, wherein, The step of triggering corresponding processing rules and performing corresponding operations based on the identified difference type includes: When the item is identified as an oversized item, a replacement order is triggered. When a shortage is detected, a refund is triggered.
4. The method according to claim 3, characterized in that, The step of triggering a replacement order when the item is identified as an oversized item includes: Construct a replacement order request that includes the channel order number, transaction amount, transaction time, and channel status; Call the internal order replenishment interface to perform accounting or status correction, and establish the association between the original channel transaction data and the order replenishment record; The order completion system has idempotent control. When an order completion fails, it is handled according to the failure type: if data verification fails, it is transferred to the exception handling process; if the interface call fails, it is entered into the retry queue; if the preset number of retries is exceeded, a manual work order is generated.
5. The method according to claim 3, characterized in that, When a shortage is detected, a refund process is triggered, including: In the event of a complete shortage, a full refund will be issued. When the status is abnormal, a refund of the difference is executed or the refund amount is calculated according to preset rules. The refund amount can be configured through the rule engine. Automatic refunds are executed for small, low-risk transactions; refunds are processed after manual approval for transactions exceeding a preset threshold or high-risk transactions. The refund process is idempotent and records the mapping between the refund and the original transaction.
6. The method according to any one of claims 1-5, characterized in that, The error handling work order prioritizes the transaction amount, error type, suspension duration, and business level, and supports dynamic priority adjustment and alarm notification.
7. A distributed transaction consistency guarantee device, characterized in that, include: The channel bill retrieval module is used to retrieve statement data for the corresponding billing period from multiple payment channels according to a preset cycle; The bill parsing and standardization module is used to convert heterogeneous reconciliation statements from various channels into a unified bill data structure through the channel adapter, forming a standardized channel bill transaction record. The automatic reconciliation and matching module is used to automatically reconcile and match the standardized channel billing records with the internal payment core records according to preset matching rules. The error detection module is used to identify unmatched transactions as overpayments, underpayments, or abnormal statuses based on the transaction status and amount differences. The automatic processing module is used to trigger corresponding processing rules based on the identified difference type and execute automatic processing operations; The error handling management module suspends error logs that cannot be handled automatically, generates error handling work orders, and records the handling status until the error handling loop is completed.
8. An electronic device, characterized in that, include: At least one processor; The at least one processor is also connected in communication with a memory, wherein the memory stores a computer program that can be executed by the at least one processor to cause the at least one processor to perform the distributed transaction consistency guarantee method according to any one of claims 1 to 6.
9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the distributed transaction consistency guarantee method as described in any one of claims 1 to 6.
10. A computer program product comprising: It includes a computer program that, when executed by a processor, implements the distributed transaction consistency guarantee method as described in any one of claims 1 to 6.