Collection system and method supporting fusion of multiple payment channels

Abstract

The invention relates to the technical field of electronic commerce, in particular to a collection system and method supporting fusion of multiple payment channels, and the system comprises a parameter collection module, a weight sorting module, a main account book writing module, a time delay recognition module and an asynchronous synchronization module. According to the invention, a standardized transaction time and amount processing mechanism is introduced in a collection behavior access stage, the basis of transaction parameter uniformity under different payment channels is improved, the weighted entropy value is constructed in combination with the transaction amount and the access time, and the transactions are sorted. The problem that the priority of multi-channel access transaction processing is not clear in a traditional sequence is avoided, the distribution rule of transaction processing time delay is identified by constructing an account book write-in processing time delay set and introducing a probability density modeling mode, and accurate screening of transaction synchronization sections is achieved. And a channel type association mapping mode is introduced in an asynchronous account book reconciliation and restoration link to ensure consistent output of data, so that the multi-channel fusion processing efficiency and the accounting consistency accuracy are effectively improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of electronic commerce, and in particular to a collection system and method supporting multi-payment channel integration. BACKGROUND

[0002] The technical field of electronic commerce involves a series of business activities such as online display, selection, transaction, payment and after-sales management of goods and services based on an Internet platform.

[0003] Among them, the collection system supporting multi-payment channel integration refers to a system for processing collection requests of multiple different payment methods such as bank card payment, third-party payment platform, and electronic wallet, simultaneously accessing multiple payment channels in a single platform, and realizing identification, forwarding and confirmation of payment requests.

[0004] The prior art only processes transaction requests in the order of access in the multi-payment channel integration process, lacks dynamic evaluation means for multi-dimensional parameters such as transaction amount and access time, and is prone to delayed processing of high-value transactions when the concurrency is high or the access rhythm is uneven. In addition, the processing time difference of the collection request written into the main account book is not fully monitored and identified, making it difficult to discover processing bottlenecks or synchronization imbalance problems in time. In the asynchronous account book synchronization and reconciliation process, there is also no unified logical path to identify transaction status and channel ownership, which is easy to cause confusion of cross-channel transaction records and result in reconciliation result deviation. In the actual scenario of multiple third-party payment channel access and high-frequency transactions, these deficiencies will directly affect the integrity of the account book data and the accuracy of the reconciliation operation. SUMMARY

[0005] The purpose of the present application is to solve the shortcomings in the prior art and to provide a collection system and method supporting multi-payment channel integration.

[0006] In order to achieve the above purpose, the present application adopts the following technical solution: a collection system supporting multi-payment channel integration comprises:

[0007] A parameter collection module acquires the access time and transaction amount of each transaction in the collection behavior access stage, and constructs a transaction parameter set;

[0008] A weight ordering module calculates the weighted entropy value of each transaction according to the transaction parameter set, and sorts all transactions according to the entropy value to obtain a collection order instruction set;

[0009] A main account book writing module writes each transaction into the main transaction account book in sequence according to the collection order instruction set and records the transaction confirmation time, compares the writing processing time delay with the access time of the corresponding transaction to obtain an account book writing processing time delay set;

[0010] The time delay identification module inputs the account book writing processing time delay set into a Bayesian Gaussian mixture model, calculates the probability density distribution of each type of time delay in the whole writing processing time delay, and identifies a time delay aggregation interval, and screens a synchronous collection sequence section;

[0011] The asynchronous synchronization module obtains the writing record of the main transaction account book corresponding to each transaction in the synchronous collection sequence section, synchronously writes the main account book transaction content into a designated asynchronous account book for channel reconciliation and account restoration, and outputs fusion collection data.

[0012] As a further scheme of the application, the transaction parameter set is specifically a standardized access time, a standardized transaction amount, and a transaction number index, the collection order instruction set includes an order position, a transaction number order, and a weighted entropy value, the account book writing processing time delay set includes a processing time length, a transaction confirmation time, and an access record index, the synchronous collection sequence section includes a transaction number interval, a stable time delay category, and a model output label, and the fusion collection data is specifically an asynchronous account book writing state, a channel account book positioning result, and a transaction synchronization result identifier.

[0013] As a further scheme of the application, the parameter collection module includes:

[0014] The time standardization submodule obtains the access time of each transaction in the collection behavior access stage, performs unified format conversion on the access time, and generates a time standardization value;

[0015] The amount standardization submodule calls the transaction number of the time standardization value to obtain the transaction amount of the corresponding transaction, converts each amount value into an expression form in a consistent scale, and generates an amount standardization value;

[0016] The transaction parameter summary submodule establishes a corresponding transaction number relationship according to the time standardization value and the amount standardization value, and generates a transaction parameter set.

[0017] As a further scheme of the application, the weight ordering module includes:

[0018] The transaction parameter extraction submodule calls the amount standardization value corresponding to each transaction in the transaction parameter set to construct a standardized parameter set;

[0019] The entropy value calculation submodule extracts the amount value corresponding to each transaction of the standardized parameter set, statistics the distribution proportion of all transactions on the amount value, calculates the information entropy of each transaction in terms of the amount based on the distribution proportion, combines according to a fixed weight proportion, and generates a weighted entropy value set;

[0020] The sorting instruction generation submodule generates a collection of payment order instructions by prioritizing and marking the corresponding time standardized values according to the entropy values of each transaction in the collection of weighted entropy values.

[0021] As a further scheme of the present application, the main ledger writing module comprises:

[0022] The ledger writing execution submodule sequentially submits the corresponding transaction content to the main transaction ledger according to the transaction number order in the collection of payment order instructions, and generates a main ledger writing sequence.

[0023] The confirmation time collection submodule obtains the transaction confirmation time fed back by the main transaction ledger based on each transaction in the main ledger writing sequence, and records the transaction number, and generates a collection of transaction confirmation times.

[0024] The processing delay calculation submodule calculates the time difference between the confirmation time of each transaction in the collection of transaction confirmation times and the access time of the corresponding transaction in the transaction parameter collection, and arranges and summarizes the time difference results of all transactions in order to generate a collection of ledger writing processing delays.

[0025] As a further scheme of the present application, the delay identification module comprises:

[0026] The model input preprocessing submodule obtains the processing delay values of all transactions in the collection of ledger writing processing delays, constructs a delay data vector in order, and generates a model processing input collection.

[0027] The density distribution identification submodule calls a variational Bayesian Gaussian mixture model to divide the probability density of the delay data according to the processing delay values in the model processing input collection, judges the distribution concentration degree of each type of processing delay in the whole according to the model output, and generates delay density aggregation information.

[0028] The sequence segment screening submodule identifies a transaction number continuous segment with concentrated density characteristics according to the distribution interval of each type of processing delay in the delay density aggregation information, and generates a synchronous payment sequence segment.

[0029] As a further scheme of the present application, the asynchronous synchronization module comprises:

[0030] The main ledger content extraction submodule obtains the number information of each transaction in the synchronous payment sequence segment, calls the writing record of the corresponding number in the main transaction ledger, and generates a collection of main ledger transaction contents.

[0031] An asynchronous ledger writing matching sub-module matches each transaction in the main ledger transaction content set to a corresponding ledger instance in the configured asynchronous ledger set according to the channel type information corresponding to each transaction, writes each transaction content into the corresponding asynchronous ledger, and generates an asynchronous ledger writing result set;

[0032] A payout data aggregation output sub-module arranges the writing results according to the channel dimension, summarizes the synchronization and transaction data writing state of all ledgers, and generates fusion payout data according to the processing state of each asynchronous ledger in the asynchronous ledger writing result set.

[0033] A payout method supporting multi-payment channel fusion is executed based on the above-mentioned payout system supporting multi-payment channel fusion, comprising the following steps:

[0034] S1: In the access stage of the payout behavior, the access time and transaction amount of each transaction are obtained, and a transaction parameter set is constructed;

[0035] S2: The access time and transaction amount of each transaction in the transaction parameter set are extracted and normalized, the weighted entropy value of each transaction is calculated, the all transactions are sorted according to the entropy value, and a collection of payout sequence instructions is obtained;

[0036] S3: According to the collection of payout sequence instructions, each transaction is written into the main transaction ledger in turn and the transaction confirmation time is recorded, the writing processing time delay is calculated by comparing the access time of the corresponding transaction, and a collection of ledger writing processing time delay is obtained;

[0037] S4: The collection of ledger writing processing time delay is input into the Bayesian Gaussian mixture model, the probability density distribution of each type of delay in the entire writing processing time delay is calculated, and the delay aggregation interval is identified, and the synchronous payout sequence section is screened;

[0038] S5: The writing record of the main transaction ledger corresponding to each transaction in the synchronous payout sequence section is obtained, the main ledger transaction content is written into the specified asynchronous ledger for channel reconciliation and account restoration, and fusion payout data is output.

[0039] Compared with the prior art, the advantages and positive effects of the present application are:

[0040] This invention improves the consistency of transaction parameters across different payment channels by introducing a standardized mechanism for processing transaction time and amount during the payment access phase. By combining transaction amount and access time to construct a weighted entropy value and sorting transactions, it effectively avoids the problem of unclear priority in multi-channel access transaction processing under traditional sequential processing. By constructing a set of ledger writing processing delays and introducing probability density modeling to identify the distribution patterns of transaction processing delays, it achieves precise filtering of synchronous transaction segments. In the asynchronous ledger reconciliation and restoration phase, a channel type association mapping method is introduced to ensure consistent data output. Ultimately, this achieves coordination and unification of cross-payment channel transaction data in terms of temporal sequence and ledger ownership, effectively improving the efficiency of multi-channel fusion processing and the accuracy of accounting consistency. It also reduces the risk of data misordering and reconciliation conflicts caused by differences in channel processing, enhancing the overall stability and settlement reliability of the multi-channel payment system. Attached Figure Description

[0041] Figure 1 This is a system flowchart of the present invention;

[0042] Figure 2 This is a flowchart of the parameter acquisition module of the present invention;

[0043] Figure 3 This is a flowchart of the weight sorting module of the present invention;

[0044] Figure 4 This is a flowchart of the master ledger writing module of the present invention;

[0045] Figure 5 This is a flowchart of the delay identification module of the present invention;

[0046] Figure 6 This is a flowchart of the asynchronous synchronization module of the present invention. Detailed Implementation

[0047] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0048] Please see Figure 1 This invention provides a technical solution: a payment system supporting the integration of multiple payment channels, comprising:

[0049] The parameter acquisition module obtains the access time and transaction amount of each transaction during the payment behavior access phase and constructs a set of transaction parameters.

[0050] The weighted sorting module calculates the weighted entropy value of each transaction based on the transaction parameter set, sorts all transactions by reference to the entropy value, and obtains the payment order instruction set.

[0051] a main account book writing module, configured to write each transaction into a main transaction account book according to the collection order instruction set and record a transaction confirmation time, compare the access time corresponding to the transaction with the writing processing time lag to obtain a set of account book writing processing time lags;

[0052] a time lag identification module, configured to input the set of account book writing processing time lags into a Bayesian Gaussian mixture model, calculate the probability density distribution of each type of time lag in the entire writing processing time lag, and identify a time lag aggregation interval and filter a synchronous collection sequence section;

[0053] an asynchronous synchronization module, configured to obtain the writing record of each transaction in the main transaction account book in the synchronous collection sequence section, write the main account book transaction content into a specified asynchronous account book to perform channel reconciliation and account restoration, and output fused collection data;

[0054] The transaction parameter set is specifically a standardized access time, a standardized transaction amount, and a transaction number index. The collection order instruction set includes an order position, a transaction number order, and a weighted entropy value. The account book writing processing time lag set includes a processing time length, a transaction confirmation time, and an access record index. The synchronous collection sequence section includes a transaction number interval, a stable time lag category, and a model output label. The fused collection data is specifically an asynchronous account book writing state, a channel account book positioning result, and a transaction synchronization result identifier.

[0055] Please refer to Figure 2 The parameter acquisition module includes:

[0056] a time standardization submodule, configured to obtain the access time of each transaction in the collection behavior access stage, perform unified format conversion on the access time, and generate a time standardization value;

[0057] To obtain the access time of each transaction during the payment collection access phase, the system first needs to retrieve the original transaction logs for that phase from the access system. These logs typically contain information such as transaction number, user ID, transaction timestamp, and channel source. The system then needs to extract the transaction time field using regular expression matching and identify valid time data according to preset time field naming rules. For example, when fields such as "transaction_time" and "create_at" exist, it's necessary to first determine if they are empty or if there are any time format discrepancies. Fields with abnormal time formats are uniformly identified and processed; common formats include "YYYY-MM-DDHH:MM:SS" or ISO. The 8601 standard format, after being identified, requires a unified format conversion step. The conversion can rely on preset time template mapping rules. For example, "July 30, 2025, 10:12 AM" requires the recognition of Chinese characters for "year", "month", and "day" and mapping them to the corresponding Arabic numeral format. After conversion, it is unified into a standard timestamp format and then stored in the database as a Unix timestamp or datetime object. The final standardized time value needs to be bound to the transaction number. The system will establish a key-value relationship between the transaction number and the standard time value and write it into the time standardization result set.

[0058] The amount standardization submodule calls the transaction number of the time-standardized value to obtain the transaction amount of the corresponding transaction, converts each amount value into an expression form under a consistent scale, and generates an amount standardization value.

[0059] According to the time standardized value, the corresponding transaction number list is obtained. The system first traverses the time standardization result set, extracts all valid transaction numbers, and then takes the number as an index to retrieve the corresponding transaction amount field in the original transaction record database. The field may be stored in the form of "amount", "pay_value", "total_price", etc. The system needs to match the field name to extract according to the transaction data table structure. After successfully extracting the amount field, it needs to be uniformly scaled and converted. The scale conversion can be based on currency units, payment channels, discount factors, and whether to include tax information. For example, in the mixed scenario of RMB and USD transactions, the system needs to determine the currency type and perform exchange rate conversion operations. At the same time, consider whether there is a discount field or a preferential field. If so, the original amount value needs to be adjusted after discount. The discount calculation needs to call the original amount and discount rate field to calculate the final amount through "adjusted amount = original amount x (1-discount rate)", and then convert the amount to a base currency unit based on the current exchange rate information. If the base currency is RMB, the exchange rate is executed with the daily updated middle price. Finally, all the amount values will be standardized under the unified currency, unified discount, and unified tax status to form the amount standardized value. The system then binds the standardized amount and the corresponding transaction number to form a binding structure and stores it.

[0060] The transaction parameter summary submodule establishes the corresponding transaction number relationship based on the time standardized value and the amount standardized value, and generates a transaction parameter set.

[0061] According to the time standardized value and the amount standardized value, and establishing the corresponding transaction number mapping relationship, the system first traverses the time standardized set and the amount standardized set during the execution process, takes the transaction number as the index key, combines and splices the time value and the amount value, and generates a parameter record object. The object includes: transaction number, standardized timestamp, standardized amount. The system needs to determine whether there is a transaction number missing or a standardized field missing during the splicing process. If a transaction number exists in the two submodule result sets at different times, it needs to be recorded as an exception and skipped. After successful splicing, the system stores all transaction parameter sets in the parameter mapping table, and generates a structured data set based on the table.

[0062] Please refer to Figure 3 , the weight sorting module includes:

[0063] The transaction parameter extraction submodule calls the amount standardized value corresponding to each transaction in the transaction parameter set to construct a standardized parameter set.

[0064] After receiving the transaction parameter set, the two key fields contained in each transaction in the set, namely the time standardized value and the amount standardized value, are first identified. The system needs to traverse the entire transaction parameter set and extract the two fields corresponding to all transaction numbers, and then perform normalization processing. The first step of normalization is to determine the normalization method. Usually, the system will preset to use linear mapping or interval compression method to map the value to a unified range, commonly to the closed interval of 0 to 1. The system will internally determine the maximum and minimum values of the selected field, and perform normalization mapping according to the range. The normalization process does not directly change the original data, but stores a normalized result as a new field in the transaction parameter set. In order to improve the rationality of normalization, the system may process abnormal values, such as removing large or small values before performing main interval mapping. In addition, the time field will be converted to a relative time interval value based on a fixed date before being normalized, such as converting the time field in the form of "2025-07-3010:12:00" to a relative time interval value based on a fixed date, and then performing interval scaling. The amount field needs to ensure that all units and after-tax states are consistent before normalization to avoid affecting the normalization result due to inconsistent scales.

[0065] The entropy value calculation submodule extracts the amount value corresponding to each transaction in the standardized parameter set, calculates the distribution proportion of all transactions in the amount value, calculates the information entropy of each transaction in the amount based on the distribution proportion, combines according to a fixed weight ratio, and generates a weighted entropy value set;

[0066] First, the normalized amount value of each transaction is extracted from the standardized parameter set to construct an amount normalization sequence. Then, the system performs frequency statistics and normalization probability distribution calculation on all transaction amounts in the sequence. In this process, in order to reduce the probability extreme interference caused by discrete distribution, the system introduces a smoothing factor to adjust the normalization proportion of each amount, ensuring that all probability values are within a non-zero range. The specific execution steps are as follows: the system first calculates the proportion of each transaction amount in the amount value sequence in all transactions. Let the transaction number be i, the total number of transactions be n, the i-th transaction amount normalization value be x i , and the sum of all transaction amount normalization values be The distribution proportion after introducing a smoothing parameter a>0 is defined as: Where i represents the number of the i-th transaction, which is unique and corresponds to the transaction number in the standardized parameter set generated earlier; n represents the total number of transactions, i.e. the total number of all transaction samples participating in the calculation in the current batch, determined by the size of the parameter set; x i : the normalized amount value of the i-th transaction, derived from the result after normalization conversion from the "amount standardization submodule", usually compressed in the [0,1] interval; x j: is the normalized amount value of the jth transaction, j belongs to all transaction sample numbers, participating in the total sum calculation; is the sum of all transaction amount normalized values plus the smoothing factor, used to construct the complete probability distribution; a: is the smoothing factor, set as a constant less than 1, to prevent the log(0) abnormality caused by the normalized amount of a transaction being 0, and a small positive value is added by human intervention to correct the minimum probability error.

[0067] Then, the system calculates the entropy value of each transaction based on the amount distribution, and the information entropy is performed by a logarithmic function, and the entropy value is defined as: H i = -p i ·log(p i ); where H i : is the entropy value of the ith transaction based on the amount distribution, indicating the information uncertainty carried by the transaction in the overall distribution; p i : is the probability value as described above, indicating the proportion of the ith transaction amount in all transactions, adjusted by smoothing; log(p i ): is the logarithmic value of p i , used to quantify the discrete degree of its proportion.

[0068] To improve the response ability of entropy value calculation to transaction volatility, the system further introduces a volatility weighting factor λ, which depends on the fluctuation amplitude of the transaction amount relative to the mean value in the normalized sequence. Let the standard deviation be σ, then the amount volatility factor of the ith transaction is defined as: where λ i : is the volatility weighting factor of the ith transaction, measuring the deviation degree of the transaction amount relative to other transaction amounts; x i : is the normalized amount value of the ith transaction as before; is the mean value of the normalized amount sequence, indicating the overall average level of all transaction amounts; σ: is the standard deviation of the normalized amount sequence, reflecting the overall volatility level of the transaction amount after normalization; is the absolute difference between the normalized value of the transaction amount and the mean value, used to construct the deviation measure.

[0069] The final weighted entropy value E i is expressed as:

[0070]

[0071] where: E i : is the weighted entropy value of the ith transaction.

[0072] Suppose the amount of five transactions is standardized and normalized as follows: x1 = 0.20, x2 = 0.30, x3 = 0.10, x4 = 0.25, x5 = 0.15, and set the smoothing factor a = 0.01.

[0073] Sum of normalized amount value plus smoothing factor:

[0074]

[0075] Calculate smoothed probability value for each transaction:

[0076] Calculate information entropy value for each transaction:

[0077] H1 = -p1 · ln(p1) = -0.2000 · ln(0.2000) ≈ 0.3219;

[0078] H2 = -0.2952 · ln(0.2952) ≈ 0.3608;

[0079] H3 = -0.1048 · ln(0.1048) ≈ 0.2352;

[0080] H4 = -0.2476 · ln(0.2476) ≈ 0.3432;

[0081] H5 = -0.1524 · ln(0.1524) ≈ 0.2876;

[0082] Calculate average of normalized amount values:

[0083] Calculate standard deviation of normalized amount values:

[0084]

[0085] Calculate volatility weight coefficient λ for each transaction i :

[0086]

[0087] Calculate weighted entropy value E i = λ i · H i :

[0088] E1 = 1 · 0.3219 = 0.3219;

[0089] E2 = 2.387 · 0.3608 ≈ 0.8610;

[0090] E3 = 2.387 · 0.2352 ≈ 0.5611;

[0091] E4 = 1.694 · 0.3432 ≈ 0.5816;

[0092] E5 = 1.694 · 0.2876 ≈ 0.4875;

[0093] Bind the above five weighted entropy values to the corresponding transaction number, form the following structure: TID1→

[0094] 0.3219, TID2→ 0.8610, TID3→ 0.5611, TID4→ 0.5816, TID5→ 0.4875.

[0095] First, by smoothing the normalized amount of each transaction, the proportion of all transactions is calculated, which reflects the relative position of the transaction in the amount distribution, preventing some extremely small or zero values from interfering with subsequent calculations; Subsequently, based on the proportion value of each transaction, the degree of uncertainty is calculated by information entropy, which reflects the distinguishing ability of the transaction in the amount dimension. The more evenly the proportion is, the higher the uncertainty is, and the greater the entropy value is; Next, in order to consider the deviation between each transaction and the average level, the amount fluctuation factor is introduced, which measures the deviation strength of the transaction and the total transaction amount, and gives the fluctuation sensitivity to adjust the weight of the transaction entropy value; Finally, by multiplying the entropy value of each transaction with its fluctuation factor, the weighted entropy value is obtained, which not only reflects the importance of the transaction in the overall amount distribution, but also reflects the difference degree of the transaction from the mainstream amount. The whole process starts from the normalization of the original amount, goes through the links of probability modeling, information entropy calculation, fluctuation correction, etc., and forms a structured quantitative index that can be used for sorting and priority division.

[0096] The sorting instruction generation submodule sorts the priority according to the entropy value of each transaction in the weighted entropy value set and marks the corresponding time standardized value, and generates a collection of collection order instructions;

[0097] First, the weighted entropy value corresponding to each transaction in the set is extracted, and a corresponding relationship is established with the unique number of the transaction. On the premise of ensuring the integrity of the set data, the weighted entropy values of all transactions are sorted from large to small. In the sorting process, the system takes the entropy value as the main priority basis. The sorting algorithm can use quicksort, merge sort or more stable heap sort, etc. to ensure the consistency and efficiency of the sorting result. After sorting, the system matches the time standardized value corresponding to the transaction number of each transaction in turn, obtains the standardized time information when the transaction first accesses the system, and takes it as the time reference point of the collection operation. Combined with the sorting order, a complete collection instruction set is generated. Each instruction includes three items: sorting number, transaction number and time standardized value, which represents the processing order in the collection process. At the same time, the system will number the sorting number after generating the sorting result, from the first priority to the last one in turn, to ensure that the execution system can execute the collection task according to the priority. For example, if the weighted entropy value of transaction number TID003 is the highest and it is located at the first place after sorting, its corresponding time standardized value is "2025-07-30

[0098] 10:12:00", then the first instruction in the collection instruction set is "number 1, transaction TID003, collection time 2025-07-30 10:12:00". All subsequent instructions are generated in the same way to form a complete collection order instruction set.

[0099] Referring to Figure 4 , the main account book writing module comprises:

[0100] The account book writing execution submodule submits the corresponding transaction content to the main transaction account book in turn according to the transaction number sequence in the collection order instruction set, and generates a main account book writing sequence.

[0101] After receiving the collection order instruction set, the system will retrieve the complete parameter content of each transaction in order of priority of the transaction number in the set, from beginning to end, including standardized time, amount, transaction identification and other fields, and then submit these transaction data in a structured format to the main transaction ledger for registration. The main transaction ledger is the core database module of the entire system for storing formal transaction records, with the characteristics of integrity, non-tamperability and operation traceability, and is usually pre-configured by the system and combined with the permission management module to ensure the accuracy and consistency of the data. The main ledger is generally built based on a distributed database or an encrypted evidence platform, with real-time writing capability and transaction status feedback mechanism. During the writing process, the system submits transactions one by one according to the collection order, and after completing the submission operation of each transaction, it receives the status code or write identifier returned by the main ledger, indicating that the transaction has been successfully received by the main ledger. At the same time, the system generates a ledger write sequence identifier for each submitted transaction and records the order of the processed transactions in the ledger write sequence.

[0102] A confirmation time collection submodule, based on each transaction in the main ledger write sequence, obtains the transaction confirmation time feedback from the main transaction ledger and records it according to the transaction number, generating a transaction confirmation time set;

[0103] Taking the ledger write sequence as the basic input, each transaction record that has been successfully submitted to the main transaction ledger is processed. The specific operation is that the system sends a status query request to the main ledger to obtain the exact time point when each transaction completes formal registration in the ledger. After the transaction data is successfully accepted by the main ledger, it will store the transaction registration time in the form of transaction processing logs or block write time, which is usually an internal system field in the ledger and can be accurately queried by transaction number or ledger sequence number. The system obtains these time records one by one, extracts the transaction confirmation time and stores it according to the transaction number. Each transaction corresponds to a unique confirmation time. The confirmation time represents the time when the main ledger acknowledges and completes the transaction, usually output in a unified system time format such as timestamp or date-time object. All confirmation time data will be collected and arranged to form a transaction confirmation time set.

[0104] A processing delay calculation submodule, according to the confirmation time of each transaction in the transaction confirmation time set, and the access time of the corresponding transaction in the transaction parameter set, the difference is calculated, and the time difference results of all transactions are arranged and summarized according to the number order to generate a ledger write processing delay set;

[0105] The transaction confirmation time set and the transaction parameter set are used as double input sources to perform the processing delay calculation task of each transaction. First, the system extracts the standardized access time of each transaction from the transaction parameter set, which represents the starting time when the transaction is first identified and stored in the system, and then finds the confirmation time of the corresponding transaction number in the confirmation time set. For each transaction, the system calculates the difference between the confirmation time and the access time to obtain the delay time between the access and the final entry of the transaction. The difference can be expressed in the form of time interval, such as seconds or minutes, depending on the system configuration. The system needs to perform this difference operation on all transactions in order according to the transaction number, and summarize the calculation results to ensure that the processing time delay record of each transaction is clear and traceable. During the operation, the system needs to consider the possibility of write failure or confirmation failure transaction, and needs to mark the records that fail to match in the confirmation time set as abnormal and skip processing to avoid affecting the overall delay statistical result. The final output is the set of account writing processing delays.

[0106] Please refer to Figure 5 , the delay identification module comprises:

[0107] The model input preprocessing submodule obtains the processing delay values of all transactions in the account writing processing delay set, constructs a delay data vector in order of number, and generates a model processing input set;

[0108] First, the processing delay of each transaction is read according to the order of transaction number. The delay is the time interval from the initial access of the transaction to the final confirmation of the entry, usually recorded in units of seconds, minutes or milliseconds. After the system reads these data, it constructs a one-dimensional data vector according to the number arrangement, maintains the consistency and continuity of the transaction order, and ensures that the data has a traceable mapping relationship with the original transaction sequence. During the construction process, the system automatically identifies and removes missing values or invalid time value records to ensure that only valid data is included in the input vector. In addition, part of the data with inconsistent units is converted to ensure the consistency of the overall numerical scale.

[0109] The density distribution identification submodule calls the variational Bayesian Gaussian mixture model to divide the delay data according to the processing delay values in the model processing input set, judges the distribution concentration degree of each type of processing delay in the whole according to the model output, and generates delay density aggregation information;

[0110] After receiving the model processing input set, the variational Bayesian Gaussian mixture model is used to model and analyze the ledger write processing delay data. The core goal is to use the distribution form of the delay value in the vector space to mine the density aggregation area with potential rules. The system first inputs all processing delay values as continuous observation data, initializes several Gaussian distributions as candidate components, and then continuously optimizes the parameters of each Gaussian component through variational inference mechanism, and finally forms the density decomposition expression of the overall delay data distribution.

[0111] In the modeling process, the system assumes that the observation sample is composed of multiple latent Gaussian distributions, and the probability of each sample belonging to a Gaussian component is automatically estimated by the model. The model is expressed using the following structure:

[0112] For each transaction sample, its density is represented as the weighted superposition of several Gaussian distributions, and the calculation expression is as follows:

[0113] Where p(t): represents the joint probability density of any specific transaction processing delay value t under the overall model, which is the basis for the system to determine which aggregation interval the delay belongs to; t: is the processing delay value of a specific transaction, which comes from the original data in the previous ledger write processing delay set; represents that the model uses K latent Gaussian components for linear combination of the overall density, and the sum represents the overall density value of the transaction delay; K: is the number of Gaussian distributions automatically estimated or set by the system, representing the number of different delay aggregation categories in the model, which is usually determined based on data complexity and sparsity; π k : is the mixing weight of the kth Gaussian component, representing the proportion of this category in all transactions, which is continuously updated by the system in the training stage through variational Bayesian inference, and is constrained between 0 and 1, and the sum of the weights of all categories must be 1, reflecting the representativeness of each delay category; represents the probability density function of the kth Gaussian distribution, which is used to measure the probability of the delay value t appearing in this distribution, where: μ k : is the mean of the kth Gaussian distribution, representing the centralized processing delay position of this category, which is consistent with the unit of the input delay; is the variance of the kth Gaussian distribution, reflecting the dispersion degree of the transaction processing delay within this category, and the smaller the variance, the more obvious the aggregation; the function overall that is, the probability density estimate value under the condition of this mean and variance when the processing delay is t.

[0114] The model estimates all the above parameters by introducing a variational Bayesian inference method, trains the overall structure using a marginal likelihood lower bound maximization strategy, dynamically updates the mean, variance and weight of each component in each iteration, and combines the Dirichlet prior to shrink the component weight, thereby effectively avoiding overfitting. The system calculates the attribution degree of each transaction processing delay on each Gaussian distribution to obtain the probability distribution of the corresponding category, and then divides it into the corresponding category according to the maximum probability principle.

[0115] Using 5 transaction processing delay values as input, the input data (transaction processing delay) transaction number 1: 12 seconds, transaction number 2: 15 seconds, transaction number 3: 13 seconds, transaction number 4: 28 seconds, transaction number 5: 30 seconds. Model setting: use two processing behavior distribution intervals for identification, transaction behavior A (fast processing class): center processing delay (mean) is 13, fluctuation range (standard deviation) is 1 (variance is 1.0), transaction proportion (mixing weight) is 0.6; transaction behavior B (slow processing class): center processing delay is 29, standard deviation is 1 (variance is 1.0), mixing weight is 0.4.

[0116] Substitute transaction number 1 (12 seconds) into the formula, first calculate the density value under transaction behavior A:

[0117]

[0118] Then multiply the A class weight: 0.6·0.2419=0.1451;

[0119] Then calculate the density value under transaction behavior B:

[0120]

[0121] Multiply the B class weight: 0.4·0=0;

[0122] The final joint density value is: p(12)=0.1451+0=0.1451;

[0123] Attribution probability: probability of belonging to behavior A=0.1451 / 0.1451=1, probability of belonging to behavior B=0 / 0.1451=0.

[0124] Substitute transaction number 4 (28 seconds) into the formula, first calculate the density under behavior A:

[0125]

[0126] Multiply the weight: 0.6·0=0;

[0127] The density under behavior B is calculated again: N(28|29, 1.0) = 0.3989 * exp(-0.5) = 0.3989 * 0.6065 = 0.2419;

[0128] The weight is multiplied: 0.4 * 0.2419 = 0.0968;

[0129] The joint density value is: p(28) = 0 + 0.0968 = 0.0968;

[0130] The attribution probability is: the probability of belonging to behavior A = 0 / 0.0968 = 0, the probability of belonging to behavior B = 0.0968 / 0.0968 = 1.

[0131] The formula is substituted for transaction number 3 (13 seconds):

[0132]

[0133] The weight is multiplied: 0.6 * 0.3989 = 0.2393;

[0134] The behavior B is seen again: N(13|29, 1.0) = 0.3989 * exp(-128) ≈ 0;

[0135] The weight is multiplied: 0.4 * 0 = 0;

[0136] The joint density is: p(13) = 0.2393 + 0 = 0.2393;

[0137] The attribution probability is: behavior A: 1, behavior B: 0.

[0138] Each transaction is fully density value substituted, probability evaluated and attribution judged between the two typical transaction processing latency behaviors, and the final model aggregates these processing results to form: one type of aggregated transactions is the fast response type, centered at 13 seconds, containing transaction numbers 1, 2, and 3, and one type of aggregated transactions is the slow response type, centered at 29 seconds, containing transaction numbers 4 and 5. The system outputs the density interval, attribution transaction number, transaction proportion and other information of each type accordingly.

[0139] Firstly, the system constructs a density model according to the central time delay, fluctuation range and occurrence frequency of each type of transaction behavior, which is used to measure the possibility of any transaction time delay data in each behavior. Then, the system substitutes the actual time delay of each transaction into each type of distribution model in turn, calculates its density value in different behaviors, and obtains the total density of the transaction under all behavior models by combining the corresponding behavior proportion. By comparing the density proportion of each behavior, the system determines the most likely behavior type of the transaction. This process not only reveals the structural attribution of different transactions in the overall distribution, but also identifies the interval with significant clustering characteristics in the processing time delay data by weighting the density of the overall sample distribution. Finally, the system outputs the central time delay, clustering range and transaction number of each type of processing behavior, which provides a basis for screening transactions with similar processing characteristics and supports the further implementation of the collection synchronization execution strategy. The whole process consists of five parts: data input, parameter setting, density calculation, attribution judgment and structure output, which realizes the automatic distribution identification and behavior classification of transaction processing time delay.

[0140] The sequence segment screening submodule identifies the transaction number continuous segment with centralized density characteristics according to the distribution interval of each type of processing time delay in the time delay density clustering information, and generates the synchronous collection sequence segment;

[0141] Based on the time delay density clustering information as the input, the information records the centralized characteristics of multiple processing time delay intervals, including the clustering center, fluctuation range, transaction number and corresponding transaction number of each interval. The system first extracts the upper and lower boundary values of each clustering interval, and obtains the complete transaction number set belonging to the interval. Then, the system scans and divides these transaction numbers in order to find the subsequence of continuous number arrangement to determine whether there is a highly consistent transaction processing behavior adjacent transaction segment. The judgment process will be carried out according to the natural increasing order of the number, identify the subsegment without jumping between numbers, and confirm whether the subsegment can be used as a synchronous execution candidate area under the conditions of meeting the minimum length threshold or clustering density limit. The system executes the screening process for all clustering intervals in turn, and finally outputs the set of transaction number subsegments with continuous numbers and high processing time delay concentration, which constitutes the synchronous collection sequence segment.

[0142] Please refer to Figure 6 , the asynchronous synchronization module comprises:

[0143] The main account content extraction submodule obtains the number information of each transaction in the synchronous collection sequence segment, calls the write record of the corresponding number in the main transaction account, and generates a set of main account transaction contents;

[0144] Based on the transaction number listed in the synchronization collection sequence section, the corresponding transaction in the main transaction ledger is retrieved in detail. The main transaction ledger is the core data storage structure in the system, containing the complete execution content of each transaction, such as transaction number, amount, standardized time, access time, confirmation time, channel type and related operation identifier, etc. The system first lists the transaction numbers in the synchronization section, and queries in the ledger database with the number as the index field. The query method can use structured search statements combined with transaction marker index to ensure high retrieval capability in high concurrency data environment. After successfully retrieving the transaction record, the system encapsulates it as a main ledger transaction content set, each record containing original field data, ledger entry time, and channel attributes related to asynchronous writing, providing complete data preparation for subsequent cross-ledger processing. If there is an abnormal situation that the number cannot be matched, the system will mark it as unmatched and keep an empty placeholder in the data set.

[0145] The asynchronous ledger writing matching submodule matches the channel type information of each transaction in the main ledger transaction content set to the corresponding ledger instance in the configured asynchronous ledger set, writes each transaction content to the corresponding asynchronous ledger, and generates an asynchronous ledger writing result set;

[0146] Before performing the specific writing operation, first determine the corresponding asynchronous ledger instance according to the channel type information of each transaction in the main ledger transaction content set. The so-called asynchronous ledger is a ledger system independent of the main transaction ledger, used to support the processing of transactions in different channels, platforms or systems, with characteristics such as asynchronous access, delayed response, non-real-time submission, etc. Unlike the main transaction ledger, which is responsible for the core registration function of all transactions in the system and has strict sequence, uniqueness constraints and real-time writing requirements, it is the basis for formal transaction authorization. The asynchronous ledger focuses more on transaction reuse, expansion processing and channel archiving in multiple channels or business dimensions, and its design allows data to be submitted asynchronously after the main ledger is confirmed, to relieve system concurrency pressure and enhance cross-ledger compatibility. Asynchronous ledgers are usually divided by channel, such as corresponding to UnionPay, online banking, digital wallet and other payment systems, and each ledger instance is responsible for receiving specific type of transaction data. During the writing process, the system looks up the asynchronous ledger mapping relationship according to the channel type field of the transaction, and submits the corresponding transaction to the matched ledger instance for writing. Asynchronous ledgers support independent feedback mechanism, which can record the processing status of each transaction and return the corresponding result, which is used for subsequent aggregation and monitoring. The main ledger focuses on the unified authorization and timeliness of the system kernel, and the asynchronous ledger provides horizontal expansion and differentiated access capability, which complement each other and together constitute a complete distributed ledger system structure.

[0147] The collection data aggregation output submodule sorts the write results by channel dimension according to the processing state of each asynchronous ledger in the asynchronous ledger write result set, summarizes the synchronization state and transaction data write state of all ledgers, and generates fusion collection data;

[0148] With the asynchronous ledger write result set as input, the system classifies and counts the write state according to the ledger instance, channel type and write feedback information recorded in the set by channel dimension. The aggregation process starts with traversing all asynchronous ledgers, extracts the number of successful writes, failed writes, and processing writes in each ledger, and marks the relevant transaction numbers for subsequent verification. At the same time, the system identifies abnormal states existing in cross-ledger writes, such as delayed writes, repeated writes, missing fields, etc., and classifies and summarizes errors by channel. Finally, the system generates fusion collection data, which includes the collection processing of each channel, the transaction success rate, abnormal details and complete write coverage, which is used to display the collection execution panorama, generate reports or feedback to the monitoring module in the upper system, realizing the structured output and process tracking of the collection process.

[0149] A collection method supporting multi-payment channel fusion, which is based on the above-mentioned collection system supporting multi-payment channel fusion and includes the following steps:

[0150] S1: In the collection behavior access stage, the access time and transaction amount of each transaction are obtained, and a transaction parameter set is constructed;

[0151] S2: The access time and transaction amount of each transaction in the transaction parameter set are extracted and normalized, the weighted entropy value of each transaction is calculated, the entropy value is referred to sort all transactions, and a collection order instruction set is obtained;

[0152] S3: According to the collection order instruction set, each transaction is sequentially written into the main transaction ledger and the transaction confirmation time is recorded, the write processing time delay is calculated by comparing with the access time of the corresponding transaction, and a ledger write processing time delay set is obtained;

[0153] S4: The ledger write processing time delay set is input into the Bayesian Gaussian mixture model, the probability density distribution of each type of time delay in the entire write processing time delay is calculated, and the time delay aggregation interval is identified, and the synchronous collection sequence section is screened;

[0154] S5: The write record of the corresponding main transaction ledger of each transaction in the synchronous collection sequence section is obtained, the main ledger transaction content is synchronously written into the specified asynchronous ledger for channel reconciliation and account restoration, and fusion collection data is output.

[0155] The above merely describes the preferred embodiments of the present application, and is not intended to limit the present application in other forms. Any skilled person in the art can modify or change the disclosed technical content into equivalent embodiments with equivalent changes, and apply them to other fields. However, any simple modification, equivalent change and modification made to the above embodiments according to the technical essence of the present application, without departing from the technical solution content of the present application, still falls within the protection scope of the present application.

Claims

1. A collection system supporting multi-payment channel convergence, characterized in that, The system comprises: A parameter collection module acquires access time and transaction amount of each transaction in the access stage of the collection behavior, and constructs a transaction parameter set; A weight ordering module calculates weighted entropy value of each transaction according to the transaction parameter set, orders all transactions according to the entropy value, and obtains a collection order instruction set; A main ledger writing module writes each transaction into the main transaction ledger in sequence according to the collection order instruction set, records the transaction confirmation time, compares the access time of the corresponding transaction to calculate the writing processing time delay, and obtains a ledger writing processing time delay set; A time delay identification module inputs the ledger writing processing time delay set into a Bayesian Gaussian mixture model, calculates the probability density distribution of each type of time delay in the entire writing processing time delay, identifies the time delay aggregation interval, and screens a synchronous collection sequence section; An asynchronous synchronization module acquires the writing record of the main transaction ledger corresponding to each transaction in the synchronous collection sequence section, synchronously writes the main ledger transaction content into a specified asynchronous ledger for channel reconciliation and account restoration, and outputs fused collection data.

2. The collection system of claim 1, wherein, The transaction parameter set is specifically standardized access time, standardized transaction amount, and transaction number index, the collection order instruction set includes ordering position, transaction number order, and weighted entropy value, the ledger writing processing time delay set includes processing time length, transaction confirmation time, and access record index, the synchronous collection sequence section includes transaction number interval, stable time delay category, and model output label, and the fused collection data specifically refers to asynchronous ledger writing state, channel ledger positioning result, and transaction synchronization result identifier. 3.The collection system of claim 1, wherein, The parameter collection module comprises: A time standardization submodule acquires access time of each transaction in the access stage of the collection behavior, performs unified format conversion on the access time, and generates time standardization values; An amount standardization submodule calls transaction number of the time standardization values to acquire transaction amount of the corresponding transaction, converts each amount value into an expression form under a consistent scale, and generates amount standardization values; A transaction parameter summary submodule establishes a corresponding transaction number relationship according to the time standardization values and the amount standardization values, and generates a transaction parameter set.

4. The collection system of claim 3, wherein, The weight ordering module comprises: A transaction parameter extraction submodule calls amount standardization values corresponding to each transaction in the transaction parameter set, and constructs a standardized parameter set; An entropy value calculation submodule extracts amount values corresponding to each transaction in the standardized parameter set, statistics the distribution proportion of all transactions in the amount values, calculates information entropy of each transaction in the amount aspect based on the distribution proportion, combines according to a fixed weight proportion, and generates a weighted entropy value set; An ordering instruction generation submodule performs priority ordering according to the entropy value of each transaction in the weighted entropy value set and marks the corresponding time standardization values, and generates a collection order instruction set.

5. The collection system of claim 4, wherein, The main ledger writing module comprises: A ledger writing execution submodule sequentially submits corresponding transaction content to the main transaction ledger according to the transaction number order in the collection order instruction set, and generates a main ledger writing sequence; The confirmation time collection submodule obtains the transaction confirmation time fed back by the main transaction ledger based on each recorded transaction in the main ledger writing sequence, records the transaction confirmation time according to the transaction number, and generates a transaction confirmation time set; The processing time delay calculation submodule calculates the time difference between the confirmation time of each transaction in the transaction confirmation time set and the access time of the corresponding transaction in the transaction parameter set, arranges and summarizes the time difference results of all transactions in order, and generates a ledger writing processing time delay set.

6. The collection system of claim 5, wherein, The time delay identification module comprises: The model input preprocessing submodule obtains the processing time delay values of all transactions in the ledger writing processing time delay set, constructs a delay data vector in order, and generates a model processing input set; The density distribution identification submodule calls a variational Bayesian Gaussian mixture model to divide the probability density of the delay data according to the processing time delay values in the model processing input set, judges the distribution concentration degree of each type of processing time delay in the whole according to the model output, and generates delay density aggregation information; The sequence section screening submodule identifies the transaction number continuous section with concentrated density characteristics according to the distribution interval of each type of processing time delay in the delay density aggregation information, and generates a synchronous collection sequence section.

7. The collection system of claim 6, wherein, The asynchronous synchronization module comprises: The main ledger content extraction submodule obtains the number information of each transaction in the synchronous collection sequence section, calls the writing record of the corresponding number in the main transaction ledger, and generates a main ledger transaction content set; The asynchronous ledger writing matching submodule matches each transaction content to the corresponding ledger instance in the configured asynchronous ledger set according to the channel type information corresponding to each transaction in the main ledger transaction content set, writes each transaction content into the corresponding asynchronous ledger, and generates an asynchronous ledger writing result set; The collection data aggregation output submodule arranges the writing results according to the channel dimension, summarizes the synchronization situation and transaction data writing state of all ledgers, and generates fused collection data according to the processing state of each asynchronous ledger in the asynchronous ledger writing result set.

8. A method for collecting money supporting the fusion of multiple payment channels, characterized by, The collection system supporting multi-payment channel fusion according to any one of claims 1-7 comprises the following steps: S1: obtaining the access time and transaction amount of each transaction in the collection behavior access stage, and constructing a transaction parameter set; S2: extracting the access time and transaction amount of each transaction in the transaction parameter set and normalizing, calculating the weighted entropy value of each transaction, sorting all transactions according to the entropy value, and obtaining a collection order instruction set; S3: according to the collection order instruction set, each transaction is written into the main transaction ledger in turn and the transaction confirmation time is recorded, and the writing processing time delay is calculated by comparing with the access time of the corresponding transaction, and a ledger writing processing time delay set is obtained; S4: input the ledger writing processing time delay set into the Bayesian Gaussian mixture model, calculate the probability density distribution of each type of time delay in the whole writing processing time delay, and identify the delay aggregation interval, and screen the synchronous collection sequence section; S5: Obtain the write record of the corresponding main transaction ledger of each transaction in the synchronization collection sequence section, synchronize the content of the main ledger transaction to the specified asynchronous ledger for channel reconciliation and account restoration, and output the fusion collection data.

Images