A fund clearing processing method and system, a terminal device and a medium
Patent Information
- Application Number
- CN202611461004.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-09-20
- Publication Date
- 2026-10-27
AI Technical Summary
该模式下,虽然清分结果能够实时获取,但实时逐笔入账导致账务流水数据激增,资金实时进入商户账户后存在跨周期、跨业务属性挪用的风险,资金风险控制难度大,难以全面推广
[0016]有益效果:本发明公开一种资金清算处理方法、系统、终端设备及介质,涉及资金清算技术领域。方法首先获取交易的交易数据。其后,响应于所述交易的完成,根据所述交易数据,对所述交易执行清分处理,得到所述交易的清分结果,其中,所述清分结果包括所述交易的手续费和应结算金额。随后,根据所述清分结果,将所述交易归集至所述交易所属商户的结算周期对应的资金统计信息中,其中,所述资金统计信息用于累计所述商户在所述结算周期内的资金数据,所述资金数据包括交易资金和/或退款资金。最后,根据所述结算周期,确定所述资金统计信息的入账时间,并在到达所述入账时间时,根据所述资金统计信息,集中执行对所述商户的入账处理,以将所述资金统计信息中累计的资金入账至所述商户的账户。
Smart Images

Figure CN122989281A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of fund clearing technology, and in particular to a fund clearing processing method, system, terminal equipment and medium. Background Technology
[0002] In the field of payment clearing, the clearing and settlement of merchant transaction funds are usually handled uniformly by the clearing system.
[0003] There are two main existing clearing models: The first is the centralized batch processing model, which involves clearing and crediting all transactions from the previous day in the early morning. Under this model, clearing is disconnected from the transaction process, merchants cannot know transaction fees and settlement amounts in real time, and the early morning batch processing is time-consuming, requiring manual intervention when interrupted, making it difficult to guarantee timely morning settlement. Furthermore, clearing anomalies cannot be detected promptly, and refund fund control is coupled to the transaction system, resulting in dispersed responsibility for fund security control. The second is the real-time clearing model, which involves clearing and crediting transactions in real time after completion. While clearing results are available in real time, real-time crediting leads to a surge in transaction data, posing a risk of misappropriation across periods and business categories once funds enter merchant accounts. This makes fund risk control difficult and hinders widespread adoption.
[0004] Therefore, there is an urgent need for a fund clearing and processing method that can perform clearing and settlement in near real time after a transaction is completed and centrally execute the settlement according to the preset settlement time, in order to fill the gap in existing technology. Summary of the Invention
[0005] The technical problem this invention aims to solve is, in the field of fund clearing technology, how to overcome the issues of delayed clearing processing and disconnection from the transaction process under the centralized batch processing model, while avoiding the fund risks associated with real-time, transaction-by-transaction settlement under the real-time clearing model. This would achieve effective decoupling of clearing and settlement, enabling merchants to obtain clearing results almost in real-time after a transaction and flexibly and securely complete fund settlement according to their settlement cycle. Therefore, an effective solution is urgently needed to address these technical problems.
[0006] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: In a first aspect, the present invention provides a fund clearing and processing method, the method comprising: Obtain transaction data for the transaction; In response to the completion of the transaction, a clearing process is performed on the transaction based on the transaction data to obtain the clearing result of the transaction; wherein, the clearing result includes the transaction fee and the amount to be settled; Based on the clearing results, the transactions are aggregated into the fund statistics information corresponding to the settlement cycle of the merchant to which the transaction belongs; wherein, the fund statistics information is used to accumulate the fund data of the merchant within the settlement cycle, and the fund data includes transaction funds and / or refund funds; The time for recording the funds statistics information is determined based on the settlement cycle. When the designated crediting time arrives, the crediting process for the merchant is executed centrally based on the fund statistics information, so as to credit the funds accumulated in the fund statistics information to the merchant's account.
[0007] In one implementation, the step of aggregating the transaction into the fund statistics information corresponding to the settlement cycle of the merchant to which the transaction belongs, based on the clearing result, includes: Based on the transaction attributes of the transaction, an inbound bill number corresponding to the settlement period is generated; wherein, the transaction attributes include at least one of the following: transaction merchant number, clearing channel number, business type, inbound interval days, and custom period, and the inbound interval days are determined according to the settlement period of the channel to which the transaction belongs; Perform a base conversion and compression on the preset fields in the billing number; The clearing results are accumulated into the statistics field of the inbound bill corresponding to the compressed inbound bill number; wherein, the inbound bill is used to record the merchant's fund inflows and outflows during the settlement period, and when accumulating the clearing results, the clearing bill status of the transaction is updated synchronously in a transactional manner, the clearing bill status is used to indicate that the transaction has been statistically completed, so as to prevent the transaction from being accumulated repeatedly.
[0008] In one implementation, the method further includes: When the clearing process of the transaction fails, the transaction data of the transaction is stored in the abnormal pending clearing table; Periodically retrieve transactions that failed to be cleared from the abnormal pending clearing table and re-execute the clearing process; If the clearing process is successfully re-executed, the transaction will be removed from the list of abnormal pending clearing transactions; If, during reconciliation, a missing transaction is found in the abnormal pending clearing table, then the missing transaction has been determined to have been processed.
[0009] In one implementation, the centralized execution of the merchant's accounting processing includes: Before performing the posting operation, check whether the reconciliation results of the reconciliation tasks within the preset time period are all successful; Obtain the clearing results associated with the fund statistics information, and compare the clearing results with the fund statistics information; If the comparison results are consistent, the posting operation is performed; wherein, the posting operation includes at least one of the following: posting the accumulated transaction funds to the merchant's account, deducting the accumulated handling fees, deducting the funds from the successfully refunded funds, and freezing the funds in the refund process; After the deposit operation is completed, automatic withdrawal information is reported to trigger the transfer of funds from the merchant's account to the merchant's bank account.
[0010] In one implementation, the method further includes: Receive a refund request for the target transaction of the merchant; Calculate the refundable handling fee and the refundable settlement amount based on the clearing results corresponding to the target transaction; Based on the merchant's financial statistics, determine whether the merchant's available funds meet the refund amount requested in the refund request; If the available funds meet the refund amount, update the refund statistics in the fund statistics information; When the refund request has not been resolved within the settlement period, the funds corresponding to multiple refunds that are in the process of being refunded are aggregated to generate a total freeze document, which is used to freeze the funds and record the unfreezing and refreezing operations of the total freeze document.
[0011] In one implementation, determining whether the merchant's available funds meet the refund amount requested in the refund request includes: When the available funds of the first processing node corresponding to the refund request are insufficient to meet the refund amount, a fund occupation record corresponding to the refund amount is established; The available funds of the merchant are queried from the second processing node, which is another processing node where the merchant has fund statistics information; When the available funds of the second processing node meet the refund amount, it is determined that the refund request can be satisfied, and the funds corresponding to the refund amount are pre-allocated on the second processing node through the fund occupation record; When the available funds of the second processing node are insufficient to meet the refund amount, the fund occupation record is released.
[0012] In one implementation, the method further includes: When a transaction pending settlement is a transaction to be settled on the same day and settlement is not completed on the transaction date of the transaction pending settlement, the transaction pending settlement is pushed to the clearing and settlement process after the transaction date to perform the clearing and settlement process on the transaction pending settlement. The same-day settlement process is executed only on the transaction date of the pending transaction, and the clearing process is executed only on transactions with a processing date later than the transaction date, in order to avoid the pending transaction being settled twice. Before centrally executing the billing process for the merchants, confirm that the push task for the pending settlement transactions has been completed.
[0013] Secondly, embodiments of the present invention also provide a funds clearing and processing system, the system comprising: The transaction data acquisition module is used to acquire transaction data. The clearing module is used to respond to the completion of the transaction by performing clearing processing on the transaction based on the transaction data, and obtaining the clearing result of the transaction; wherein, the clearing result includes the transaction fee and the amount to be settled; The funds statistics information processing module is used to aggregate the transaction into the funds statistics information corresponding to the settlement cycle of the merchant to which the transaction belongs, based on the clearing result; wherein, the funds statistics information is used to accumulate the merchant's funds data within the settlement cycle, and the funds data includes transaction funds and / or refund funds; The deposit time determination module is used to determine the deposit time of the fund statistics information based on the settlement cycle. The payment module is used to centrally execute payment processing for the merchant based on the fund statistics information when the payment time arrives, so as to transfer the funds accumulated in the fund statistics information to the merchant's account.
[0014] Thirdly, embodiments of the present invention also provide a terminal device, the terminal device including a memory, a processor, and a funds clearing processing program stored in the memory and executable on the processor, wherein when the processor executes the funds clearing processing program, it implements the steps of the funds clearing processing method described in any of the above schemes.
[0015] Fourthly, embodiments of the present invention also provide a computer-readable storage medium storing a funds clearing processing program, wherein when the funds clearing processing program is executed by a processor, it implements the steps of the funds clearing processing method described in any of the above schemes.
[0016] Beneficial Effects: This invention discloses a fund clearing and processing method, system, terminal equipment, and medium, relating to the field of fund clearing technology. The method first acquires transaction data. Then, in response to the completion of the transaction, a clearing process is performed on the transaction based on the transaction data to obtain the clearing result, wherein the clearing result includes the transaction fee and the amount to be settled. Subsequently, based on the clearing result, the transaction is aggregated into the fund statistics information corresponding to the settlement cycle of the merchant to which the transaction belongs, wherein the fund statistics information is used to accumulate the merchant's fund data within the settlement cycle, and the fund data includes transaction funds and / or refund funds. Finally, based on the settlement cycle, the crediting time of the fund statistics information is determined, and upon reaching the crediting time, the crediting process for the merchant is centrally executed based on the fund statistics information to credit the accumulated funds in the fund statistics information to the merchant's account.
[0017] This invention decouples clearing and settlement processing from payment processing, performing clearing and settlement processing nearly in real time after a transaction is completed. This allows merchants to promptly know the transaction fees and settlement amounts for each transaction without waiting for the unified clearing process at midnight the following day. Simultaneously, the payment processing time is determined according to the merchant's settlement cycle, and payment processing is performed centrally when the payment time arrives. This avoids the financial risks associated with real-time, transaction-by-transaction payment processing. Furthermore, the payment processing time can be flexibly configured according to the merchant's settlement cycle, balancing the real-time nature and security of fund clearing and effectively improving the efficiency and flexibility of fund clearing and processing. Attached Figure Description
[0018] Figure 1 A flowchart illustrating a specific implementation of the fund clearing and processing method provided in this embodiment of the invention.
[0019] Figure 2 This is a flowchart illustrating the refund process in this embodiment, where the refund result is only determined after a cross-cycle period.
[0020] Figure 3 This is a flowchart illustrating the cross-node refund processing operation in this embodiment.
[0021] Figure 4 This is a flowchart illustrating the successful transaction clearing process in this embodiment.
[0022] Figure 5 This is a flowchart illustrating the transaction refund creation and processing operation in this embodiment.
[0023] Figure 6 This is a flowchart illustrating the centralized batch processing operation for accounting entries in this embodiment.
[0024] Figure 7 This is a flowchart illustrating the real-time clearing and exception handling operation in this embodiment.
[0025] Figure 8 This is a flowchart illustrating the bill number generation process in this embodiment.
[0026] Figure 9 This is a schematic diagram of the process for calculating the SN entry time in this embodiment.
[0027] Figure 10 This is a schematic diagram of the fund clearing and processing equipment provided in the embodiment of the present invention.
[0028] Figure 11 This is a block diagram illustrating the internal structure of the terminal device provided in an embodiment of the present invention. Detailed Implementation
[0029] To make the objectives, technical solutions, and effects of this invention clearer and more explicit, 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 of the invention and are not intended to limit the invention.
[0030] The flowchart shown in the attached diagram is for illustrative purposes only and does not necessarily include all content, operations, or steps, nor does it require execution in the described order. For example, some operations or steps can be broken down, combined, or partially merged, so the actual execution order may change depending on the actual situation.
[0031] It should be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.
[0032] It should be understood that, in order to clearly describe the technical solutions of the embodiments of the present invention, the terms "first" and "second" are used in the embodiments of the present invention to distinguish identical or similar items with essentially the same function and effect. For example, the first control information and the second control information are only used to distinguish different control information and do not limit their order.
[0033] Those skilled in the art will understand that the words "first" and "second" do not limit the quantity or the order of execution, and that the words "first" and "second" do not necessarily imply that they are different.
[0034] It should also be understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.
[0035] With the development of payment services, transaction fund clearing systems need to handle the clearing and crediting of transaction funds for merchants. Clearing refers to calculating the transaction fee and settlement amount for each transaction based on transaction data, while crediting refers to depositing the funds due for settlement within a certain settlement period into the merchant's account. Currently, transaction fund clearing and crediting typically employs the following two models.
[0036] The first type is the centralized batch processing model. This model processes all transactions generated the previous day at a fixed time in the early morning using a batch processing settlement task. This includes both calculating the settlement amount for each transaction and depositing the funds. Currently, most merchants still use this model for next-day settlements. This model also supports time-sharing settlements and allows merchants to choose to temporarily retain funds within the system for later withdrawal. However, the centralized batch processing model has the following drawbacks: (1) The time spent on clearing and accounting in the early morning is long. If the batch processing is interrupted, manual intervention is required to repair it, resulting in a large delay in the morning settlement. (2) Because the batch processing mode cannot interact with the transaction process in real time, the transaction process is coupled with the control and responsibility for the security of settlement funds. For example, the control of refund funds and the processing of business revenue mark-up must be completed in the transaction process. (3) The lack of participation in the real-time transaction process limits the expansion of the batch processing business, because the batch processing prioritizes the stability, high performance and timeliness of centralized clearing, and needs to avoid complex and frequent external interaction processing as much as possible. (4) The negative refund process reused the stop payment plan to intercept and deduct funds, resulting in unclear stop payment amounts on the payment slips; (5) The batch processing will clear the same day's settlement transactions again according to the settlement method of the next day's settlement, resulting in the clearing data containing useless data and wasting batch processing time; (6) Batch processing is split into multiple settlement services based on time-sharing or regular, card swiping or QR code scanning, resulting in high update and maintenance costs; (7) Fee allocation depends on transaction clearing data, and the centralized batch processing mode makes the real-time fee allocation system unable to function.
[0037] The second type is the real-time clearing model, which combines real-time settlement and real-time payment. To provide a better financial experience in application scenarios such as real-time subsidies and real-time revenue sharing, and to replace the aforementioned centralized batch processing model, the industry has provided clearing systems that combine real-time settlement and real-time payment. However, during the gradual rollout of this model and its attempt to replace the centralized batch processing model, problems have arisen, including difficulty in controlling the financial risks associated with real-time payment, cumbersome application processes for merchants to activate real-time clearing permissions, a surge in transaction data, and the potential for misappropriation of account funds across settlement cycles and business attributes. These issues have hindered the full implementation of the real-time clearing model. Instead of alleviating or eliminating the burden of centralized batch processing, it has further expanded the scale of clearing services and increased development and maintenance costs.
[0038] This reveals that the existing centralized batch processing model suffers from lagging clearing and processing, lacks real-time interaction with the transaction process, and is time-consuming, requiring manual intervention during interruptions. The existing real-time clearing model, on the other hand, records transactions one by one, leading to uncontrollable financial risks and excessive accounting data. As the market's demand for personalized allocation, composition (such as including subsidies), and disbursement methods for settlement funds continues to grow, and as the real-time requirements of upstream and downstream settlement systems (transactions, fee allocation) increase, there is an urgent need for a clearing and processing method that can complete clearing near real-time after a transaction and ensure fund security during the recording process. This method should be flexible, fast, and efficient on the demand side, seamlessly connecting the entire process of transactions, settlement, and fee allocation; secure and controllable on the funding side; and provide a streamlined and unified business settlement model, cohesive settlement functions, and timely detection of abnormal data on the maintenance side.
[0039] Therefore, this embodiment provides a fund clearing and processing method to solve the above problems. The fund clearing and processing method is as follows: Figure 1 As shown, the specific steps include the following: Step S100: Obtain transaction data for the transaction.
[0040] In this embodiment, a transaction refers to the payment and receipt of funds between a merchant and a consumer through an acquiring channel. A successful transaction generates a corresponding transaction record. Transaction data refers to the information carried in this transaction record, specifically the transaction amount, transaction time, transaction status, transaction number, and transaction channel identifier. In this embodiment, after a transaction is completed, the transaction system can asynchronously send the transaction data to the clearing system via a message component. Upon receiving the message, the clearing system completes the acquisition of the transaction data. The message component can take the form of a message queue, such as a message middleware based on a publish-subscribe pattern, to achieve decoupled transmission between the transaction system and the clearing system, allowing the clearing process to obtain data without waiting for a synchronous response from the transaction system.
[0041] It should be noted that the entry point for obtaining transaction data in this embodiment is not limited to message push notifications after a transaction is completed. In actual operation, tools for pushing transactions settled on the same day to those settled the next day, hourly reconciliation and compensation tools, and automatic anomaly compensation tools will all provide transaction data to be cleared to the clearing process under corresponding trigger conditions, thereby allowing missed or backlogged transactions to be supplemented into the clearing process. By obtaining transaction data, transaction data is provided for the clearing process, enabling the clearing process to be executed in near real-time after the transaction is completed, without waiting for centralized batch processing in the early morning of the following day.
[0042] Step S200: In response to the completion of the transaction, perform clearing processing on the transaction based on the transaction data to obtain the clearing result of the transaction; wherein, the clearing result includes the transaction fee and the amount to be settled.
[0043] In this embodiment, clearing and settlement refers to the process of calculating the transaction fees and the funds owed to the merchant based on transaction data. The transaction fee is the fee charged to the merchant according to an agreed rate during transaction processing, and the settlement amount is the amount of funds to be settled to the merchant after deducting the transaction fee. The transaction fee and the settlement amount together constitute the clearing and settlement result of the transaction. In this embodiment, the clearing and settlement process can reuse the clearing and settlement procedures in the real-time clearing system to reduce functional redundancy, enabling the same clearing and settlement process to simultaneously serve both real-time clearing and centralized accounting methods.
[0044] like Figure 4 As shown, the specific process of clearing and sorting includes: First, query the interface or database to obtain the basic transaction data and merchant information required for clearing; determine whether the transaction is a same-day settlement transaction and whether it has been settled by the same-day settlement system. This determination is used to avoid duplicate clearing when a same-day settlement transaction is converted to a next-day settlement transaction; for next-day settlement transactions, call the billing platform to complete the calculation of handling fees. The billing platform determines the handling fee amount based on the fee rate rules configured by the merchant and determines the amount to be settled based on the transaction amount; after determining the basic characteristics of clearing, the clearing results are stored and a clearing slip is generated.
[0045] Subsequently, it is determined whether the merchant to which the transaction belongs needs real-time settlement. If the merchant needs real-time settlement, the settlement result will be credited to the merchant's account balance in real time after the settlement is completed; if the merchant does not need real-time settlement, it will be processed according to the real-time settlement centralized crediting mode, that is, the crediting dimension features are extracted based on the transaction and settlement attributes to generate a crediting bill number, and the expected crediting time is inferred by combining the settlement cycle attributes of the channel and the merchant's customized billing cycle attributes for centralized crediting.
[0046] Next, the transaction amount, settlement amount, and other information corresponding to this transaction are accumulated into the corresponding statistical fields of the invoice for that invoice number. Simultaneously, the settlement status, invoice number, and posting time of this transaction are updated. To prevent the same transaction from being counted repeatedly in the invoice, the update of the settlement status and the accumulation of statistical data are completed within the same transaction. If any abnormality occurs during the above settlement process, such as database query or update failure, interface access error, or missing billing configuration, the key information of this transaction is recorded in the abnormal pending settlement table, and the automatic abnormal compensation tool will pull it out and re-push it.
[0047] It should be noted that the above process integrates the real-time clearing mode and the real-time clearing and centralized accounting mode. The two modes share the same clearing process, and the only difference is in the accounting stage. One mode records the accounting to the account balance in real time after clearing is completed, while the other mode generates an accounting entry number and accounting time in advance for centralized accounting.
[0048] In this embodiment, the clearing process is executed in near real-time after the transaction is completed. By separating the clearing process from the centralized batch processing in the early morning of the following day and making it near real-time, merchants can know the transaction fee and the amount to be settled immediately after the transaction is completed, achieving real-time awareness of the charging situation. On the other hand, it also enables real-time monitoring of data anomalies such as abnormal fee configuration and missing channel data, thereby promptly notifying the business side to repair the data and configuration, avoiding the long-term accumulation of abnormal data that would lead to full fee-based settlement and supplementary settlement.
[0049] Step S300: Based on the clearing results, the transaction is aggregated into the fund statistics information corresponding to the settlement cycle of the merchant to which the transaction belongs; wherein, the fund statistics information is used to accumulate the fund data of the merchant in the settlement cycle, and the fund data includes transaction funds and / or refund funds.
[0050] In this embodiment, a merchant refers to a entity that establishes a settlement relationship with the clearing system. The settlement period refers to the transaction time range covered by the merchant's due funds, which can be a calendar day period or a period with start and end points defined by the merchant. Fund statistics refer to the cumulative fund data collected according to the merchant and its settlement period, used to reflect the overall situation of the merchant's due funds within a certain settlement period. Specifically, it can be represented as a statistical record of the merchant's cumulative transaction funds and refund funds within that settlement period. Transaction funds refer to the due funds generated from transactions within that period, and refund funds refer to the funds that need to be offset after a refund occurs within that period. The net due funds of the merchant within that period are the sum of the transaction funds and refund funds.
[0051] In this embodiment, transactions are aggregated into the fund statistics information corresponding to the settlement cycle of the merchant to which the transaction belongs, based on the clearing results. Specifically, elements such as the transaction amount and the amount to be settled are extracted from the clearing results. The aggregation target is determined according to the merchant to which the transaction belongs and its settlement cycle, and the corresponding amount is accumulated into the fund statistics information under that target. By aggregating the clearing results by settlement cycle, the dispersed funds of individual transactions can be aggregated by merchant for centralized execution and accounting by merchant.
[0052] In one implementation, the step of aggregating the transaction into the fund statistics information corresponding to the settlement cycle of the merchant to which the transaction belongs, based on the clearing result, specifically includes the following steps: Step S310: Generate an inbound bill number corresponding to the settlement cycle based on the transaction attributes of the transaction; wherein, the transaction attributes include at least one of the following: transaction merchant number, clearing channel number, business type, inbound interval days, and custom cycle, and the inbound interval days are determined according to the settlement cycle of the channel to which the transaction belongs; Step S320: Perform a base conversion and compression on the preset fields in the billing number; Step S330: The clearing results are accumulated into the statistics field of the inbound bill corresponding to the compressed inbound bill number; wherein, the inbound bill is used to record the merchant's fund inflows and outflows during the settlement period, and when accumulating the clearing results, the clearing bill status of the transaction is updated synchronously in a transactional manner, the clearing bill status is used to indicate that the transaction has been statistically completed, so as to prevent the transaction from being accumulated repeatedly.
[0053] In this embodiment, fund statistics are implemented in the form of inbound invoices. Inbound invoices, or periodic inbound invoices, are used to record the total fund inflows and outflows of merchants within the settlement period. Before settlement, inbound invoices serve as in-transit balance information, reflecting the scale of funds that have been cleared but not yet credited to the account. In refund processing, they are used as highly dependent data to prevent fund leakage and control concurrent refunds, playing a crucial role in ensuring fund security. Ultimately, inbound invoices also serve as the basis for actual crediting, assisting in completing the crediting process.
[0054] The unique key of the bill of accounts consists of multiple dimension members, as shown in Table 1, including the billing merchant number, transaction merchant number, transaction date, settlement cycle, ledger type, clearing channel, multi-active node ID, billing time, business type, and special bits.
[0055] Table 1
[0056] The aforementioned dimensions collectively describe a complete fund statistics record. This record details which merchant's transactions for a specific type of business, occurring at a designated payment date and belonging to a designated clearing channel, will be cleared and credited to which ledger after a custom settlement cycle, along with the current fund statistics for that record. The clearing channel is configured on the transaction channel attribute. Having the same clearing channel means that, under the same conditions in other dimensions, multiple different transaction channels can be merged for statistics and share the amount in transit for refunds. The multi-active node ID is used to distinguish the accumulated payments of the same merchant across different nodes in a multi-active deployment system. A special bit is used to distinguish between normal payment invoices and abnormal clearing invoices.
[0057] The total length after concatenating all dimensions can reach 38 characters, while the length of the invoice number in the database field is only 32 characters, which would be truncated if used directly. To avoid losing the dimensional information carried by the invoice number, this embodiment uses a decimal-to-sexagenary conversion to compress some information. Specifically, 17 characters of information such as the merchant number, clearing channel number, business type, invoice date, and custom period are compressed to 10 characters, while the remaining information remains plaintext. The mapping character set used in the sexagenary compression rule is: 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwx The character set contains 60 characters. The conversion algorithm is as follows:
[0058]
[0059]
[0060]
[0061]
[0062]
[0063]
[0064] In this algorithm, let the decimal number to be converted be... ,make Empty; when When it is greater than 0, take equal The result of taking the modulo of 60 is used to set the index in the character set as follows. append characters to and will Updated to Divide by 60 and round down; after the loop ends, Reverse, and you get the transformation result.
[0065] For example, suppose the clearing information of a transaction is as follows: Transaction date 20250115, special bit 0, settlement flag 1, node ID 2, transaction merchant number 6012514015, clearing channel number 1, business type 0, settlement interval days 2, custom period 0, settlement merchant number 6012514015. Then the concatenated plaintext is 20250115012601251401501002006012514015, and after compression it is 202501150125vwAP5OWGe6012514015, where 60125140150100200 is compressed to 5vwAP5OWGe.
[0066] It should be further explained that the determination of the settlement interval is related to the settlement cycle of the transaction channel. For channels that support the S+N settlement rule, such as overseas card channels (VISA, MASTER), a settlement cycle of several days with a delay of S+3, T+4, etc. may be used, and the settlement basis needs to be calculated based on local holidays. Its settlement cycle parameters include the settlement basis type and the number of interval days, where the settlement basis type is used to indicate whether S is a calendar day or a transaction day.
[0067] like Figure 9 As shown, when S is a calendar day, N can be directly used as the settlement interval days; when S is a transaction day, it is necessary to query the holiday information configured for this channel, find N working days from the transaction date, and use the total number of days after skipping holidays as the settlement interval days. The domestic T+1 rule is only a special case of S+N. By supporting S+N calculation, the clearing and settlement processing of domestic and foreign cards can be unified.
[0068] Regarding the process of generating the invoice number, such as Figure 8As shown, the clearing parameters are first checked. Since the characteristics of the invoice number are derived from the clearing information, and the invoice number identifies a merchant's periodic settlement funds, this characteristic needs to be strictly checked. Next, the start time of the settlement period to which the transaction belongs is inferred. This involves the merchant's customized billing cycle configuration. For example, for a merchant with an 8 AM settlement cycle, transactions before 8 AM belong to the settlement cycle from 8 AM yesterday to 8 AM today, and transactions after 8 AM belong to the settlement cycle from 8 AM today to 8 AM tomorrow. Then, it is determined whether the current clearing of this transaction belongs to normal cycle processing or abnormal processing after the cycle ends. If it is normal processing, the billing interval is added to the transaction start time to calculate the billing time. This is then combined with other clearing information and some fields shortened by sexagesimal encoding to construct the invoice number. If it is abnormal processing, the values of special bits are adjusted. After each adjustment, a new invoice number is generated in the aforementioned manner, and it is confirmed whether the corresponding invoice has been billed. If it has, the special bits are adjusted again until a usable invoice number is found; otherwise, failure is returned. The special field can be used to distinguish abnormally cleared invoices from normal invoices, making it easier for merchants to quickly locate and operate when they need to urgently replenish funds.
[0069] Furthermore, when adding the settlement results to the statistics field of the deposit statement, the settlement statement status for that transaction is updated synchronously using a transaction approach. A settlement statement status of "successful deposit" indicates that the transaction has been successfully tallied and cannot be added again, thus preventing the same transaction's settlement statement from being repeatedly tallied in the deposit statement. The transaction approach means that updating the settlement statement status and adding statistical data are completed within the same database transaction; both either succeed simultaneously or fail simultaneously, thus avoiding inconsistencies such as the status being updated but the data not being added, or the data being added but the status not being updated, ensuring the accuracy and consistency of the fund statistics.
[0070] In one implementation, the method further includes the following steps: Step S340: When the clearing process of the transaction fails, the transaction data of the transaction is stored in the abnormal pending clearing table; Step S350: Periodically retrieve transactions that failed to be cleared from the abnormal pending clearing table and re-execute the clearing process; Step S360: If the clearing process is successfully re-executed, remove the transaction from the abnormal pending clearing list; Step S370: During reconciliation, if a missing transaction is found in the abnormal pending clearing table, it is determined that the missing transaction has been processed.
[0071] In this embodiment, the pending clearing table is used to store transactions that cannot be cleared normally for the time being. Reasons for failure to clear transactions normally include system anomalies and configuration anomalies. System anomalies may specifically include database query or update failures, interface access anomalies, etc., while configuration anomalies may specifically include missing billing configurations, abnormal rate configurations, etc. The pending clearing table uses the transaction order number as the primary key, as shown in Table 2, and records information such as the transaction merchant number, transaction time, transaction amount, number of retries, retry status, creation time, and update time. Redundant records of transaction time and transaction amount are included for easy direct use in statistical data verification within a specified time period.
[0072] Table 2
[0073] The purpose of the Outstanding Transactions Pending Clearance List is twofold. First, the scheduled compensation task retrieves records that failed to clear from the list, replays them, and re-executes the clearing process. Once clearing is successful, the corresponding transactions are removed from the list. Second, the hourly reconciliation tool uses it as a pending clearing list. If a missing transaction discovered during reconciliation exists in this list, it is considered that the reconciliation discrepancy has been processed, thus distinguishing known anomalies from actual clearing omissions.
[0074] like Figure 7 As shown, an abnormal clearing order undergoes a complete clearing lifecycle on the timeline. The horizontal axis represents the timeline, marking each hour. The leftmost point indicates the moment when the clearing anomaly occurred for this next-day settlement transaction; after the anomaly occurred, the transaction was added to the abnormal pending clearing list. The abnormal re-push tool pulls abnormal data every minute for clearing re-push. It may succeed after 1 minute, or it may succeed after several hours of re-pushing, or it may succeed on the last retry before the end-of-day accounting. If clearing fails due to configuration issues, the transaction remains in the abnormal pending clearing list as pending clearing data. As long as the sum of the pending settlement amount and the normally settled amount matches the total transaction amount, the merchant can be settled. After the configuration is fixed, the transaction can be manually re-pushed to complete the clearing, which may be after the settlement cycle has ended. Through the cooperation of the abnormal pending clearing list and the compensation mechanism, abnormal transactions during the clearing process can be automatically identified, recorded, and retried, ensuring the integrity and final consistency of transaction clearing and reducing the impact of clearing anomalies on merchant settlement.
[0075] Step S400: Determine the recording time of the fund statistics information according to the settlement cycle.
[0076] In this embodiment, the billing time refers to the execution point at which the accumulated funds due to settle by the merchant within the settlement cycle are credited to the merchant's account. In this embodiment, the determination of the billing time needs to be based on both the channel's settlement cycle attribute and the merchant's custom billing cycle attribute. The channel's settlement cycle attribute characterizes the delay rule between the occurrence of a transaction and the crediting of funds under that channel. For example, domestic channels typically use a next-day settlement rule, while foreign card channels may use a settlement rule with a delay of several days, and the settlement benchmark may also be calculated based on local holidays. The merchant's custom billing cycle attribute characterizes the time boundary by which the merchant wants the funds due to settle to be collected. For example, for a merchant with an 8-8 billing cycle, the transactions due to settle include those that occurred between 08:00 yesterday and 08:00 today, and will begin to be credited at 08:00 today, i.e., after the end of the cycle. In addition, combined with the application scenarios of time-sharing settlement, merchants can also customize the transaction time period included in the funds to be settled according to their own business scenarios. For example, the 6 o'clock time-sharing settlement settles the transactions between 06:00 yesterday and 05:59 today. When this time-sharing settlement is used in conjunction with the real-time clearing mode, it constitutes a custom cycle.
[0077] In specific application scenarios, when using foreign cards for payment within China, transaction funds need to be settled to merchants according to the clearing and settlement cycle of the foreign card institution. For example, a settlement cycle of several days, such as S+3 or T+4, is required, which differs from the domestic D0 / D1 settlement cycle. Because the clearing and settlement processes are controlled separately, existing centralized batch processing models require unified clearing and settlement on the following day, while real-time clearing models require real-time clearing and settlement; neither can meet the needs of this type of delayed settlement. This embodiment, however, performs near-real-time clearing after the transaction is completed and configures delayed settlement based on the channel's settlement cycle, thus meeting the requirements of this application scenario.
[0078] Therefore, the settlement time is no longer limited to the fixed early morning of the next day, but can be flexibly determined according to the channel rules and merchant requirements, meeting the domestic common next-day settlement, and supporting personalized settlement needs such as time-sharing settlement and delayed settlement of foreign card transactions.
[0079] By determining the settlement time, the clearing and settlement are decoupled in terms of time. After the clearing is completed, the funds can be temporarily stored in transit and settled in a unified manner when the agreed settlement time arrives. There is no need to settle each transaction immediately after it is completed, thus meeting the merchants' real-time perception needs while controlling the financial risk.
[0080] Step S500: When the crediting time arrives, according to the fund statistics information, the crediting process for the merchant is executed centrally to credit the funds accumulated in the fund statistics information to the merchant's account.
[0081] In this embodiment, the posting process refers to the accounting operation of crediting the funds due to merchants from the fund statistics information to the merchant's account. A merchant account is an account established by the merchant in the accounting system to record its settlement funds. The accounting system has accounting operation capabilities such as balance management, freezing, and payment suspension. Funds in the merchant's account will be transferred to the merchant's linked bank account in the subsequent disbursement stage. In this embodiment, when the posting time arrives, a scheduled task initiates centralized posting processing. Based on the accumulated fund statistics information of the merchant during the settlement cycle, the funds due are centrally credited to the merchant's account, thereby completing the centralized posting by merchant.
[0082] Unlike traditional batch processing methods that centrally execute clearing and accounting in the early morning, the centralized accounting process in this embodiment only performs accounting entries. Its processing data comes from the fund statistics aggregated from completed clearing results, and it does not rely on external business data from the transaction process. Therefore, the processing logic is relatively simple, and the execution time of the early morning centralized accounting task can be reduced from over 30 minutes to less than 6 minutes. Furthermore, if the task is interrupted, it can be automatically recovered through disaster recovery, requiring no manual intervention; the number of manual interventions is zero. At the same time, since accounting is performed centrally by merchant, it avoids the problems of data bloat and uncontrollable financial risks caused by immediately recording each transaction in real time. In terms of funds and storage, it maintains consistency with existing clearing methods and does not introduce new risks.
[0083] In one implementation, the centralized execution of the merchant's accounting processing specifically includes the following steps: Step S510: Before performing the posting operation, check whether all reconciliation results of the reconciliation tasks within the preset time period are successful. Step S520: Obtain the clearing result associated with the fund statistics information, and compare the clearing result with the fund statistics information; Step S530: If the comparison results are consistent, perform the posting operation; wherein, the posting operation includes at least one of the following: posting the accumulated transaction funds to the merchant's account, deducting the accumulated handling fees, deducting the funds from the successfully refunded funds, and freezing the funds in the refund process; Step S540: After the inflow operation is completed, report the automatic withdrawal information to trigger the transfer of funds from the merchant's account to the merchant's bank account.
[0084] In this embodiment, the specific execution process of centralized accounting processing is as follows. For example... Figure 6As shown, before executing the posting operation, check whether all reconciliation results for the pre-defined time period were successful. To avoid missed settlements due to incomplete merchant clearing data, check whether all hourly reconciliation results from the reconciliation tool were successful within the previous 24 hours before executing the posting. The reconciliation tool will verify that each transaction has been cleared, or that although it cannot be cleared, it has been recorded in the abnormal pending clearing table. If there are any missing records, the posting cannot be executed, and you must wait for all prerequisite tasks to be completed before retrying.
[0085] Subsequently, the clearing results associated with the fund statistics are obtained and compared with the fund statistics. Specifically, all inflow records whose expected crediting time meets the crediting time parameter are retrieved. For each inflow record, all associated clearing records are pulled out and summarized by dimensions such as transaction amount, number of transactions, and refund amount. The summarized results are compared with the statistical amount on the inflow record to confirm whether the two are consistent. If they are inconsistent, it indicates that there is a problem with the fund data, which requires manual processing.
[0086] If the comparison results are consistent, the payment is processed. Payment processing includes various types of fund handling, specifically: crediting accumulated transaction funds to the merchant's account (i.e., topping up the funds due for transactions within the period); deducting accumulated transaction fees (i.e., deducting the accumulated transaction fees for the period from the merchant's due funds); deducting funds from successfully refunded transactions (i.e., deducting the corresponding amount from the due funds for transactions within the period that have been clearly refunded); and freezing funds in the process of being refunded (i.e., freezing funds in the process of being refunded without a clear refund outcome to control risk). Transactions in the process of being refunded without a clear refund outcome need to be extracted, summarized, and frozen separately until the refund outcome is clear before further processing.
[0087] Finally, after the deposit process is completed, the automatic withdrawal information is reported, thereby automatically generating withdrawal documents for the merchant to transfer funds from the merchant's account to the merchant's linked bank account. Through the above centralized deposit process, the integrity of fund data is ensured by double verification through reconciliation and summary comparison before deposit. During the deposit process, transaction funds, handling fees, and refund funds are centrally processed in a unified manner, and a freezing mechanism is used to control the fund risk in refunds. After the deposit is completed, the withdrawal process is connected, realizing a complete fund settlement process.
[0088] In one implementation, the method further includes the following steps: Step S610: Receive a refund request for the target transaction of the merchant; Step S620: Calculate the refundable handling fee and the refundable settlement amount based on the clearing result corresponding to the target transaction; Step S630: Based on the merchant's financial statistics, determine whether the merchant's available funds meet the refund amount requested in the refund request; Step S640: If the available funds meet the refund amount, update the refund statistics in the funds statistics information; Step S650: When the refund request has not been resolved within the settlement period, the funds corresponding to multiple refunds that are in the process of being refunded are aggregated to generate a total freeze document to freeze the funds, and the unfreezing and refreezing operations of the total freeze document are recorded.
[0089] In this embodiment, merchants can initiate refund requests for transactions that have already been successfully paid for. For example... Figure 5 As shown, the refund processing procedure includes: the real-time clearing service receiving a synchronous refund request initiated by the transaction system; calculating the refundable handling fee and settlement amount proportionally based on the forward transaction clearing information corresponding to the target transaction; determining whether the original transaction was processed under real-time clearing mode or real-time clearing mode, and using the same mode for refund processing. Specifically, if the original transaction was under real-time clearing mode, it checks whether the account balance is sufficient for the refund; if the original transaction was under real-time clearing mode, it generates an inbound invoice number and determines whether the available amount calculated by netting the in-transit statistical amount corresponding to the inbound invoice number is sufficient for the refund. If the account balance or in-transit funds are insufficient, the refund fails.
[0090] If the available funds meet the refund amount, update the refund statistics in the fund statistics information. That is, add the refund amount to the fund statistics information of the merchant's corresponding settlement period, so that the refund funds become a deduction item of the merchant's due funds in that period, and thus be uniformly deducted when the funds are centrally recorded.
[0091] like Figure 2 As shown, for situations where a refund request fails to yield a refund result within the settlement period—that is, when the refund is still pending during the period in which it was initiated—the settlement fund processing for that period needs to block these funds. This embodiment employs an accounting operation that aggregates the funds corresponding to multiple refunds pending, generating a single overall freeze order, and then freezes these funds. The reason for using an overall freeze order instead of freezing each refund individually is that there is a limit to the number of sub-requests that guarantee atomicity within an accounting request. For example, if a single request contains a maximum of 50 sub-requests, and 10,000 refunds are pending, then 200 freeze requests would need to be initiated. This is inefficient and fails to utilize the transactional nature of a single request. Furthermore, if anomalies occur between requests, the funds will be out of control, posing a security risk.
[0092] After generating the master freeze document, it is necessary to record the unfreezing and refreezing operations of the master freeze document, the identifier of the refund request that performed the operation, and the execution order of the operation. For example, when Refund Request 1 receives a clear refund success result in the next cycle, the master freeze document is unfrozen, the corresponding settlement amount of Refund Request 1 is deducted, and the remaining amount is refrozen. The above operations are completed in one transaction, and the regenerated freeze document corresponds to the settlement amount of Refund Request 2. When Refund Request 2 also receives a clear refund failure result later, the corresponding accounting document can be unfrozen.
[0093] Since the unfreezing operation of the account requires the provision of frozen documents, and the documents to be unfrozen in Refund Order 2 were refrozen by Refund Order 1, this information cannot be transmitted through the accounting system. Therefore, it is necessary to record the unfreezing and refreezing operations of all frozen documents, the refund request identifiers of the operations, and the execution order of the operations to track the ownership of the frozen documents corresponding to each refund and the order of operations, so as to ensure the correctness of fund operations.
[0094] By delegating the determination of refund eligibility to the clearing system based on inbound statement statistics, the control of refund funds is transferred from the trading system to the clearing system, thus enabling the interception of refund operations that pose a risk of financial loss.
[0095] In one implementation, determining whether the merchant's available funds meet the refund amount requested in the refund request specifically includes the following steps: Step S631: When the available funds of the first processing node corresponding to the refund request are insufficient to meet the refund amount, establish a fund occupation record corresponding to the refund amount; Step S632: Query the merchant's available funds from the second processing node, which is another processing node where the merchant has fund statistics information; Step S633: When the available funds of the second processing node meet the refund amount, it is determined that the refund request can be satisfied, and the funds corresponding to the refund amount are pre-occupied on the second processing node through the fund occupation record; Step S634: When the available funds of the second processing node are insufficient to meet the refund amount, the fund occupation record is released.
[0096] In this embodiment, cross-node refund processing is related to the multi-active node deployment of the clearing system. For example... Figure 3As shown, in a multi-active deployment system, the clearing system deploys multiple completely independent data center nodes. The data and services of each node are independent and isolated from each other, all simultaneously handling clearing and inbound traffic. The QR code transaction system has multiple systems with completely independent and isolated services and data, and the clearing and settlement system also has multiple independent systems corresponding to it. The advantage of complete isolation lies in its extreme fault tolerance capability, but it also increases the difficulty of designing global consistency at the business level.
[0097] For example, a merchant might generate transactions across multiple nodes, but their in-transit funds are split into multiple independent sets based on the number of active nodes, and these sets cannot be lent to each other. This means that from the merchant's perspective, refundable funds within the complete cycle cannot be returned. Although the situation where merchant transactions are distributed across multiple nodes is generally uncommon, the QR code transaction system periodically conducts system stress tests. Merchants previously routed to node A may switch their traffic to node B, and after the test is completed, they may switch back to node A. If a refund is attempted for transactions that occurred on node B at this time, it will fail because node B's refund processing only recognizes in-transit funds within its own node, while all new funds are recorded on node A. The failure rate can reach 100%.
[0098] In this embodiment, when determining whether a merchant's available funds meet the refund amount requested, if the available funds of the first processing node corresponding to the refund request do not meet the refund amount, a fund occupation record corresponding to the refund amount is established. Specifically, the fund occupation record can be a stop-payment plan in the clearing system, which is a global, cross-node fund control measure.
[0099] Specifically, when the first processing node finds insufficient available funds in transit, it establishes a stop payment plan corresponding to the refund settlement amount, and then queries the second processing node for its current available funds in transit. If the second processing node has sufficient available funds in transit for the refund, it determines that the refund request can be fulfilled, and pre-allocates the funds corresponding to the refund amount on the second processing node through the stop payment plan. All refunds occurring on the second processing node will have this stop payment plan amount deducted, thereby preventing funds from being used repeatedly for refunds. If the second processing node has insufficient available funds in transit, it cancels the newly established stop payment plan and returns a refund failure message.
[0100] By using a cross-node pre-accounting mechanism for fund usage records, the problem of refund failures caused by fragmented refund fund statistics under multi-active node deployment is solved, while ensuring that the same fund is not used for multiple refunds.
[0101] In one implementation, the method further includes the following steps: Step S710: When the transaction to be settled is a transaction to be settled on the same day and the settlement is not completed on the transaction date of the transaction to be settled, the transaction to be settled is pushed to the clearing and sorting process after the transaction date to perform the clearing and sorting process on the transaction to be settled. The same-day settlement process is executed only on the transaction date of the pending transaction, and the clearing process is executed only on transactions with a processing date later than the transaction date, in order to avoid the pending transaction being settled twice. Step S720: Before centrally executing the payment processing for the merchants, confirm that the push task for the pending settlement transactions has been completed.
[0102] In this embodiment, to fully replace the existing model of centralized batch clearing and settlement in the early morning with a new model, the clearing process also needs to handle the settlement of same-day settlement transactions converted to next-day settlement transactions. Same-day settlement transactions refer to transactions that are cleared and settled on the same day, characterized by settlement only within the same calendar day. In some scenarios, such as risk control rule blocking or same-day settlement permission issues, transactions cannot be processed using the same-day settlement method, and these transactions need to be converted to the next-day settlement method.
[0103] Specifically, when a transaction awaiting settlement is a same-day settlement transaction that has not been settled on the transaction date, the transaction awaiting settlement will be pushed to the clearing and settlement process after the transaction date for clearing and settlement. That is, abnormal settlement orders from the daily settlement processing exception table will be directly retrieved and pushed to real-time clearing and settlement for processing, and then centrally recorded together with normal next-day settlement transactions.
[0104] Furthermore, it is also necessary to ensure fund security and the integrity of clearing. Firstly, the clearing data for same-day and next-day settlements are independent, making it impossible to prevent duplicate transactions through database constraints. Since same-day settlement can only be completed on the day of the transaction, any abnormal interception issues can be resolved and the transaction resubmitted for a re-settlement attempt. However, once the 24:00 mark of the current day has passed, it can only be converted to next-day settlement, and the same-day settlement system will refuse to process it. Therefore, the task of pushing same-day settlement to next-day settlement is set to begin after 00:00 on the following day. If a same-day settlement transaction is mistakenly pushed to the clearing process on the same day, the clearing process will also refuse to process it; only transactions with processing dates after the transaction date are allowed to be processed. That is, the clearing processing is selected based on the transaction time; only same-day settlement can process transactions on the same day, and only clearing processing can process transactions after that day. This time-based division ensures that a transaction can only be successfully processed by one system, avoiding duplicate settlements. As a long-term design, the clearing data for same-day and next-day settlements can be merged into a single clearing table, relying on database characteristics to avoid the risk of duplicate entries.
[0105] Secondly, although the deposits and automatic withdrawals of these funds converted to next-day settlement are pushed out by a dedicated bypass task on a scheduled basis every other day, rather than triggered by transaction pushes, they are essentially real-time clearing funds for next-day settlement. Only some business-related attribute markers differ. They can be deposited and withdrawal information reported together with other normal next-day settlement transactions. Since the push task and the centralized deposit task are two unrelated scheduled tasks, there is a possibility that the push task may not be completed when the centralized deposit begins, resulting in missed deposits and reports. Therefore, before centrally executing the deposit processing for merchants, it is necessary to confirm that the push task for the pending settlement transactions has been completed. That is, the centralized deposit task must depend on the completion of the next-day settlement conversion task before deposits can be executed.
[0106] Finally, to address the potential issue of missed settlements, the current approach directly uses abnormal settlement data from the same day as the data source for push notifications, leveraging the strong reconciliation and synchronous push mechanisms of the same-day settlement to eliminate the risk of missed settlements. Through these measures, same-day settlement transactions can be safely converted to next-day settlement in abnormal situations, ensuring the integrity of the settlement function after replacing the existing batch processing mode.
[0107] In summary, compared with existing technologies, this invention separates the clearing and settlement process from centralized batch processing in the early morning and makes it near real-time, enabling merchants to obtain the transaction fees and settlement amounts for each transaction immediately after completion, thus achieving real-time awareness of clearing and settlement information. At the same time, it uses the invoice as a carrier to collect clearing and settlement results by merchant and settlement cycle, and performs centralized invoicing when the invoicing time arrives. This reduces the early morning invoicing task to only require completing the accounting invoicing operation, reducing the task execution time from more than 30 minutes to less than 6 minutes. Furthermore, task interruptions can be automatically recovered through disaster recovery without manual intervention. The refund eligibility assessment relies on the in-transit statistics of incoming bills. Control of refund funds is transferred from the transaction system to the clearing system, enabling the interception of refund operations with potential financial losses. The system also ensures the safety of cross-cycle refund funds through a total frozen document and unfreezing / refreezing operation records. An abnormal pending clearing list and compensation re-push mechanism automatically identify, record, and retry clearing anomalies, and reconciliation discrepancies are traceable. A cross-node fund occupation record pre-holding mechanism solves the refund failure problem caused by fragmented refund fund statistics in multi-active deployments. The conversion of same-day settlement transactions to next-day settlement avoids duplicate clearing and missed entries through time demarcation and task dependency control, ensuring the complete replacement of the clearing function. The above solution supports personalized needs such as time-sharing settlement and delayed entry of foreign cards according to the settlement cycle, and can monitor data anomalies such as abnormal rate configurations in real time.
[0108] like Figure 10 As shown in the figure, this embodiment of the invention provides a fund clearing and processing system, which includes: a transaction data acquisition module 10, a clearing module 20, a fund statistics information processing module 30, a deposit time determination module 40, and a deposit module 50.
[0109] Specifically, the transaction data acquisition module 10 is used to acquire transaction data; the clearing module 20 is used to, in response to the completion of the transaction, perform clearing processing on the transaction based on the transaction data to obtain the clearing result of the transaction; wherein, the clearing result includes the transaction fee and the amount to be settled; the funds statistics information processing module 30 is used to, based on the clearing result, aggregate the transaction into the funds statistics information corresponding to the settlement cycle of the merchant to which the transaction belongs; wherein, the funds statistics information is used to accumulate the funds data of the merchant in the settlement cycle, and the funds data includes transaction funds and / or refund funds; the crediting time determination module 40 is used to, based on the settlement cycle, determine the crediting time of the funds statistics information; the crediting module 50 is used to, upon reaching the crediting time, centrally execute the crediting processing of the merchant based on the funds statistics information to credit the funds accumulated in the funds statistics information to the merchant's account.
[0110] Based on the above embodiments, the present invention also provides a terminal device, the principle block diagram of which can be as follows: Figure 11 As shown, the terminal device includes a processor, memory, network interface, display screen, and temperature sensor connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements a fund clearing processing method. The display screen can be an LCD screen or an e-ink screen. The temperature sensor is pre-installed inside the terminal device to detect the operating temperature of the internal components.
[0111] Those skilled in the art will understand that Figure 11 The schematic diagram shown is only a partial structural diagram related to the present invention and does not constitute a limitation on the terminal device to which the present invention is applied. The specific terminal device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.
[0112] In one embodiment, a terminal device is provided, including a memory and one or more programs, wherein one or more programs are stored in the memory and configured to be executed by one or more processors, the one or more programs including instructions for performing operations as described in the embodiments of the methods above.
[0113] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided by this invention can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.
[0114] 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 specification.
[0115] 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 method for clearing and processing funds, characterized in that, The method includes: Obtain transaction data for the transaction; In response to the completion of the transaction, a clearing process is performed on the transaction based on the transaction data to obtain the clearing result of the transaction; wherein, the clearing result includes the transaction fee and the amount to be settled; Based on the clearing results, the transactions are aggregated into the fund statistics information corresponding to the settlement cycle of the merchant to which the transaction belongs; wherein, the fund statistics information is used to accumulate the fund data of the merchant within the settlement cycle, and the fund data includes transaction funds and / or refund funds; The time for recording the funds statistics information is determined based on the settlement cycle. When the payment time arrives, based on the fund statistics information, the payment processing for the merchant is executed centrally to transfer the funds accumulated in the fund statistics information to the merchant's account; The step of aggregating the transaction into the fund statistics information corresponding to the settlement cycle of the merchant to which the transaction belongs, based on the clearing results, includes: Based on the transaction attributes of the transaction, an inbound bill number corresponding to the settlement period is generated; wherein, the transaction attributes include at least one of the following: transaction merchant number, clearing channel number, business type, inbound interval days, and custom period, and the inbound interval days are determined according to the settlement period of the channel to which the transaction belongs; Perform a base conversion and compression on the preset fields in the billing number; The clearing results are accumulated into the statistics field of the inbound bill corresponding to the compressed inbound bill number; wherein, the inbound bill is used to record the merchant's fund inflows and outflows during the settlement period, and when accumulating the clearing results, the clearing bill status of the transaction is updated synchronously in a transactional manner, the clearing bill status is used to indicate that the transaction has been statistically completed, so as to prevent the transaction from being accumulated repeatedly.
2. The fund clearing and processing method according to claim 1, characterized in that, The method further includes: When the clearing process of the transaction fails, the transaction data of the transaction is stored in the abnormal pending clearing table; Periodically retrieve transactions that failed to be cleared from the abnormal pending clearing table and re-execute the clearing process; If the clearing process is successfully re-executed, the transaction will be removed from the list of abnormal pending clearing transactions; If, during reconciliation, a missing transaction is found in the abnormal pending clearing table, then the missing transaction has been determined to have been processed.
3. The fund clearing and processing method according to claim 1, characterized in that, The centralized execution of the merchant's accounting processing includes: Before performing the posting operation, check whether the reconciliation results of the reconciliation tasks within the preset time period are all successful; Obtain the clearing results associated with the fund statistics information, and compare the clearing results with the fund statistics information; If the comparison results are consistent, the posting operation is performed; wherein, the posting operation includes at least one of the following: posting the accumulated transaction funds to the merchant's account, deducting the accumulated handling fees, deducting the funds from the successfully refunded funds, and freezing the funds in the refund process; After the deposit operation is completed, automatic withdrawal information is reported to trigger the transfer of funds from the merchant's account to the merchant's bank account.
4. The fund clearing and processing method according to claim 1, characterized in that, The method further includes: Receive a refund request for the target transaction of the merchant; Calculate the refundable handling fee and the refundable settlement amount based on the clearing results corresponding to the target transaction; Based on the merchant's financial statistics, determine whether the merchant's available funds meet the refund amount requested in the refund request; If the available funds meet the refund amount, update the refund statistics in the fund statistics information; When the refund request has not been resolved within the settlement period, the funds corresponding to multiple refunds that are in the process of being refunded are aggregated to generate a total freeze document, which is used to freeze the funds and record the unfreezing and refreezing operations of the total freeze document.
5. The fund clearing and processing method according to claim 4, characterized in that, The step of determining whether the merchant's available funds meet the refund amount requested includes: When the available funds of the first processing node corresponding to the refund request are insufficient to meet the refund amount, a fund occupation record corresponding to the refund amount is established; The available funds of the merchant are queried from the second processing node, which is another processing node where the merchant has fund statistics information; When the available funds of the second processing node meet the refund amount, it is determined that the refund request can be satisfied, and the funds corresponding to the refund amount are pre-allocated on the second processing node through the fund occupation record; When the available funds of the second processing node are insufficient to meet the refund amount, the fund occupation record is released.
6. The fund clearing and processing method according to claim 1, characterized in that, The method further includes: When a transaction pending settlement is a transaction to be settled on the same day and settlement is not completed on the transaction date of the transaction pending settlement, the transaction pending settlement is pushed to the clearing and settlement process after the transaction date to perform the clearing and settlement process on the transaction pending settlement. The same-day settlement process is executed only on the transaction date of the pending transaction, and the clearing process is executed only on transactions with a processing date later than the transaction date, in order to avoid the pending transaction being settled twice. Before centrally executing the billing process for the merchants, confirm that the push task for the pending settlement transactions has been completed.
7. A funds clearing and processing system, characterized in that, The system, used to implement the fund clearing and processing method as described in any one of claims 1-6, comprises: The transaction data acquisition module is used to acquire transaction data. The clearing module is used to respond to the completion of the transaction by performing clearing processing on the transaction based on the transaction data, and obtaining the clearing result of the transaction; wherein, the clearing result includes the transaction fee and the amount to be settled; The funds statistics information processing module is used to aggregate the transaction into the funds statistics information corresponding to the settlement cycle of the merchant to which the transaction belongs, based on the clearing result; wherein, the funds statistics information is used to accumulate the merchant's funds data within the settlement cycle, and the funds data includes transaction funds and / or refund funds; The deposit time determination module is used to determine the deposit time of the fund statistics information based on the settlement cycle. The payment module is used to centrally execute payment processing for the merchant based on the fund statistics information when the payment time arrives, so as to transfer the funds accumulated in the fund statistics information to the merchant's account.
8. A terminal device, characterized in that, The terminal device includes a memory, a processor, and a funds clearing processing program stored in the memory and executable on the processor. When the processor executes the funds clearing processing program, it implements the steps of the funds clearing processing method as described in any one of claims 1-6.
9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a funds clearing processing program, which, when executed by a processor, implements the steps of the funds clearing processing method as described in any one of claims 1-6.