A digital payment routing intelligent account allocation management and control method and system suitable for multi-service scenarios

Abstract

This application discloses a digital payment routing intelligent revenue sharing management method and system adapted to multiple business scenarios, relating to the field of digital payment data processing technology. The method includes: responding to the triggering of an aggregated payment revenue sharing instruction, obtaining multi-channel payment transaction numbers and payment identifiers for each channel; distributing the multi-channel payment transaction numbers to corresponding independent revenue sharing status queues based on the payment identifiers of each channel; determining the exclusive waiting time for each independent revenue sharing status queue based on historical fund transit latency data corresponding to each channel payment identifier; adding a revenue sharing anti-re-entry lock to the independent revenue sharing status queue within the exclusive waiting time; releasing the anti-re-entry lock and issuing a revenue sharing instruction when the exclusive waiting time expires and a real fund arrival event is received. This application, by combining channel physical isolation with dynamic latency waiting, accurately intercepts erroneous re-entry requests from asynchronous compensation nodes, eliminating the risk of over-distribution of funds and state machine deadlock in dual-channel parallel scenarios.

Description

Technical Field

[0001] This application relates to the field of digital payment data processing technology, and in particular to a digital payment routing intelligent accounting control method and system adapted to multiple business scenarios. Background Technology

[0002] With the development of digital payment services, aggregated payment gateways need to connect to multiple underlying payment channels simultaneously. The settlement cycles for funds in transit differ physically across these channels. For example, the underlying ledger of the digital RMB uses second-level clearing, while interbank clearing for bank cards involves forwarding through multiple network nodes, resulting in a settlement cycle far exceeding that of the digital RMB. In aggregated payment revenue sharing routing scenarios, the system needs to split and distribute the underlying funds of an aggregated payment order to multiple revenue sharing recipients. To ensure the eventual consistency of revenue sharing, the system typically deploys asynchronous compensation polling nodes. These nodes periodically probe the execution status of revenue sharing instructions from each channel within a fixed time window. When the fixed time window expires and no successful revenue sharing confirmation message is received, the asynchronous compensation polling node classifies the revenue sharing instruction as a failure and reissues it.

[0003] However, in dual-channel parallel business scenarios, the fixed time window cannot accommodate the ultra-fast arrival of funds from the digital RMB channel and the delayed arrival of funds from the bank card channel. When the asynchronous compensation polling node closes at the fixed time window, the funds from the bank card channel are still in transit. The asynchronous compensation polling node cannot accurately identify the true transit status of the bank card channel and incorrectly marks the delayed bank card channel transfer instruction as a failure. Based on the failure status marking, the asynchronous compensation polling node triggers repeated transfer instruction issuance operations, causing the same underlying funds to be mapped multiple times to different transfer recipients in the transfer state machine, leading to serious risks of over-distribution of funds and deadlock problems in the transfer state machine accounts. Summary of the Invention

[0004] In view of the aforementioned problems, this application is hereby filed.

[0005] Therefore, this application provides a digital payment routing intelligent accounting and management method and system that adapts to multiple business scenarios, which can solve the problems mentioned in the background art.

[0006] To solve the above-mentioned technical problems, this application provides the following technical solution:

[0007] Firstly, this application provides a digital payment routing intelligent accounting control method adapted to multiple business scenarios, including: In response to the triggering of the aggregated payment splitting instruction, obtain the multi-channel payment transaction number and each channel payment identifier contained in the aggregated payment splitting instruction; Distribute multi-channel payment serial numbers to independent accounting status queues corresponding to each channel payment identifier based on the payment identifier of each channel. Based on the historical fund transit delay data corresponding to the payment identifiers of each channel, the exclusive waiting time for each independent account status queue is determined; Add a deduplication lock to the independent account splitting status queue that is within the dedicated waiting period. Release the deduplication lock and issue an account splitting instruction when the dedicated waiting period expires and a real fund arrival event is received.

[0008] In one possible implementation, determining the specific waiting time for each independent accounting status queue based on historical fund transit delay data corresponding to each channel payment identifier includes: Obtain the time points when funds leave and arrive for payment indicators from various channels within multiple past settlement cycles; Obtain the time difference between the time the funds are credited and the time the funds are debited, and then sum up multiple time differences to calculate the average value; An additional buffer time interval is added to the average value to generate a dedicated waiting time, which is then bound and stored with an independent revenue sharing status queue.

[0009] In one possible implementation, adding a re-entry lock to the independent accounting status queue within its dedicated waiting time includes: In response to the operation of entering the independent accounting status queue in response to the accounting instruction, the status identifier in accounting processing is written to the current node of the independent accounting status queue. Generate a split-account anti-duplicate lock based on the status identifier and attach the split-account anti-duplicate lock to the memory data area corresponding to the multi-channel payment serial number; The anti-duplicate entry lock intercepts secondary transaction instructions targeting multi-channel payment serial numbers and returns a status response indicating that the instruction is being processed to the node that initiated the secondary transaction instruction.

[0010] In one possible implementation, the step of releasing the anti-duplicate lock and issuing a splitting instruction upon the expiration of the dedicated waiting period and the receipt of a real fund arrival event includes: Obtain the underlying fund arrival notification message and match and verify the transaction number in the fund arrival notification message with the multi-channel payment transaction number; Based on the successful matching verification, the status identifier in the independent accounting status queue will be updated to the fund settlement status. Based on the fund settlement status, the anti-duplicate lock of the sub-account mounted in the memory data area is destroyed and the distribution and transfer operation of the sub-account instruction is triggered.

[0011] In one possible implementation, updating the status identifier in the independent accounting status queue to the fund settlement status based on the successful matching verification includes: In response to an event where the dedicated waiting period has expired and no notification message of fund arrival has been received, the status flag of the independent account status queue will be changed to an abnormal pending account status. Based on the abnormal account status, abnormal account records are generated and written into a separate abnormal account verification data table; The anti-duplicate lock corresponding to the abnormal account records is persistently retained to prevent subsequent automatic account transfer for abnormal account records.

[0012] In one possible implementation, the step of intercepting the secondary transaction splitting instruction for the multi-channel payment serial number based on the transaction splitting anti-reentrancy lock and returning a status response indicating that it is being processed to the node that initiated the secondary transaction splitting instruction includes: Obtain the secondary revenue sharing instruction issued by the asynchronous compensation node and parse the secondary revenue sharing instruction to extract the compensation trigger source identifier and the compensation target serial number; Based on the compensation trigger source identifier and the compensation target serial number, query whether there is a split-account anti-duplicate lock in the memory data area corresponding to the multi-channel payment serial number; Based on the existence of a split-account anti-re-entry lock in the memory data area, the query result discards the secondary split-account instruction and returns a successful interception notification to the asynchronous compensation node.

[0013] In one possible implementation, the query result based on the memory data region's anti-reentrancy lock for accounting purposes discards the secondary accounting instruction and returns a successful interception notification to the asynchronous compensation node, including: In response to the pending account status query request initiated by the asynchronous compensation node after receiving the interception success notification, obtain the current status identifier of the independent account status queue; Based on the determination result that the current status is marked as an abnormal pending account, a release instruction is sent to the asynchronous compensation node to allow the fund return operation to be performed; The release command releases the anti-duplicate lock on the abnormal posting record and updates the status flag of the independent posting status queue to the return processing status.

[0014] In one possible implementation, the step of distributing multi-channel payment serial numbers to independent accounting status queues corresponding to each channel payment identifier based on the channel payment identifier includes: The channel payment identifier contained in the aggregated payment splitting instruction is parsed into digital RMB channel type and bank card channel type; Import the associated multi-channel payment serial number into the independent digital RMB account status queue according to the digital RMB channel type; Based on the bank card channel type, the associated multi-channel payment serial number is imported into the bank card's independent accounting status queue to achieve state space isolation between different physical settlement channels.

[0015] In one possible implementation, the step of destroying the anti-re-entry lock mounted in the memory data area based on the fund settlement status and triggering the distribution and transfer of settlement instructions includes: In response to the triggering of the distribution and transfer operation of the revenue sharing instruction, obtain the account identifier and revenue sharing amount data of each revenue sharing recipient contained in the revenue sharing instruction; Based on the account identifier, match the corresponding target fund account in the underlying split fund pool and verify the available balance data of the target fund account; Based on the available balance data and the verification results of the split amount data, the split execution status of the target fund account is written into the account transaction record to complete the fund disbursement.

[0016] Secondly, this application also provides a digital payment routing intelligent accounting control system adapted to multiple business scenarios, including: The instruction response acquisition module is used to respond to the triggering of the aggregated payment split instruction and acquire the multi-channel payment transaction number and each channel payment identifier contained in the aggregated payment split instruction; The channel distribution module is used to distribute multi-channel payment serial numbers to the independent accounting status queues corresponding to each channel payment identifier based on the payment identifier of each channel. The duration determination module is used to determine the exclusive waiting duration of each independent accounting status queue based on the historical fund transit delay data corresponding to the payment identifier of each channel. The lock control execution module is used to add a debit lock to the independent debit status queue that is within a dedicated waiting period. When the dedicated waiting period expires and a real fund arrival event is received, the debit lock is released and a debit instruction is issued.

[0017] Implementing this application has the following beneficial effects: This application combines channel physical isolation with dynamic latency waiting to accurately intercept erroneous re-entry requests from asynchronous compensation nodes, eliminating the risk of over-distribution of funds and state machine deadlock in dual-channel parallel scenarios. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application 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 related drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 A flowchart illustrating a digital payment routing intelligent accounting control method adapted to multiple business scenarios, provided as an embodiment of this application; Figure 2A core overall flowchart of a digital payment routing intelligent accounting control method adapted to multiple business scenarios provided in one embodiment of this application; Figure 3 This is a specific timing diagram of a digital payment routing intelligent accounting control system adapted to multiple business scenarios, provided as an embodiment of this application. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0021] The terms "first," "second," "third," "fourth," etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein.

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

[0023] It should be understood that in this application, "comprising" and "having" and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are explicitly listed, but may include other steps or units that are not explicitly listed or that are inherent to such process, method, product or device.

[0024] It should be noted beforehand that the numerical descriptions such as "threshold," "upper and lower limits," and "preset threshold" appearing in the specific implementation methods can be determined based on the needs of relevant personnel in the actual operation scenario and existing technology. It is easy to understand that the required "threshold," "upper and lower limits," and "preset thresholds" are often different for different experimental scenarios. This application focuses on the processing of method logic, rather than limiting specific values. This part will not be repeated later; this statement is made here.

[0025] It should be understood that in this application, "multiple" refers to two or more. "And / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "Contains A, B, and C", "Contains A, B, and C" means that all three A, B, and C are contained; "Contains A, B, or C" means that one of A, B, and C is contained; "Contains A, B, and / or C" means that any one, two, or three of A, B, and C are contained.

[0026] It should be understood that in this application, "B corresponding to A", "B corresponding to A", "A corresponds to B", or "B corresponds to A" means that B is associated with A, and B can be determined based on A. Determining B based on A does not mean determining B solely based on A; B can also be determined based on A and / or other information. Matching A and B is defined as a similarity between A and B that is greater than or equal to a preset threshold.

[0027] Depending on the context, "if" as used here can be interpreted as "when," "when," "in response to determination," or "in response to detection."

[0028] The technical solutions of this application will be described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0029] This application provides a method that can effectively solve the problems mentioned above. The following will describe in detail how to implement this digital payment routing intelligent accounting and management method that adapts to multiple business scenarios, using a system configured with the method of this application.

[0030] Figure 1 A flowchart illustrating a digital payment routing intelligent revenue sharing and management method adapted to multiple business scenarios is shown, including: S1, in response to the triggering of the aggregated payment splitting instruction, obtains the multi-channel payment serial number and each channel payment identifier contained in the aggregated payment splitting instruction; It should be noted that the aggregated payment split instruction is the initial control signal that triggers the intelligent split management process of digital payment routing. The multi-channel payment serial number is a unique set of numbers that identifies the fund flow status of an aggregated payment order in multiple underlying payment channels. The payment identifiers of each channel are tag data used to distinguish the physical attributes and settlement characteristics of different underlying payment channels.

[0031] Among them, the aggregated payment splitting instruction contains the order traceability information and channel routing information necessary to complete a multi-channel fund split. By parsing the aggregated payment splitting instruction, the processing objects for subsequent fund distribution and state isolation can be determined.

[0032] In this application embodiment, a message queue for a specific topic in a distributed message bus is monitored, and when a message message containing a splitting trigger identifier is inserted into the message queue, the trigger event of the aggregated payment splitting instruction is captured.

[0033] Furthermore, the captured aggregated payment splitting instructions are decrypted and deserialized, and the main order number field and the subsidiary channel list field are extracted from the deserialized data structure.

[0034] Furthermore, the sub-channel list fields are traversed, and the serial number string corresponding to each sub-channel is concatenated to generate a multi-channel payment serial number. At the same time, the channel code string corresponding to each sub-channel is extracted to generate the payment identifier for each channel.

[0035] Furthermore, the multi-channel payment serial number and each channel payment identifier are loaded into the working memory area of ​​the revenue sharing management process for subsequent steps to call.

[0036] For example, when an order includes both digital RMB payment and bank card payment, the aggregated payment splitting instruction contains digital RMB channel code and bank card channel code. The codes are extracted to generate payment identifiers for each channel, and the corresponding transaction numbers are extracted and assembled into a multi-channel payment transaction number.

[0037] It should be noted that this application provides a precise data addressing basis for the subsequent physical isolation of revenue sharing transactions by channel by accurately obtaining multi-channel payment transaction numbers and payment identifiers of each channel.

[0038] S2, Distribute the multi-channel payment serial number to the independent accounting status queue corresponding to each channel payment identifier according to the payment identifier of each channel; Understandably, this step primarily involves physically classifying and routing the extracted serial number data according to channel attributes, ensuring that channel data from different settlement periods enters independent processing spaces and avoiding state confusion. Specifically, this can be achieved through the following steps: S21, resolves the channel payment identifier contained in the aggregated payment splitting instruction into digital RMB channel type and bank card channel type; It should be noted that the digital RMB channel type represents the payment channel attribute that uses the digital RMB ledger for second-level settlement, while the bank card channel type represents the payment channel attribute that involves interbank network node forwarding and has a longer settlement cycle.

[0039] The purpose of resolving the channel payment identifier into digital RMB channel type and bank card channel type is to clarify the physical settlement differences of each channel before routing and distribution, thereby providing a classification basis for the physical isolation of the subsequent state space.

[0040] In this application embodiment, the first character code in the payment identifier of each channel is obtained. The first character code is used to characterize the underlying clearing network to which the payment channel belongs.

[0041] Furthermore, the first character code is compared bit by bit with the locally preset digital RMB network feature code. If the first character code is completely consistent with the digital RMB network feature code, the channel payment identifier is determined to be a digital RMB channel type.

[0042] Furthermore, the first character code is compared bit by bit with the locally preset bank card network feature code. If the first character code is completely consistent with the bank card network feature code, the channel payment identifier is determined to be a bank card channel type.

[0043] Furthermore, the parsed digital RMB channel type and bank card channel type are written into the context information of the serial number distribution task.

[0044] For example, if the first character of the channel payment identifier is DCEP, the identifier is determined to belong to the digital RMB channel type; if the first character of the channel payment identifier is BANK, the identifier is determined to belong to the bank card channel type.

[0045] It should be noted that this application improves the accuracy of routing and distribution by accurately analyzing channel types and transforming complex aggregated payment instructions into two distinct physical channel categories.

[0046] S22, import the associated multi-channel payment serial number into the digital RMB independent account status queue according to the digital RMB channel type; It should be noted that the independent settlement status queue for digital RMB is a memory data structure specifically used to cache the settlement transaction records and status of digital RMB channels. The associated multi-channel payment transaction number refers to the transaction number data corresponding to the channel type identified as digital RMB.

[0047] The purpose of importing the associated multi-channel payment serial number into the independent accounting status queue of digital RMB is to spatially isolate the business data of the instant payment type from the business data of the delayed payment type in physical memory.

[0048] In this embodiment of the application, serial number records marked as digital RMB channel type are filtered out from context information.

[0049] Furthermore, locate the tail pointer position of the pre-allocated digital RMB independent accounting status queue in memory.

[0050] Furthermore, the selected serial number records are encapsulated as independent data nodes, and these independent data nodes are inserted into the tail pointer position of the digital RMB independent accounting status queue.

[0051] Furthermore, update the tail pointer position of the independent accounting status queue of digital RMB to the newly inserted data node to complete the import operation.

[0052] It should be noted that this application ensures that the transaction data of the digital RMB channel is processed in a separate memory space through the import operation of a dedicated queue.

[0053] S23, based on the bank card channel type, import the associated multi-channel payment serial number into the bank card independent accounting status queue to achieve state space isolation of different physical settlement channels.

[0054] It should be noted that the bank card independent settlement status queue is a memory data structure specifically used to cache the settlement flow and status of bank card channels. State space isolation refers to dividing the memory area of ​​a distributed system into independent data operation areas that do not interfere with each other for channels with different settlement cycles.

[0055] Existing aggregated payment and settlement systems typically process all channel transactions in the same global state machine. In dual-channel parallel scenarios, the global state machine cannot distinguish between instant and delayed settlements, causing delayed bank card channel transactions to be incorrectly marked as failed during asynchronous compensation probing, thus triggering a state machine deadlock problem. It should be noted that this application addresses the aforementioned problem of global state machine confusing the states of different physical settlement channels by importing bank card channel transactions into a dedicated queue.

[0056] In this embodiment of the application, the serial number records marked as bank card channel type are filtered out from the context information.

[0057] Furthermore, locate the tail pointer position of the pre-allocated bank card independent accounting status queue in memory.

[0058] Furthermore, the selected serial number records are encapsulated as independent data nodes, and these independent data nodes are inserted into the tail pointer position of the bank card independent account status queue.

[0059] Furthermore, the tail pointer position of the bank card independent accounting status queue is updated, so that the digital RMB independent accounting status queue and the bank card independent accounting status queue are completely independent in memory address space, thus completing state space isolation.

[0060] It should be noted that this application completely cuts off the state interference of bank card delayed settlement on digital RMB's second-level settlement through a strict physical memory isolation mechanism, eliminating the risk of state machine deadlock.

[0061] S3 determines the exclusive waiting time for each independent account status queue based on the historical fund transit delay data corresponding to the payment identifiers of each channel. Understandably, this step primarily utilizes historical statistical data to dynamically configure a reasonable waiting time for each independent revenue-sharing status queue, replacing the traditional fixed-time-window compensation detection mechanism. Specifically, this can be achieved through the following steps: S31, obtain the time points when funds leave and arrive for payment identifiers from various channels in past settlement cycles; It should be noted that the fund departure time point in the past multiple settlement cycles refers to the timestamp of funds being deducted from the initiator's account in the historical order, while the fund arrival time point refers to the timestamp of funds arriving in the recipient's account in the historical order.

[0062] Obtaining the departure and arrival times of funds is to construct a basic time sample set for calculating the delay in funds in transit, thereby providing raw data support for the subsequent dynamic calculation of specific waiting time.

[0063] In this embodiment of the application, a historical data query request is sent to the underlying accounting transaction database based on the payment identifier of each channel.

[0064] Furthermore, the accounting transaction database receives historical data query requests and retrieves transaction records from the historical accounting transaction table for multiple past settlement cycles with payment identifiers from various channels.

[0065] Furthermore, the first timestamp field corresponding to the fund departure action and the second timestamp field corresponding to the fund arrival action are extracted from the transaction records of multiple past settlement cycles.

[0066] Furthermore, the extracted first timestamp field and second timestamp field are paired and combined in chronological order to generate a time point pairing set.

[0067] It should be noted that this application has established a latency sample library that reflects the actual physical settlement capabilities of various channels by extracting historical timestamp data on a large scale.

[0068] S32, obtain the time difference between the time point when funds are received and the time point when funds are received, and sum up multiple time differences to obtain the average value; It should be noted that the time difference is the absolute time taken for funds for a single historical order to be credited from the time the funds are debited to the time the funds are credited, while the average value is a statistical indicator that measures the typical settlement speed of this channel over multiple past settlement cycles.

[0069] The calculation of time difference and average is to transform scattered historical settlement events into a representative time benchmark that can reflect the time it takes for funds to arrive in the channel in most cases.

[0070] In this embodiment, the time point pairing set is traversed, and for each pairing data, the second-level timestamp value corresponding to the fund deposit time point is subtracted from the second-level timestamp value corresponding to the fund departure time point to obtain a single time difference value.

[0071] Furthermore, the calculated time differences are stored in a temporary accumulator register and then summed to obtain the total time difference.

[0072] Furthermore, the sum of the time differences is divided by the total number of time differences to calculate a preliminary average.

[0073] Furthermore, the calculated preliminary average value is stored in the configuration cache area corresponding to the payment identifier of each channel.

[0074] In an optional implementation, the aforementioned average value can be obtained through the following specific calculation method, wherein: ; In the formula, This represents a preliminary average value. This indicates the total number of previous settlement periods. Indicates the first The timestamp value corresponding to the time point of fund receipt within each settlement cycle. Indicates the first The timestamp value corresponding to the time point when funds are deferred within each settlement cycle. In the formula above... and The data comes from the timestamp field extracted from the accounting transaction database in step S31, and is calculated accordingly. As a basic parameter, it is directly used in the calculation process of generating the specific waiting time in step S33.

[0075] It should be noted that this application uses a rigorous statistical averaging algorithm to transform fluctuating historical latency data into stable benchmark time parameters, thereby improving the scientific validity of the waiting time setting.

[0076] S33, add an extra buffer time interval to the average value to generate a dedicated waiting time, and bind and store the dedicated waiting time with an independent revenue sharing status queue; It should be noted that the additional buffer time interval is a safety margin reserved to cope with network jitter or occasional congestion of the underlying clearing nodes, and the dedicated waiting time is the final waiting time limit set for the independent revenue sharing status queue of a specific channel after comprehensively considering the historical average time and safety margin.

[0077] The additional buffer time interval is to ensure that the dedicated waiting time can cover the delay in funds in transit under extreme circumstances, and to avoid the system misjudging the account as abnormal due to occasional timeouts. The dedicated waiting time is bound to the independent account status queue for storage so that the corresponding waiting time standard can be quickly read in the subsequent anti-reentry lock control stage.

[0078] In this embodiment of the application, a preliminary average value is read from the configuration cache area corresponding to each channel payment identifier.

[0079] Furthermore, based on the underlying network type of each payment channel identifier, the corresponding buffer coefficient is found in the system parameter table, and the buffer time interval is calculated by multiplying the preliminary average value by the buffer coefficient.

[0080] Furthermore, the initial average value is added to the buffer time interval to generate a specific waiting time.

[0081] Furthermore, a key-value pair mapping relationship is established in memory between the identifier of the independent accounting status queue and the exclusive waiting time, and the key-value pair mapping relationship is written into the queue configuration data table to complete the binding storage.

[0082] For example, the average time to read data from the bank card channel is 120 seconds. Looking up the table, the buffer coefficient for the bank card channel is 0.5, resulting in a buffer time interval of 60 seconds. A dedicated waiting time of 180 seconds is then generated and stored in the bank card's independent accounting status queue. The buffer coefficient mentioned here can be dynamically adjusted based on the network stability, clearing node level, and historical abnormal latency distribution characteristics of different channels. For instance, for the cross-border bank card channel, due to the involvement of multi-currency exchange and international clearing organization forwarding, its buffer coefficient can be set to 0.8. If the average time is 300 seconds, the buffer time interval is 240 seconds, and the dedicated waiting time is 540 seconds. For the domestic digital RMB channel, because it uses the central bank digital currency system for direct clearing, the network stability is extremely high, and the buffer coefficient can be as low as 0.2. If the average time is 10 seconds, the buffer time interval is 2 seconds, and the dedicated waiting time is 12 seconds. The system periodically (e.g., daily at midnight) resamples and recalculates historical latency data for each channel. When the actual latency fluctuation of a channel exceeds ±15% within three consecutive settlement cycles, the system automatically triggers a buffer coefficient calibration process to ensure that the dedicated waiting time always matches the channel's current actual clearing capacity. It should be noted that this application, by introducing a dynamic buffer mechanism, avoids both the inefficiency of settlement caused by excessively long fixed waiting times and the erroneous compensation problems caused by excessively short waiting times, achieving a balance between efficiency and accuracy. This application dynamically overlays buffer time intervals to tailor a fault-tolerant dedicated waiting time for each independent queue, overcoming the shortcomings of fixed time windows that cannot adapt to the physical differences between different channels.

[0083] S4, add a debit lock to the independent debit status queue that is within the exclusive waiting time, and release the debit lock and issue a debit instruction when the exclusive waiting time expires and a real fund arrival event is received. Understandably, this step primarily controls the access permissions of the independent accounting status queue during the waiting period through locking and unlocking mechanisms, preventing asynchronous compensation nodes from repeatedly issuing accounting instructions while funds are in transit. Specifically, this can be achieved through the following steps: S41, in response to the operation of entering the independent accounting status queue in response to the accounting instruction, write the status identifier in accounting processing to the current node of the independent accounting status queue. It should be noted that the status identifier in the splitting process is a control field used to mark a specific transaction number in the independent splitting status queue that is currently in the stage of waiting for funds to arrive and is not allowed to be repeated. The current node refers to the actual data storage location occupied by the splitting instruction in the independent splitting status queue.

[0084] The purpose of writing the status identifier in the revenue sharing process is to establish the first state barrier at the node level of the independent revenue sharing status queue, so that any subsequent operation request for that node must first read and verify the specific content of the status identifier.

[0085] In this embodiment, the enqueue event of the independent revenue sharing status queue is monitored. When the data packet of the revenue sharing instruction is detected to be written to the current node of the independent revenue sharing status queue, the status initialization process is triggered.

[0086] Furthermore, the multi-channel payment transaction number carried by the splitting instruction is extracted, and the multi-channel payment transaction number is located to the current node of the independent splitting status queue.

[0087] Furthermore, the state machine modification interface is called to overwrite the initial idle state field in the current node with the state code corresponding to the state identifier in the accounting process.

[0088] Furthermore, the status code writing results are synchronized to the replica memory area of ​​the independent accounting status queue to ensure state consistency in a distributed environment.

[0089] For example, the splitting instruction enters the 5th node of the bank card's independent splitting status queue, and writes the PROCESSING status code into the status field of the 5th node.

[0090] It should be noted that this application solidifies the processing state within the data structure by writing explicit state identifiers into the queue nodes, providing direct local data basis for subsequent anti-reentrancy judgment.

[0091] S42, Generate a split account anti-duplicate lock based on the status identifier and attach the split account anti-duplicate lock to the memory data area corresponding to the multi-channel payment serial number; It should be noted that the split-payment anti-duplicate lock is a mutual exclusion control variable implemented based on a memory data structure. The memory data area refers to the distributed memory cache space that is uniquely bound to the multi-channel payment serial number.

[0092] The purpose of generating a deduplication lock based on the status identifier is to elevate the status identifier of the queue node to a global memory lock object. The purpose of attaching the deduplication lock to the memory data area is to enable the asynchronous compensation node to directly address the lock object by the serial number when initiating a query, thereby intercepting duplicate requests at the global level.

[0093] In this embodiment of the application, the status identifier of the split processing in the current node of the independent split status queue is read.

[0094] Furthermore, using the multi-channel payment serial number as the primary key and the status identifier as the lock status value, a split-account anti-reentrancy lock object is instantiated in the memory data area.

[0095] Furthermore, the hash value of the multi-channel payment serial number is calculated, and the split-payment anti-reentrancy lock object is routed and stored on the corresponding memory shard node according to the hash value.

[0096] Furthermore, a lock mounting confirmation request is sent to the memory shard node, and the memory shard node returns a response message indicating successful mounting, thus completing the physical deployment of the accounting anti-reentrancy lock.

[0097] For example, based on the hash value of the serial number BANK_20260419_002, the generated anti-reentrancy lock object is mounted to the specified cache line of memory shard node 3.

[0098] It should be noted that this application transforms the status flag into a global memory lock, changing the inefficient traditional model that relies on database row locks, and greatly improving the response speed of concurrent interception and system throughput.

[0099] S43, based on the anti-re-entry lock for splitting accounts, intercept the secondary splitting instruction for multi-channel payment serial numbers and return a status response indicating that it is being processed to the node that initiated the secondary splitting instruction; Understandably, this step primarily utilizes the already mounted anti-duplicate lock to intercept and provide status feedback for duplicate requests from outside the system in real time, maintaining the uniqueness of the revenue sharing status. Specifically, this can be achieved through the following steps: S431, obtain the secondary accounting instruction issued by the asynchronous compensation node and parse the secondary accounting instruction to extract the compensation trigger source identifier and the compensation target serial number; It should be noted that the asynchronous compensation node is an independent process in the system responsible for detecting the accounting status according to the time window and resending the instruction when the failure is determined. The secondary accounting instruction is an accounting request message regenerated by the asynchronous compensation node after the initial accounting instruction has timed out. The compensation trigger source identifier is used to prove that the instruction was issued by the asynchronous compensation node, and the compensation target serial number is the order serial number that the secondary accounting instruction attempts to operate on.

[0100] The purpose of acquiring and parsing secondary revenue sharing instructions is to identify the identity attributes and operation targets of external requests, thereby providing feature comparison data for subsequent accurate interception.

[0101] In this embodiment of the application, network data packets sent by asynchronous compensation nodes are received through a distributed communication framework.

[0102] Furthermore, the network data packets are disassembled according to the predefined message structure, and the sender process number in the header field of the network data packets is read and extracted as the compensation trigger source identifier.

[0103] Further, the target order number string in the network packet payload field is read, and the target order number string is extracted as the compensation target serial number.

[0104] Furthermore, the compensation trigger source identifier and the compensation target serial number are encapsulated into an interception verification data packet and passed to the subsequent query module.

[0105] For example, when a network data packet with asynchronous compensation node process number COMP_01 is received, the compensation trigger source identifier COMP_01 and the compensation target serial number BANK_20260419_002 are extracted from it.

[0106] It should be noted that this application provides precise data filtering conditions for the system to distinguish between normal business requests and compensation retry requests by finely analyzing the source and target of external retry requests.

[0107] S432, based on the compensation trigger source identifier and the compensation target serial number, query whether there is a split account anti-duplicate lock in the memory data area corresponding to the multi-channel payment serial number; It should be noted that querying whether a split-account anti-reentrancy lock exists in the memory data area refers to locating a specific memory address by compensating the target serial number and checking whether a valid lock instance object is stored in that memory address.

[0108] The existence check is used to determine whether the order targeted by the secondary revenue splitting instruction is within the protected waiting period. This determination is the sole basis for deciding whether to intercept the secondary revenue splitting instruction.

[0109] In this embodiment of the application, the compensation trigger source identifier in the intercepted verification data packet is checked to see if it belongs to a valid list of asynchronous compensation nodes. If it is valid, the query operation continues.

[0110] Furthermore, the compensation target serial number is converted into a memory addressing key, and a lock status query request is sent to the memory shard node of the storage ledger anti-reentrancy lock.

[0111] Furthermore, the memory shard node retrieves the corresponding cache line based on the memory addressing key and detects the live timestamp of the lock instance object in the cache line.

[0112] Furthermore, if the live timestamp indicates that the lock instance object has not expired, the memory shard node returns a query result to the system indicating that a ledger anti-reentrant lock exists; if the cached behavior is empty or the lock instance object has expired, the memory shard node returns a query result to the system indicating that a ledger anti-reentrant lock does not exist.

[0113] For example, the system uses the serial number BANK_20260419_002 to initiate a query to memory shard node 3. Memory shard node 3 detects that there is an unexpired lock object at this address and returns the query result that the lock exists.

[0114] It should be noted that this application achieves millisecond-level determination of duplicate revenue sharing requests through direct memory-level lock object detection, avoiding inefficient database status lookups.

[0115] S433: Based on the existence of a split-account anti-re-entry lock in the memory data area, the query result discards the secondary split-account instruction and returns an interception success notification to the asynchronous compensation node; Understandably, this step primarily involves executing interception actions and notifying the request initiator in a closed-loop manner, ensuring that the asynchronous compensation node promptly stops invalid retries for that serial number. Specifically, this can be achieved through the following steps: S4331, responding to the account status query request initiated by the asynchronous compensation node after receiving the interception success notification, obtains the current status identifier of the independent account status queue; It should be noted that the pending account status query request is a status inquiry request initiated by the asynchronous compensation node after being intercepted in order to confirm the final destination of the funds. The current status identifier refers to the actual status code of the transaction number in the independent account status queue at the time of interception.

[0116] Obtaining the current status identifier is to provide the asynchronous compensation node with an accurate account posting context, enabling the asynchronous compensation node to determine the subsequent compensation strategy based on the specific status.

[0117] In this embodiment of the application, the asynchronous compensation node receives an account status query request message sent after successfully parsing the interception notification.

[0118] Furthermore, the serial number parameter to be queried is extracted from the account status query request message.

[0119] Furthermore, the corresponding independent accounting status queue is located based on the serial number parameter, and the status field of the node containing the serial number in the independent accounting status queue is read.

[0120] Furthermore, the read status field is decoded into a current status identifier, and the current status identifier is loaded into the status response message for transmission.

[0121] For example, the status field of the node containing the transaction number BANK_20260419_002 in the bank card independent account status queue is read, and the current status identifier is ABNORMAL_PENDING.

[0122] It should be noted that this application breaks the black-box nature of traditional interception mechanisms by exposing the true state of the queue to the interceptor, thus providing state transparency for the secure handling of funds in abnormal scenarios.

[0123] S4332, based on the determination result that the current status is marked as an abnormal pending account, send a release instruction to the asynchronous compensation node to allow the fund return operation to be performed; It should be noted that the abnormal pending status refers to the abnormal situation where the dedicated waiting period has expired but the system has not yet received the underlying fund arrival notification message. The release instruction is the permission signal of the system to authorize the asynchronous compensation node to perform reverse fund operation.

[0124] Sending a release instruction to the asynchronous compensation node is intended to guide the asynchronous compensation node to follow a safe processing path for fund return if it is confirmed that the funds cannot arrive normally, thus preventing the risk of funds remaining in an unknown state for an extended period.

[0125] In this application implementation, the obtained current status identifier is strictly matched and compared with the pre-set abnormal account status codes in the system.

[0126] Furthermore, if the comparison result determines that the current status is an abnormal pending status, a release instruction message containing a fund return permission identifier is generated.

[0127] Furthermore, the release instruction message is sent to the instruction receiving port of the asynchronous compensation node through an encrypted communication channel.

[0128] Furthermore, the asynchronous compensation node parses the release instruction message, extracts the fund return permission identifier, and activates the internal fund return process module.

[0129] For example, if the current status is determined to be ABNORMAL_PENDING, a release instruction message with the REFUND_PERMIT flag is sent to the asynchronous compensation node.

[0130] It should be noted that this application accurately triggers the release instruction through conditional judgment, providing a compliant exit channel for asynchronous pending funds and ensuring the safety of user funds.

[0131] S4333, based on the release command, releases the anti-duplicate lock for abnormal pending records and updates the status flag of the independent account status queue to the return processing status.

[0132] It should be noted that releasing the anti-re-entry lock for abnormal account records means logically destroying the lock instance object that is persistently retained in the memory data area, and the return processing status refers to the status code in the independent account status queue that marks the transaction number as undergoing the original fund return operation.

[0133] Existing account management methods often maintain long-term locking of the account anti-duplicate lock or adopt a crude timed release mechanism when facing abnormal situations such as funds not arriving on time. This results in asynchronous compensation nodes being unable to intervene or causing state chaos after intervention, leading to serious failures such as permanent fund closure or over-distribution. It should be noted that this application addresses the problem of the disconnect between the locking mechanism and the compensation mechanism in abnormal scenarios by using secure unlocking and state switching based on release commands, ensuring the only exit for abnormal fund flows and the orderly flow of the state machine.

[0134] In this embodiment of the application, the acknowledgment signal returned by the asynchronous compensation node in response to the release command is received, and the digital signature of the acknowledgment signal is verified.

[0135] Furthermore, if the verification passes, the memory address is calculated based on the serial number corresponding to the abnormal account record, and a lock destruction command is sent to the memory shard node. The memory shard node executes the lock destruction command to completely delete the account anti-duplicate lock from the memory data area.

[0136] Furthermore, it is determined in memory whether the independent accounting status queue is currently in a writable state. If the independent accounting status queue is in a writable state, the status flag is updated to the rollback processing state; if the independent accounting status queue is in a non-writable state, the status flag update request is stored in the retry buffer queue and the update operation is performed after the independent accounting status queue is restored to a writable state.

[0137] Furthermore, the rollback processing status is synchronously written to the underlying persistent accounting database to complete the closed-loop switching of the state machine.

[0138] For example, after the system verifies that the release command confirmation signal is valid, it deletes the lock object corresponding to the serial number BANK_20260419_002 from memory shard node 3, updates the queue status to the REFUNDING status code, and then synchronizes it to the database.

[0139] It should be noted that, due to the need to consider the special case where a surge in system concurrency pressure during abnormal account receivable scenarios causes momentary blocking of the independent account status queue, the specific methods are as follows, and also include: First, monitor the write latency indicator of the independent accounting status queue in real time. When the write latency indicator exceeds the preset blocking limit, determine that the independent accounting status queue is in an unwriteable state. Furthermore, update requests containing rollback processing status are encapsulated as persistent messages and written to a retry buffer queue. The blocking limit here is set to 300ms based on historical system monitoring data. When the queue write response time consistently exceeds this threshold, an unwriteable state is triggered. The retry buffer queue employs a time-based priority scheduling mechanism, sorting update requests by the timestamp of the blocking occurrence. A queue scan is performed every 100ms. When the write latency indicator of the independent accounting status queue falls below the blocking limit, persistent messages are retrieved sequentially according to the first-in-first-out principle for status update operations. Simultaneously, each persistent message is given a maximum lifespan of 24 hours. If the status update is not completed within this time, the message is automatically transferred to the exception log queue, triggering a manual intervention alarm to prevent permanent loss of status updates due to extreme blocking.

[0140] It should be noted that queue availability is determined by monitoring write latency metrics to avoid thread backlog caused by writing directly when the queue is blocked.

[0141] Furthermore, an asynchronous polling thread, independent of the main process, is started. The asynchronous polling thread scans the persistent messages in the retry buffer queue at a fixed period. Furthermore, when the asynchronous polling thread detects that the write latency of the independent accounting status queue has fallen back to the preset blocking lower limit, the asynchronous polling thread pulls persistent messages from the retry buffer queue and re-executes the operation of updating the status flag to the rollback processing status. The blocking lower limit here can be set to 100ms. When the queue write response time is consistently below this threshold, it is determined that the queue has recovered its normal write capability. Before executing the status update operation, the asynchronous polling thread will again verify whether the current status of the abnormal pending record is still ABNORMAL_PENDING. If the status has changed (e.g., it has been processed by another process), the update is abandoned and a status conflict log is recorded; if the status has not changed, the status update is executed and the persistent message is removed from the retry buffer queue. By introducing a secondary verification mechanism with a blocking lower limit, it is ensured that the status update operation is executed after the queue has fully recovered and stabilized, avoiding write failures caused by momentary fluctuations. In addition, the asynchronous polling thread will periodically check the health of messages in the retry buffer queue. For messages that are close to the 24-hour survival time threshold, an early warning notification will be triggered 30 minutes in advance so that operations and maintenance personnel can intervene before the message is transferred to the abnormal log queue, minimizing the lag in manual intervention.

[0142] It should be noted that the asynchronous polling mechanism is used to automatically retry the update operation after the queue is restored, ensuring that the rollback processing status can eventually be successfully written to the queue.

[0143] The aforementioned return processing status can be understood as the only legal proof for controlling the return of abnormal outstanding funds to their original payment method.

[0144] It should be noted that this application triggers the unlocking and status update operations through strict release conditions, which not only ensures the safe return of abnormal funds but also completely eliminates the risk of locking up abnormal records.

[0145] S44, obtain the underlying fund arrival notification message and match and verify the transaction number in the fund arrival notification message with the multi-channel payment transaction number; It should be noted that the funds arrival notification message is a confirmation signal sent by the underlying clearing network to the upper-level distribution system after the funds have actually been deposited into the target account. Matching verification refers to the process of accurately comparing the transaction number in the notification message with the multi-channel payment transaction number waiting in the system.

[0146] Among these steps, obtaining and verifying the fund arrival notification message is to confirm that the real funds have arrived, thus providing the most crucial factual basis for unlocking the anti-duplicate entry lock in the split account.

[0147] In this embodiment of the application, the fund arrival notification message is listened to and received through the underlying clearing network interface.

[0148] Furthermore, the message body of the fund arrival notification message is analyzed, and the clearing serial number field contained in the message body is extracted.

[0149] Furthermore, iterate through all independent revenue-sharing status queues that are currently in the revenue-sharing processing state, and extract the multi-channel payment transaction numbers stored in the independent revenue-sharing status queues.

[0150] Furthermore, the clearing transaction number field is compared character by character with the multi-channel payment transaction number. If they are completely consistent, a signal indicating that the matching verification has passed is output; otherwise, a signal indicating that the matching verification has failed is output.

[0151] It should be noted that this application eliminates misjudgments caused by false payment notifications by strictly matching the underlying messages with the queue flow, thus ensuring the absolute security of the unlocking operation.

[0152] S45, based on the result of the matching verification, update the status identifier in the independent accounting status queue to the fund settlement status; Understandably, this step primarily advances the status of successfully received transaction numbers in the queue to the "funds deposited" status, preparing for subsequent lock destruction and fund disbursement. Specifically, this can be achieved through the following steps: S451, in response to the event that the dedicated waiting time has expired and no fund arrival notification message has been received, the status flag of the independent account status queue is changed to abnormal pending status. It should be noted that the event of the dedicated waiting period expiring without receiving a notification message of fund arrival refers to an abnormal situation in which the matching and verification operation in step S44 has not been executed when the system timer reaches the upper limit of the dedicated waiting period. The abnormal pending status is a special status code that marks the funds as having an unknown destination and requires manual or specific compensation node intervention.

[0153] From a technical perspective, if the step of changing the status identifier to an abnormal pending account status is not executed, the transaction number will remain permanently in the pending account status, preventing the pending account anti-duplicate lock from being properly destroyed or legally transferred. This would cause a permanent deadlock in the pending account state machine at that node, and the actual funds might be in a detached state within the underlying clearing network. Failure to execute this application could lead to serious technical failures such as loss of fund control and inability to reconcile accounts. Executing this application, however, can promptly break the deadlock chain and guide the abnormal process to a safe and controllable pending account reconciliation stage.

[0154] In this embodiment of the application, a countdown timer is started for the independent accounting status queue, and the initial value of the countdown timer is set to a dedicated waiting time.

[0155] Furthermore, when the countdown timer reaches zero, it checks whether a matching verification signal for the corresponding serial number has been received.

[0156] Furthermore, if the system confirms that it has not received a matching verification pass signal, it generates a status change transaction request. The status change transaction request contains an instruction to overwrite the status identifier in the accounting process with an abnormal pending status.

[0157] Furthermore, submit a status change transaction request to forcibly change the status identifier of the independent accounting status queue to an abnormal pending status.

[0158] For example, if the countdown timer for the bank card's independent account status queue reaches 180 seconds and no notification message of funds arriving has been received, the status of that queue node will be forcibly changed to an abnormal pending account status.

[0159] It should be noted that this application effectively prevents the state machine from falling into an infinite loop due to indefinite waiting by introducing a timeout forced change mechanism, thereby improving the system's fault tolerance and self-healing capabilities.

[0160] S452, Generate abnormal account records based on abnormal account status and write the abnormal account records into an independent abnormal verification data table; It should be noted that abnormal account records are structured data containing complete contextual information such as transaction number, channel type, and account time. The abnormal verification data table is a separate database table specifically used to store abnormal account records.

[0161] The purpose of generating abnormal account records and writing them to the abnormal verification data table is to persist the transient abnormal state in memory, so that subsequent maintenance personnel or automatic verification programs can conduct account investigation and fund tracking.

[0162] In this application implementation, the transaction number that triggers the abnormal pending status, the corresponding payment identifier of each channel, the time point when the exclusive waiting time expires, and the memory snapshot data of the current queue node are collected.

[0163] Furthermore, the collected data is serialized and encapsulated according to the field format of the anomaly verification data table to generate anomaly outstanding records.

[0164] Furthermore, establish a database connection with the anomaly verification data table.

[0165] Furthermore, the abnormal outstanding records are inserted into the abnormal reconciliation data table through the database connection, and the database returns a confirmation log of successful insertion.

[0166] It should be noted that this application achieves physical data separation between normal and abnormal business flows by establishing an independent abnormal data storage structure, thereby reducing the complexity of accounting reconciliation.

[0167] S453, persistently retain the anti-duplicate lock corresponding to the abnormal account record to prevent subsequent automatic account transfer for the abnormal account record; It should be noted that persistent retention refers to transferring the anti-reentrancy lock for the accounting entries, which was originally stored in volatile memory, to persistent storage media and maintaining the locked state. Automatic accounting entries flow refers to the accounting entries instruction issuance process triggered by a scheduled task within the system without human intervention.

[0168] Conversely, if the step of persistently retaining the anti-reentrancy lock for account splitting is not performed, the anti-reentrancy lock in memory will be lost when the system's memory cache fails or a node restarts. This will cause the system to mistakenly believe that the abnormal account record is in an unlocked state, and the subsequent automatic account splitting process will issue an account splitting instruction for this abnormal account record for which no real funds have arrived, thus causing a serious risk of over-distribution of funds. Implementing this application can extend the protective effect of the lock to the persistence level, completely blocking the erroneous path of automatic account splitting.

[0169] In this embodiment, the serial number corresponding to the abnormal account record is read, and the anti-duplicate lock instance in the memory data area is located based on the serial number.

[0170] Furthermore, extract the lock holder identifier and locking timestamp from the split-account anti-duplicate lock instance.

[0171] Furthermore, the lock holder identifier and locking timestamp are written into the persistent lock management table, and the status field of the anti-reentrancy lock for the sub-account is set to persistent lock status in the persistent lock management table.

[0172] Furthermore, delete the anti-reentrancy lock instance in the memory data area. Before initiating the automatic accounting process, the system must query the persistent lock management table. If a persistent lock status is found, the accounting process will be terminated.

[0173] It should be noted that this application maintains the absolute interception capability of dangerous and abnormal records while ensuring the release of system memory resources through persistent migration of lock states.

[0174] S46, destroy the anti-re-entry lock of the account splitting data area mounted in the memory area according to the fund settlement status and trigger the distribution and transfer operation of the account splitting instruction; Understandably, this step primarily involves clearing the lock resources for normally received transaction numbers and initiating the subsequent business process of distributing funds to various sub-receivers. Specifically, this can be achieved through the following steps: S461, in response to the triggering of the distribution and transfer operation of the revenue sharing instruction, obtain the account identifier and revenue sharing amount data of each revenue sharing recipient contained in the revenue sharing instruction; It should be noted that the account identifier of the recipient is a unique number for each sub-account to which the funds will ultimately reach, and the amount of the distribution is the specific amount of funds allocated to each sub-account.

[0175] Obtaining the account identifier and amount data of each recipient is to clarify the specific target and quantity of fund distribution, providing precise instruction parameters for the underlying fund transfer operation.

[0176] In this embodiment of the application, after detecting that the status identifier of the independent account splitting status queue has changed to the fund settlement status, the distribution and transfer operation event of the account splitting instruction is triggered.

[0177] Furthermore, based on the serial number associated with the distribution and transfer operation event that triggers the revenue sharing instruction, the revenue sharing splitting rule corresponding to that serial number is extracted from the revenue sharing rule configuration library.

[0178] Furthermore, the revenue splitting rules are analyzed to extract multiple sub-account number fields and multiple sub-amount value fields contained in the revenue splitting rules.

[0179] Furthermore, the system maps multiple sub-account number fields to the account identifiers of each revenue share recipient, maps multiple sub-amount value fields to revenue share amount data, and combines the account identifiers of each revenue share recipient with the revenue share amount data to generate a list of fund disbursement tasks.

[0180] For example, the revenue splitting rules are parsed to extract the account number and amount of 100 yuan for account A and the account number and amount of 50 yuan for account B, generating a fund distribution task list containing the two sets of data.

[0181] It should be noted that this application provides a clear operational blueprint for subsequent concurrent fund allocation by accurately analyzing the revenue sharing rules and converting them into a standardized task list.

[0182] S462, Match the corresponding target fund account in the underlying split fund pool based on the account identifier and verify the available balance data of the target fund account; It should be noted that the split-payment pool is a collection of transitional accounts opened at the underlying level of the aggregated payment system for the collection and distribution of funds. The target fund account is a specific account in the split-payment pool that is bound to the account identifier of the split recipient. The available balance data is the amount of funds that can currently be used in the target fund account.

[0183] The purpose of verifying the available balance data of the target fund account is to conduct a final quota verification before the fund is disbursed, and to prevent partial accounting anomalies caused by insufficient balance in the underlying fund pool leading to disbursement failure.

[0184] In this implementation, the fund disbursement task list is traversed, and the account identifier of each revenue recipient is extracted one by one.

[0185] Furthermore, the account identifiers of each revenue-sharing recipient are sent to the underlying revenue-sharing fund pool accounting core system, which then queries the corresponding target fund account based on the binding relationship table.

[0186] Furthermore, a balance query request is sent to the accounting core system. The accounting core system reads the current total balance and the frozen balance of the target fund account, and calculates the available balance by subtracting the frozen balance from the current total balance.

[0187] Furthermore, the calculated available balance data is compared with the revenue sharing amount data in the fund allocation task list to determine whether the available balance data is greater than or equal to the revenue sharing amount data.

[0188] In an optional implementation, the available balance data mentioned above can be characterized as follows: ; In the formula, This indicates the available balance data of the target funds account. This indicates the current total balance of the target funds account. This indicates the frozen balance in the target funds account. In the formula above... and The data originates from real-time read operations performed by the core accounting system on the target fund account, and is calculated accordingly. The results are directly used in the verification and comparison process with the split amount data in step S463.

[0189] It should be noted that this application ensures that every splitting instruction is based on a solid foundation of available funds through a rigorous available balance verification mechanism.

[0190] S463, based on the available balance data to meet the verification results of the split amount data, write the split execution status of the target fund account into the account flow record to complete the fund disbursement.

[0191] It should be noted that the splitting execution status is a status field that records the final result of the action of transferring funds from the target fund account to the splitting recipient account, while the account flow record is an underlying database record that permanently saves the trajectory of fund changes.

[0192] The purpose of recording the execution status of fund allocation in the accounting records is to solidify the results of fund disbursement, making the entire fund allocation process have an unalterable audit traceability capability, thereby completely completing the final distribution of funds.

[0193] In this application implementation, the verification result confirms that the available balance data is greater than or equal to the split amount data.

[0194] Furthermore, a fund deduction and disbursement instruction is sent to the accounting core system, which executes the instruction to transfer the sub-account amount data from the target fund account to the entity account corresponding to the account identifier of each sub-account recipient.

[0195] Furthermore, after completing the fund transfer, the accounting core system generates a split execution status response message containing a success status code.

[0196] Furthermore, upon receiving the revenue sharing execution status response message, the revenue sharing execution status, the account identifier of each revenue sharing recipient, the revenue sharing amount data, and the current system timestamp are assembled into an account transaction record, and the account transaction record is inserted into the underlying account transaction database to complete the fund disbursement.

[0197] It should be noted that this application, through the recording of transaction records, brings the accounting control process to a final conclusion, ensuring the integrity and auditability of fund distribution.

[0198] like Figure 2 The diagram shown is the core overall flowchart of this application. As shown, this method eliminates the risk of over-distribution of funds and state machine deadlock in dual-channel parallel scenarios by combining channel physical isolation with dynamic latency waiting mechanism. Specifically, it includes the following four core stages: Part 1 (Channel Distribution and Physical Isolation Phase): The process begins with the triggering of an aggregated payment splitting instruction. First, it retrieves the multi-channel payment transaction numbers and payment identifiers for each channel contained in the instruction. Then, it parses the channel payment identifiers into digital RMB channel type and bank card channel type, and imports the associated multi-channel payment transaction numbers into the digital RMB independent splitting status queue and the bank card independent splitting status queue, respectively, thereby achieving state space isolation between different physical settlement channels.

[0199] Part Two (Dynamic Duration Setting Stage): Before entering the waiting mechanism, based on the historical fund transit delay data corresponding to each payment channel's payment identifier, the fund departure time and fund arrival time within multiple past settlement cycles are obtained. By calculating the average of the time differences and adding an additional buffer time interval to this average, a unique waiting duration is generated and bound to the corresponding independent settlement status queue for storage.

[0200] Part Three (Anti-re-entry Lockout and Normal Revenue Sharing Phase): For independent account allocation status queues within their designated waiting time, a locking operation is performed: a status identifier for account allocation processing is written to the current node, and an anti-re-entry lock is generated and attached to the memory data area. When the designated waiting time expires and a notification message of fund arrival from the underlying layer is received, the message serial number is matched and verified; if the verification passes, the status is updated to fund settlement status, and the anti-re-entry lock in memory is destroyed. Then, the distribution and transfer operation of the account allocation instruction is triggered, the available balance of the target fund account in the account allocation fund pool is checked, and based on the verification result that the available balance meets the account allocation amount, the execution status is written to the account transaction record to complete the fund disbursement.

[0201] Part Four (Abnormal Accounts Outstanding and Asynchronous Compensation Interception Phase): The diagram also includes key branches for handling anomalies and duplicate requests. If the dedicated waiting period expires and no fund arrival notification message is received, the status is changed to an abnormal pending status, an abnormal pending record is generated and written to a separate abnormal verification data table, and the split account anti-duplicate lock is persistently retained to prevent subsequent automatic split account transfers.

[0202] Meanwhile, when the asynchronous compensation node issues a secondary accounting instruction, it checks the memory data area to confirm the existence of the accounting anti-reentrancy lock, thereby discarding the secondary accounting instruction and returning an interception success notification.

[0203] Furthermore, if the current status is determined to be an abnormal pending account status, a release instruction is sent to the asynchronous compensation node to allow the fund return operation. Based on this release instruction, the persistent anti-reentry lock is released, and the status identifier is updated to the return processing status to ensure the safe exit of abnormal funds.

[0204] This embodiment also provides a digital payment routing intelligent accounting and management system adapted to multiple business scenarios. The system includes: The instruction response acquisition module is used to respond to the triggering of the aggregated payment split instruction and acquire the multi-channel payment transaction number and each channel payment identifier contained in the aggregated payment split instruction; The channel distribution module is used to distribute multi-channel payment serial numbers to the independent accounting status queues corresponding to each channel payment identifier based on the payment identifier of each channel. The duration determination module is used to determine the exclusive waiting duration of each independent accounting status queue based on the historical fund transit delay data corresponding to the payment identifier of each channel. The lock control execution module is used to add a debit lock to the independent debit status queue that is within a dedicated waiting period. When the dedicated waiting period expires and a real fund arrival event is received, the debit lock is released and a debit instruction is issued.

[0205] The specific timing diagram of the system is as follows: Figure 3 As shown, the contents are all described in the foregoing embodiments and will not be repeated here.

[0206] The above-mentioned unit modules can be embedded in the processor of the electronic device in hardware form or independent of it, or they can be stored in the memory of the electronic device in software form, so that the processor can call and execute the corresponding operations of the above modules.

[0207] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0208] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A digital payment routing intelligent revenue sharing and management method adaptable to multiple business scenarios, characterized in that, include: In response to the triggering of the aggregated payment splitting instruction, obtain the multi-channel payment transaction number and each channel payment identifier contained in the aggregated payment splitting instruction; Distribute multi-channel payment serial numbers to independent accounting status queues corresponding to each channel payment identifier based on the payment identifier of each channel. Based on the historical fund transit delay data corresponding to the payment identifiers of each channel, the exclusive waiting time for each independent account status queue is determined; Add a deduplication lock to the independent account splitting status queue that is within the dedicated waiting period. Release the deduplication lock and issue an account splitting instruction when the dedicated waiting period expires and a real fund arrival event is received.

2. The method as described in claim 1, characterized in that, The determination of the specific waiting time for each independent account status queue based on historical fund transit delay data corresponding to payment identifiers of each channel includes: Obtain the time points when funds leave and arrive for payment indicators from various channels within multiple past settlement cycles; Obtain the time difference between the time the funds are credited and the time the funds are debited, and then sum up multiple time differences to calculate the average value; An additional buffer time interval is added to the average value to generate a dedicated waiting time, which is then bound and stored with an independent revenue sharing status queue.

3. The method as described in claim 2, characterized in that, Adding a de-entrancy lock to the independent accounting status queue within its dedicated waiting time includes: In response to the operation of entering the independent accounting status queue in response to the accounting instruction, the status identifier in accounting processing is written to the current node of the independent accounting status queue. Generate a split-account anti-duplicate lock based on the status identifier and attach the split-account anti-duplicate lock to the memory data area corresponding to the multi-channel payment serial number; The anti-duplicate entry lock intercepts secondary transaction instructions targeting multi-channel payment serial numbers and returns a status response indicating that the instruction is being processed to the node that initiated the secondary transaction instruction.

4. The method as described in claim 3, characterized in that, The step of releasing the anti-duplicate lock and issuing a splitting instruction upon the expiration of the dedicated waiting period and the receipt of a real fund arrival event includes: Obtain the underlying fund arrival notification message and match and verify the transaction number in the fund arrival notification message with the multi-channel payment transaction number; Based on the successful matching verification, the status identifier in the independent accounting status queue will be updated to the fund settlement status. Based on the fund settlement status, the anti-duplicate lock of the sub-account mounted in the memory data area is destroyed and the distribution and transfer operation of the sub-account instruction is triggered.

5. The method as described in claim 4, characterized in that, The step of updating the status identifier in the independent accounting status queue to the fund settlement status based on the successful matching verification includes: In response to an event where the dedicated waiting period has expired and no notification message of fund arrival has been received, the status flag of the independent account status queue will be changed to an abnormal pending account status. Based on the abnormal account status, abnormal account records are generated and written into a separate abnormal account verification data table; The anti-duplicate lock corresponding to the abnormal account records is persistently retained to prevent subsequent automatic account transfer for abnormal account records.

6. The method as described in claim 5, characterized in that, The step of intercepting secondary transaction splitting instructions targeting multi-channel payment serial numbers based on the transaction splitting anti-duplicate lock and returning a status response indicating that the instruction is being processed to the node that initiated the secondary transaction splitting instruction includes: Obtain the secondary revenue sharing instruction issued by the asynchronous compensation node and parse the secondary revenue sharing instruction to extract the compensation trigger source identifier and the compensation target serial number; Based on the compensation trigger source identifier and the compensation target serial number, query whether there is a split-account anti-duplicate lock in the memory data area corresponding to the multi-channel payment serial number; Based on the existence of a split-account anti-re-entry lock in the memory data area, the query result discards the secondary split-account instruction and returns a successful interception notification to the asynchronous compensation node.

7. The method as described in claim 6, characterized in that, The query result based on the existence of a re-entry lock for accounting division in the memory data region discards the secondary accounting division instruction and returns a successful interception notification to the asynchronous compensation node, including: In response to the pending account status query request initiated by the asynchronous compensation node after receiving the interception success notification, obtain the current status identifier of the independent account status queue; Based on the determination result that the current status is marked as an abnormal pending account, a release instruction is sent to the asynchronous compensation node to allow the fund return operation to be performed; The release command releases the anti-duplicate lock on the abnormal posting record and updates the status flag of the independent posting status queue to the return processing status.

8. The method as described in claim 7, characterized in that, The step of distributing multi-channel payment transaction numbers to independent accounting status queues corresponding to each channel payment identifier based on the payment identifier of each channel includes: The channel payment identifier contained in the aggregated payment splitting instruction is parsed into digital RMB channel type and bank card channel type; Import the associated multi-channel payment serial number into the independent digital RMB account status queue according to the digital RMB channel type; Based on the bank card channel type, the associated multi-channel payment serial number is imported into the bank card's independent accounting status queue to achieve state space isolation between different physical settlement channels.

9. The method as described in claim 8, characterized in that, The step of destroying the anti-duplicate lock mounted in the memory data area based on the fund settlement status and triggering the distribution and transfer of settlement instructions includes: In response to the triggering of the distribution and transfer operation of the revenue sharing instruction, obtain the account identifier and revenue sharing amount data of each revenue sharing recipient contained in the revenue sharing instruction; Based on the account identifier, match the corresponding target fund account in the underlying split fund pool and verify the available balance data of the target fund account; Based on the available balance data and the verification results of the split amount data, the split execution status of the target fund account is written into the account transaction record to complete the fund disbursement.

10. A digital payment routing intelligent accounting and management system adaptable to multiple business scenarios, using the method described in any one of claims 1 to 9, characterized in that, include: The instruction response acquisition module is used to respond to the triggering of the aggregated payment split instruction and acquire the multi-channel payment transaction number and each channel payment identifier contained in the aggregated payment split instruction; The channel distribution module is used to distribute multi-channel payment serial numbers to the independent accounting status queues corresponding to each channel payment identifier based on the payment identifier of each channel. The duration determination module is used to determine the exclusive waiting duration of each independent accounting status queue based on the historical fund transit delay data corresponding to the payment identifier of each channel. The lock control execution module is used to add a debit lock to the independent debit status queue that is within a dedicated waiting period. When the dedicated waiting period expires and a real fund arrival event is received, the debit lock is released and a debit instruction is issued.

Images