Transaction end state processing method, system, and storage medium

Abstract

The application discloses a transaction end state processing method and system and a storage medium, and relates to the technical field of payment data processing. The method comprises the following steps: if the payment system initiates an online transaction and the transaction is in a processing state or the transaction is overdue, then the system initiates multiple asynchronous state queries based on the query strategy of a first configuration table and returns the processing state to the upstream; if the transaction returns an end state during each query, the system notifies the upstream after completing the account processing; if the transaction returns a non-end state and contains a business response code, the system queries a second configuration table, and if there is a matching business response code and the time length exceeds a time threshold, the system determines that the transaction is in a failed end state and notifies the upstream; if all the queries are completed and the transaction is still in the processing state, the system registers a daily error table and reminds the operator; when the operator initiates a query, the system determines the end state again, provides a supplementary account or a reversal operation if the transaction end state is obtained, and sets the end state through offline verification if the transaction end state cannot be obtained. The application improves the timeliness and automation level of transaction end state acquisition, and avoids the risk of customer overdue credit investigation.

Description

Technical Field

[0001] This invention relates to the field of payment data processing technology, and in particular to a method, system, and storage medium for processing the final state of a transaction. Background Technology

[0002] In the fintech payment field, payment systems typically need to interact with downstream systems (including core accounting systems, various payment channels, etc.) to complete financial transactions. The complete lifecycle of a transaction requires a clear final state (success or failure) to facilitate accounting processing, customer notification, and subsequent business operations.

[0003] Currently, when a payment system initiates a transaction to a downstream system, if the downstream system fails to return the final state of the transaction in the online response, such as due to a response timeout or the downstream system explicitly returning a "processing" status, existing technologies generally handle this in the following two ways: Active polling query: The payment system repeatedly initiates status queries to downstream systems at fixed or incremental time intervals until the final state of the transaction is obtained or the maximum number of queries is reached.

[0004] End-of-day reconciliation: The payment system performs batch reconciliation with downstream systems at the end of each day and corrects transaction status in batches based on the reconciliation results.

[0005] However, the aforementioned existing technologies have the following obvious shortcomings in practical applications: (1) The failure of the polling mechanism in complex downstream environments: Some downstream systems have defects, or the downstream systems are connected to deeper downstream systems (multi-layer nesting), causing the transaction status to remain in the "processing" or timeout state for a long time. In this case, even if the payment system polls continuously, it is difficult to obtain the final state of the transaction in a short time. The polling efficiency is low and the system resources are wasted.

[0006] (2) Timeliness defects of end-of-day reconciliation: End-of-day reconciliation is usually carried out after the end of the business day. For customer transactions with high timeliness requirements, such as repayments, if it is necessary to wait until the end of the day to confirm whether the transaction has failed or succeeded, customers may default on their payments due to not being informed of the results in time, which may lead to credit issues. In addition, if the actual transaction has been successful but has not been processed in time due to reconciliation delays, customers may make duplicate payments or miss the repayment window.

[0007] (3) Lack of automatic final state determination capability in special error scenarios: In actual business, there are situations where "query transactions arrive in the downstream system before accounting transactions." In this case, the downstream system may return non-final state business response codes such as "no transaction record," but the subsequent accounting transaction may actually be successful. Conversely, the original accounting transaction may not have arrived in the downstream system at all due to network timeout, and the query will also return "no transaction record." Existing polling and end-of-day reconciliation technologies cannot automatically distinguish the above scenarios and directly determine the final state, resulting in a large number of such transactions requiring manual intervention or delayed processing, further reducing processing efficiency.

[0008] In summary, existing methods for handling the final state of financial transactions have significant shortcomings in three aspects: the ability to acquire the final state in complex downstream environments, the processing efficiency in high-time-sensitivity scenarios, and the automatic determination of the final state of special business response codes. Therefore, there is an urgent need for a technical solution that can automatically determine the final state in certain special scenarios and provide a rapid manual intervention mechanism for transactions that cannot be finalized for extended periods. Summary of the Invention

[0009] To address the shortcomings of existing technologies, this invention provides a transaction final state processing method, system, and storage medium that can automatically determine the transaction final state in special error scenarios. By combining asynchronous progressive querying with manual intervention, it can efficiently obtain the final state of transactions that have timed out or are in the process, thus preventing customers from experiencing overdue payments and credit issues due to reconciliation delays.

[0010] In a first aspect, the present invention provides a method for processing the final state of a transaction, comprising: Step S1: After the payment system initiates an online transaction to the downstream system, if the transaction times out or the downstream system returns a "processing" status, it reads the first configuration table, initiates multiple asynchronous status queries in sequence based on the query strategy set in the first configuration table, and returns "processing" to the upstream. Step S2: For each asynchronous status query, the payment system makes a judgment based on the query results returned by the downstream system: If the transaction is returned to its final state, the upstream supplier will be notified after the accounting is completed according to the transaction type, and subsequent queries will be terminated. If a non-final state is returned and a business response code is included, then the second configuration table is queried. The second configuration table is configured with the business response code and its corresponding time threshold. If the business response code is configured in the second configuration table and the time from the transaction initiation to the current query response has exceeded the corresponding time threshold, it is determined to be a failed final state. After completing the accounting processing according to the transaction type, the upstream is notified and subsequent queries are terminated; otherwise, the "processing" state is maintained and the next asynchronous state query continues. Step S3: If all queries have been completed and the transaction status is still "processing", then register the transaction in the daytime error table and remind the operations staff; Step S4: When the operations staff initiates an active query on the transactions in the daytime error table, the payment system queries the downstream system again and determines whether the transaction has reached its final state according to the rules for determining the final state of the transaction in Step S2. If the final state of the transaction is obtained, the system provides options for supplementary accounting, reversal, or resending based on the transaction scenario. After being triggered by the operations staff, the system calls the core accounting system to complete the accounting processing synchronously and notifies the upstream. Step S5: If the final state of the transaction still cannot be obtained in step S4, then provide options for successful adjustment and failed adjustment; after offline verification by the operations personnel, the final state of the transaction is forcibly set. The payment system automatically determines whether it is necessary to make up the account, reverse the transaction, or resend the channel based on the transaction type and timeout scenario, and provides corresponding operation options. After being triggered by the operations personnel, the core accounting system is called to complete the accounting process synchronously, and finally the upstream is notified.

[0011] Step S1 of this invention employs a multiple asynchronous status query strategy based on a first configuration table. Compared to the fixed-frequency polling in existing technologies, this strategy allows for flexible configuration of the query interval according to business needs, efficiently obtaining the final state of a transaction within a limited number of queries. Step S2, for non-final states that carry business response codes, introduces a time threshold from a second configuration table for judgment. When the time from transaction initiation to the current response exceeds the threshold, it is automatically determined to be a failed final state, eliminating the need to wait for end-of-day reconciliation. This mechanism shortens many transactions that originally required processing every other day to be completed within a single day, significantly improving the timeliness of final state acquisition.

[0012] In step S2, for non-final transactions that meet the business response code configuration but have timed out, the system automatically determines them as failed final states and completes the accounting processing, preventing such transactions from entering the manual processing flow. In step S4, when operations personnel initiate an active query for transactions in the daily error report, the system reuses the automatic judgment logic of step S2, which can quickly obtain the final state of the transaction and directly provide channels for reconciliation, reversal, or resending, without the need for offline verification. The above mechanism ensures that only a very small number of transactions that cannot be automatically determined enter the offline verification process in step S5, significantly reducing the proportion of transactions requiring manual intervention and alleviating the workload of operations personnel.

[0013] For time-sensitive transactions such as loan repayments, existing technologies that rely on end-of-day reconciliation may result in customers not knowing the transaction results on the same day, leading to overdue payments. This invention, through its daytime processing mechanism in steps S1 to S4, can obtain the final status of a transaction or complete a proactive manual inquiry on the day the transaction occurs, promptly notifying upstream electronic channels of the transaction results and effectively preventing customer credit issues caused by reconciliation delays.

[0014] In step S3 of this invention, transactions that cannot automatically obtain a final state are registered in the intraday error table and the operators are alerted to ensure that unprocessed transactions are not lost. Steps S4 and S5 provide multi-level manual intervention methods (actively querying the supplementary / reversal / reissue channels, and offline verification of the forced final state), so that every transaction, regardless of the anomaly it experiences, can ultimately obtain a clear success or failure final state and complete the corresponding accounting processing, meeting the strict requirements of the financial system for transaction consistency.

[0015] In summary, the technical solution described in this invention solves the technical problems of low polling efficiency, poor reconciliation timeliness, and inability to automatically determine special error scenarios in the prior art, and achieves beneficial technical effects such as improving timeliness, reducing labor costs, avoiding customer credit risks, and ensuring final state consistency.

[0016] Furthermore, the first configuration table includes channel code, service type, first query interval, subsequent query interval, query time increment multiplier, and total number of increments; the second configuration table includes channel code, service type, service response code, and time threshold.

[0017] The first configuration table enables the payment system to flexibly configure the start time, interval, increment multiplier, and total number of queries for asynchronous queries based on different downstream systems and business types. This achieves differentiated and refined control of the query strategy, avoiding the use of a uniform and ineffective polling for all transactions, thereby improving query efficiency and reducing system resource consumption. The second configuration table allows the payment system to set independent automatic judgment time thresholds for specific business response codes of different downstream systems and business types. This enables differentiated automatic final state judgment for special non-final state scenarios such as those without transaction history, further improving the accuracy and flexibility of automatic judgment.

[0018] Furthermore, the intraday error table includes error ID, error intraday time, core transaction status, error type, error description, error handling method, error handling time, and error handling status; the error type includes channel transaction timeout, channel transaction failure, core transaction timeout, and core transaction failure; the error handling method includes query, reversal, account refill, resend channel, adjustment successful, adjustment failed, and ignore.

[0019] The daytime error log provides a complete tracking record for every transaction that enters the manual processing flow, ensuring that operations personnel can clearly understand the source, cause, and current processing progress of errors. It clearly distinguishes different error types, enabling the system to automatically match the corresponding error handling logic based on the error type (such as querying the channel when the channel times out, and querying the core when the core times out), improving the automation level of error handling. The error handling methods enumerate complete operations such as query, reversal, reconciliation, resending the channel, adjustment success, adjustment failure, and ignoring, covering all processing scenarios that may occur in actual business, ensuring the completeness of error handling.

[0020] Furthermore, in step S2, completing the accounting process includes: For credit transactions, where the core accounting system first deducts the payment and then sends it to the payment channel: If a timeout occurs in the core accounting system, the core transaction status is retrieved through a query: if it is a successful final state, the channel transaction process is triggered; if it is a failed final state, the transaction failure is returned to the upstream. If a timeout occurs in the payment channel, the transaction status of the payment channel is retrieved by querying: if it is a successful final state, a successful transaction is returned to the upstream; if it is a failed final state, a synchronous reversal operation is performed, and a failed transaction is returned to the upstream. For debit transactions, which are transactions where funds are first sent to the payment channel for deduction and then recorded by the core accounting system: If a timeout occurs in the core accounting system, the core transaction status is retrieved through querying: if it is a successful final state, a successful transaction is returned to the upstream; if it is a failed final state, a synchronous reconciliation operation is performed, and if the reconciliation fails, it is recorded in the intraday error table. If a timeout occurs in the payment channel, the transaction status of the payment channel is retrieved through query: if it is a successful final state, a synchronous reconciliation operation is performed and a successful transaction is returned to the upstream; if it is a failed final state, a failed transaction is returned to the upstream.

[0021] The above-mentioned differentiated processing not only complies with financial business rules (credit channel failures require reversal and refund, debit channel successes require account reconciliation), but also reduces unnecessary system operations (credit channel failures do not send to the channel, debit channel failures directly return failure), thus improving the accuracy, completeness, and efficiency of accounting processing.

[0022] Furthermore, the supplementary accounting operation involves calling the core accounting system to synchronously complete the accounting, and the reversal operation involves calling the core accounting system to synchronously complete the reverse accounting.

[0023] This invention clarifies the executing entity (core accounting system) and operating method (synchronous) of accounting operations, ensuring the timeliness and consistency of accounting processing. Synchronous calls guarantee that the results of reversal or correction operations can be returned immediately, facilitating the payment system to update transaction status and notify upstream entities in a timely manner, avoiding status delays or secondary inconsistencies that may arise from asynchronous calls. Furthermore, centralizing the execution of posting and correction operations by the core accounting system aligns with the layered and decoupled design principles of financial systems, facilitating accounting auditing and error tracing.

[0024] Furthermore, in step S4: When the transaction is a debit remittance transaction and the error type is channel transaction timeout, the payment system, after querying and determining in step S2, will: If the final state of a failed channel transaction is obtained, the transaction status is updated to failed; if the final state of a successful channel transaction is obtained, the option to perform a reconciliation operation is provided, which is triggered by the operations personnel and calls the core accounting system to complete the accounting. When the transaction is a credit remittance transaction and the error type is channel transaction timeout, the payment system, after querying and determining in step S2, will: If the final state of a failed channel transaction is obtained, a reversal operation option is provided, which is triggered by the operations personnel and calls the core accounting system to complete the reverse accounting; if the final state of a successful channel transaction is obtained, the transaction status is updated to successful.

[0025] This invention further defines the specific processing branches for debit and credit remittance in step S4 for channel transaction timeout scenarios. For debit remittance transactions, if the channel query returns a failure final state, the status is directly updated to failure; if it returns a success final state, a reconciliation operation is provided, achieving automatic remedy for scenarios where the channel is successful but not recorded. For credit remittance transactions, if the channel returns a failure final state, a reversal operation is provided; if it returns a success final state, the status is directly updated to success. The technical effect of this limitation is that it provides a complete automated or semi-automated processing path for the common error type of channel transaction timeout, allowing operators to directly complete accounting corrections without offline verification, significantly improving error handling efficiency, while ensuring the correctness of different business logics for debit and credit.

[0026] Furthermore, in step S4: When the transaction is a debit remittance transaction and the error type is core transaction timeout, the payment system, after querying and determining in step S2, will: If the core transaction fails, an option to perform a reconciliation operation is provided, which is triggered by the operations staff and calls the core accounting system to complete the accounting; if the core transaction succeeds, the transaction status is updated to successful. When the transaction is a credit remittance transaction and the error type is core transaction timeout, the payment system, after querying and determining in step S2, will: If the core transaction fails, the transaction status is updated to failure. If the core transaction succeeds, either a reversal operation or a resend channel operation is provided, which is selected and triggered by the operations personnel. The reversal operation option calls the core accounting system to complete the reverse accounting, while the resend channel operation option updates the transaction status to success after receiving a successful channel response.

[0027] This invention further defines the specific processing branches for debit and credit remittances in step S4 for core transaction timeout scenarios. For debit remittance transactions, if the core query returns a failure final state, a reconciliation operation is provided; if it returns a success final state, the status is directly updated to success. For credit remittance transactions, if the core query returns a failure final state, the status is updated to failure; if it returns a success final state, a reversal operation or a resend channel operation is provided for operations personnel to choose from. The technical effect of this limitation is that it provides flexible processing options for the special error type of core transaction timeout. Operations personnel can choose to reverse and cancel the transaction or choose the resend channel to ensure the transaction is eventually completed, thus adapting to different needs in complex business scenarios (such as repayment transactions, which may prefer resend rather than reversal). At the same time, the differentiated processing of debits and credits also conforms to their respective accounting characteristics, improving the system's business adaptability.

[0028] Furthermore, in step S5: When the transaction is a debit transfer transaction, and the timeout scenario is a channel transaction timeout and the final state of the payment channel transaction cannot be obtained after querying in step S4, the following is verified offline by the operations personnel: If the actual transaction is successful, the final state of the transaction is forcibly set by adjusting the success option, and then the option to make up the difference is provided. After the operation personnel trigger it, the core accounting system is called to complete the accounting. If the actual transaction fails, the final state of the transaction is forcibly set by adjusting the failure option, and the processing ends. When the transaction is a debit remittance transaction, and the timeout scenario is a core transaction timeout, and the final state of the transaction in the core accounting system cannot be obtained after querying in step S4, the following verification was conducted offline by operations personnel: If the actual transaction is successful, the transaction final state is forced to be set by adjusting the success option, and the processing ends; if the actual transaction fails, the core accounting transaction is forced to fail by adjusting the failure option, and then the option to make up the account is provided. After being triggered by the operations personnel, the core accounting system is called to complete the account making up. When the transaction is a credit remittance transaction, and the timeout scenario is a core transaction timeout, and the final state of the core accounting system transaction cannot be obtained after querying in step S4, the following verification was conducted offline by operations personnel: If the actual transaction is successful, the final state of the transaction is forcibly set by adjusting the success option, and then the reversal operation option or the resend channel operation option is provided according to the error type, which is selected and triggered by the operations personnel; if the actual transaction fails, the final state of the transaction is forcibly set by adjusting the failure option, and the transaction final state is failure, and the processing ends. When the transaction is a credit transfer transaction, and the timeout scenario is a channel transaction timeout and the final state of the payment channel transaction cannot be obtained after querying in step S4, the following verification was conducted offline by the operations personnel: If the actual transaction is successful, the transaction final state is forcibly set by adjusting the success option, and the processing ends; if the actual transaction fails, the payment channel transaction status is forcibly set to failure by adjusting the failure option, and then the reversal operation option or the resend channel operation option is provided for the operators to choose to trigger.

[0029] This invention further defines the specific processing branch in step S5 for cases where the final state of a transaction cannot be obtained after the query in step S4, following offline verification by operations personnel. It differentiates between timeout scenarios (channel transaction timeout or core transaction timeout) and transaction types (debit remittance or credit remittance). This differentiation provides a fallback solution for transactions where the final state cannot be automatically obtained in extreme cases. By distinguishing between timeout scenarios (channel timeout or core timeout) and offline verification results (actual success or actual failure), differentiated mandatory final state settings and accounting processing strategies (remediation, reversal, resending the channel, or termination) are adopted for different situations, ensuring that every transaction ultimately obtains a clear state and correct accounting processing. Simultaneously, by adjusting success and failure options, operations personnel are guided to first forcibly set the final state, and then the system automatically provides corresponding remediation or reversal operation options based on the judgment, processing according to standardized procedures to avoid secondary errors due to operational mistakes. This mechanism guarantees the final consistency of the final state of financial transactions, meeting the highest requirements of financial systems for data accuracy and integrity.

[0030] Secondly, the present invention also provides a transaction finality processing system, including a payment system, the payment system comprising: The storage unit is used to store a first configuration table, a second configuration table, and a daytime error table; wherein, the first configuration table is configured with an asynchronous query strategy, the second configuration table is configured with a business response code and its corresponding time threshold, and the daytime error table is used to register transaction records that have not obtained the final state of the transaction; The asynchronous query unit is used to read the first configuration table after executing an online transaction to the downstream system. If the transaction times out or the downstream system returns a "processing" status, the unit will initiate multiple asynchronous status queries to the downstream system in sequence based on the query strategy set in the first configuration table and return "processing" to the upstream system. The unit will also continue or terminate subsequent queries according to the instructions of the final status judgment unit. The final state determination unit is used to receive the return result of each asynchronous state query and make a judgment: If the transaction is returned to its final state, the accounting unit is notified to process the accounting, the upstream transaction is notified of its final state, and an instruction to terminate subsequent queries is sent to the asynchronous query unit. If a non-final state is returned and a business response code is included, the second configuration table is queried. If the business response code is configured in the second configuration table and the time from the transaction initiation to the current query response has exceeded the corresponding time threshold, it is determined to be a failed final state. The accounting unit is notified to perform accounting processing, the upstream transaction is notified of failure, and an instruction to terminate subsequent queries is sent to the asynchronous query unit. Otherwise, an instruction to continue the next query is sent to the asynchronous query unit. The accounting processing unit is used to call the core accounting system to synchronously complete the supplementary accounting operation or the reversal operation according to the instructions of the final state judgment unit; The error registration unit is used to register the transaction in the daytime error table and trigger an operational staff reminder if the transaction status is still "processing" after the asynchronous query unit has completed all configured queries. The proactive query processing unit is used to respond to proactive queries from operations personnel regarding transactions in the daily error table, query the downstream system again, and call the rules for final state determination in the final state determination unit to determine whether the transaction has reached the final state. If the final state of the transaction is obtained, the unit provides options for supplementary accounting, reversal, or resending based on the transaction scenario. After being triggered by operations personnel, the unit calls the accounting processing unit to complete the accounting processing and notifies the upstream. The offline verification and processing unit is used to provide options for successful adjustment and failed adjustment if the final state of the transaction cannot be obtained after active inquiry. In response to the final state of the transaction set by the operations personnel after offline verification, the payment system automatically determines whether it is necessary to make up the account, reverse the transaction or resend the channel based on the transaction type and timeout scenario, and provides corresponding operation options. After being triggered by the operations personnel, the accounting processing unit is called to complete the accounting processing, and finally the upstream is notified.

[0031] This invention defines the specific structure of a transaction final state processing system. Through the storage unit, asynchronous query unit, final state judgment unit, accounting processing unit, error registration unit, active query processing unit, and offline verification processing unit set up within the payment system, the following technical effects are achieved at the system structure level: The storage unit independently manages the storage of the first configuration table, the second configuration table, and the daily error table, thus separating query strategy parameters, business response code judgment rules, and error records from the business logic of the payment system. When it is necessary to adjust the query interval, time threshold, or add new error types, only the configuration data in the storage unit needs to be updated, without modifying the program code of other units, significantly reducing system maintenance costs and upgrade risks.

[0032] The asynchronous query unit controls the query process based on the continue or terminate instructions issued by the final state determination unit, avoiding logical coupling caused by the asynchronous query unit determining the final state on its own. The final state determination unit focuses on determining the returned result, while the asynchronous query unit focuses on initiating and terminating the query. Each unit performs its own function, making the system's control flow clear and controllable, facilitating unit-level testing and fault location.

[0033] The error registration unit independently monitors the completion status of the asynchronous query unit and automatically registers transactions that have not yet reached their final state into the intraday error table after all configured queries have been executed. This mechanism ensures that every transaction in its final state is recorded without manual intervention, avoiding the risk of transaction loss due to omissions and improving the integrity of system data.

[0034] The proactive query processing unit and the offline verification processing unit correspond to two different levels of manual intervention. The proactive query processing unit reuses the automatic judgment logic of the final state judgment unit, enabling most transactions entering the intraday error stage to quickly obtain their final state through proactive querying. The offline verification processing unit serves as a fallback mechanism, providing mandatory final state settings only for a very small number of transactions that cannot be automatically judged. This hierarchical design eliminates the need for operations personnel to use a uniform, heavily manual verification process for all erroneous transactions, significantly improving the overall efficiency of error handling.

[0035] The accounting processing unit serves as a dedicated interface between the payment system and the external core accounting system. It centrally handles all reconciliation and correction requests, eliminating the need for other units within the payment system to concern themselves with the specific call details of the core accounting system. When the interface of the core accounting system changes, only the accounting processing unit needs to be modified to adapt, enhancing the system's scalability and isolation from external dependencies.

[0036] The seven functional units described above each perform their respective functions, with clear instruction interactions and well-defined data flows, achieving a highly cohesive and loosely coupled system architecture. Compared to implementing all functions in a single module, this structure facilitates parallel development, unit testing, and subsequent functional expansion, meeting the engineering requirements of financial payment systems for stability and maintainability.

[0037] Thirdly, the present invention also provides a computer-readable storage medium having a computer program / instructions stored thereon, which, when executed by a processor, implements the transaction final state processing method of the present invention as described above. Attached Figure Description

[0038] To more clearly illustrate the technical solution of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only one embodiment of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0039] Figure 1 This is a flowchart of the transaction final state processing method in an embodiment of the present invention; Figure 2 This is a schematic diagram of the active query final state processing branch in an embodiment of the present invention; Figure 3 This is a schematic diagram of the offline verification forced final state processing branch in an embodiment of the present invention. Detailed Implementation

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

[0041] The technical solution of the present invention will be described in detail below with reference to specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0042] Example 1 See Figure 1 The transaction final state processing method provided in this embodiment of the invention includes the following steps: Step S1: After the payment system initiates an online transaction to the downstream system, if the transaction times out or the downstream system returns a "processing" status, it reads the first configuration table, initiates multiple asynchronous status queries in sequence based on the query strategy set in the first configuration table, and returns "processing" to the upstream system.

[0043] After the payment system initiates an online transaction to a downstream system (including the core accounting system or payment channel), if any of the following situations occur: Online transaction response timed out; The downstream system explicitly returned the transaction status as "processing"; The payment system will then perform the following operations: S1.1: Read the first configuration table. The first configuration table contains at least the following fields: channel code (downstream system), business type (or business type code), first query interval t0 (seconds), subsequent query interval t (seconds), query time increment multiplier m, and total number of increments n.

[0044] S1.2: Calculate the initiation time of each asynchronous query based on the parameters in the first configuration table (starting from the moment the transaction times out or returns "processing"): First query: Waiting for t0 seconds to initiate.

[0045] Second query: Initiate after waiting for t0+t×m seconds.

[0046] Third query: Initiate after waiting for t0+2×t×m seconds.

[0047] And so on, the initiation time of the i-th (i≥1) query is t0+(i-1)×t×m seconds.

[0048] For example, let t0 = 10 seconds, t = 15 seconds, m = 2, n = 3, where n represents the total number of asynchronous queries: First query: initiated 10 seconds after timeout.

[0049] The second query was initiated 10 + 15 × 2 = 40 seconds after the timeout.

[0050] The third query was initiated 10 + 2 × 15 × 2 = 70 seconds after the timeout.

[0051] S1.3: Based on the time calculated above, asynchronous status queries are initiated sequentially to downstream systems. Simultaneously, the payment system returns a transaction status of "Processing" to the upstream electronic channel (hereinafter referred to as the upstream), informing the upstream that the transaction is being processed.

[0052] The core accounting system mentioned in this article refers to the core business system in financial institutions that is responsible for customer account management, bookkeeping, accounting and fund clearing. It communicates with the payment system through interface calls to complete synchronous or asynchronous accounting processes.

[0053] Step S2: For each asynchronous status query, the payment system makes a judgment based on the query result returned by the downstream system. If the final state of the transaction is returned, the system completes the accounting processing according to the transaction type, notifies the upstream system, and terminates subsequent queries. If a non-final state is returned and contains a business response code, the system proceeds to step S3.

[0054] For each asynchronous status query initiated in step S1, the payment system receives the query result returned by the downstream system and performs the following judgment: If the query result indicates a clear final state of the transaction (success or failure), the corresponding accounting processing is completed according to the transaction type, the upstream electronic channel is asynchronously notified of the transaction final state, and subsequent queries not yet executed in step S1 are terminated. If the query result is not a final state and contains a business response code, then proceed to step S3, where a judgment is made based on the second configuration table in the payment system.

[0055] In this embodiment, the accounting rules are as follows: For credit transactions, where the core accounting system first deducts the payment and then sends it to the payment channel: If the timeout occurs in the core accounting system, the core transaction status (i.e., the transaction status in the core accounting system) is retrieved through a query: if the transaction in the core accounting system is in a successful final state, the channel transaction process is triggered; if the transaction in the core accounting system is in a failed final state, the transaction failure is returned to the upstream. If a timeout occurs in the payment channel, the transaction status of the payment channel is retrieved by querying: if the payment channel transaction is in a successful final state, a successful transaction is returned to the upstream and the transaction ends; if the payment channel transaction is in a failed final state, a synchronous reversal operation is performed and a transaction failure is returned to the upstream.

[0056] For debit transactions, which are transactions where funds are first sent to the payment channel for deduction and then recorded by the core accounting system: If a timeout occurs in the core accounting system, the core transaction status is retrieved by querying: if the transaction in the core accounting system is in a successful final state, a successful transaction is returned upstream, and the transaction ends; if the transaction in the core accounting system is in a failed final state, a synchronous reconciliation operation is performed. If the reconciliation fails, it is recorded in the daytime error table, and the operations staff will then perform a manual reconciliation operation later. If a timeout occurs in the payment channel, the transaction status of the payment channel is retrieved through query: if the payment channel transaction is in a successful final state, a synchronous reconciliation operation is performed and a successful transaction is returned to the upstream; if the payment channel transaction is in a failed final state, a failed transaction is returned to the upstream.

[0057] Step S3: Query the second configuration table. If the second configuration table contains the configuration for the business response code and the time from the transaction initiation to the current query response has exceeded the corresponding time threshold, it is determined to be a failed final state. After completing the accounting processing according to the transaction type, the upstream is notified and subsequent queries are terminated; otherwise, the "processing" state is maintained and the next asynchronous state query continues.

[0058] If the query result is not final and contains a business response code, the payment system queries the second configuration table. The second configuration table must contain at least the following fields: channel code, business type, business response code, and time threshold (seconds).

[0059] If the business response code is configured in the second configuration table, then it is further determined whether the time between the original transaction initiation time (i.e. the time when the payment system initiates an online transaction to the downstream system) and the current query response time has reached or exceeded the time threshold corresponding to the business response code.

[0060] If the time threshold has been reached or exceeded, the payment system will automatically determine the transaction as a failed final state, complete the corresponding accounting processing (see step S2 for accounting processing rules), asynchronously notify the upstream electronic channel of the transaction failure, and terminate subsequent queries.

[0061] If the time threshold is not reached, the transaction status remains "processing" and the next query in step S1 (if any) continues.

[0062] If the business response code is not configured in the second configuration table, the transaction status remains "processing" and the next query in step S1 (if any) continues.

[0063] Step S4: If all queries have been completed and the transaction status is still "processing", then register the transaction in the daytime error table and remind the operations staff.

[0064] If, in step S1, all asynchronous queries have been executed according to the total number of increments set in the first configuration table, and after the judgments in steps S2 and S3, the transaction status of the transaction is still "processing" (i.e., no final status has been obtained), then the payment system will perform the following operations: S4.1: Record this transaction in the intraday error table. The intraday error table must contain at least the following fields: Error ID, Error Intraday Time, Core Transaction Status, Error Type, Error Description, Error Handling Method, Error Handling Time, and Error Handling Status. Error types include Channel Transaction Timeout, Channel Transaction Failure, Core Transaction Timeout, and Core Transaction Failure; error handling methods include Query, Reverse, Reconcile, Resend Channel, Adjustment Successful, Adjustment Failed, and Ignore.

[0065] S4.2: Remind operations staff via SMS or other means to inform them of pending daytime error transactions.

[0066] Step S5: When the operations staff initiates an active query on the transactions in the daily error table, the payment system queries the downstream system again and executes the final state judgment logic. If the final state of the transaction is obtained, the system provides options for supplementary accounting, reversal, or resending based on the transaction scenario. After being triggered by the operations staff, the system calls the core accounting system to complete the accounting process synchronously and notifies the upstream.

[0067] The payment system provides operations staff with an error handling interface, displaying transactions from the daily error report. When an operations staff member clicks the query option for a specific transaction, the payment system performs the following operations: S5.1: Based on the error type (if it is a channel transaction timeout, query the payment channel; if it is a core transaction timeout, query the core accounting system), initiate a status query to the downstream system again.

[0068] S5.2: Process the query results according to the rules for determining the final state of the transaction in steps S2 and S3 (including final state determination, business response code + time threshold determination). The active query here is a single query and does not involve terminating or continuing subsequent queries.

[0069] S5.3: Process according to the judgment result, such as Figure 2 As shown: Scenario 1: The final state of the transaction is obtained.

[0070] For debit transactions: If the transaction status is "failed," the transaction status is updated to "failed," and processing ends. If the transaction status is "successful," a reconciliation option is provided. After the operations staff clicks this option, the payment system calls the core accounting system to synchronously complete the accounting, and the transaction status is updated to "successful."

[0071] For credit-based transactions: If the transaction fails, a reversal option is provided. After the operations staff clicks this option, the payment system calls the core accounting system to synchronously complete the reverse accounting, and the transaction status is updated to "failed." If the transaction succeeds, the transaction status is directly updated to "successful."

[0072] For core transaction timeout scenarios (error type: core transaction timeout): For debit transactions: If the core transaction fails, provide an option to make up the difference; if the core transaction succeeds, update the transaction status to succeed directly.

[0073] For credit transactions: If the core transaction fails, the transaction status is directly updated to failure. If the core transaction succeeds, two options are provided for operations personnel: reversal or resend. If reversal is selected, the core accounting system is invoked to complete the reverse posting, and the transaction status is updated to failure. If resend is selected, the payment system resends the transaction to the payment channel, and the transaction status is updated to success after receiving a successful response from the channel.

[0074] After completing the above accounting procedures, the payment system asynchronously notifies the upstream electronic channel of the transaction's final status.

[0075] Scenario 2: The final state of the transaction cannot be obtained.

[0076] If the judgment result of step S5.2 still cannot obtain the final state of the transaction (i.e., the downstream system returns a non-final state and cannot be automatically determined by the second configuration table, or the query times out, etc.), then proceed to step S6.

[0077] Step S6: If the final state of the transaction still cannot be obtained after active inquiry, provide options for successful adjustment and failed adjustment; after offline verification by the operations personnel, the final state of the transaction is forcibly set. The payment system automatically determines whether it is necessary to make up the account, reverse the transaction, or resend the channel based on the transaction type and timeout scenario, and provides corresponding operation options. After being triggered by the operations personnel, the core accounting system is called to complete the accounting process synchronously, and finally the upstream is notified.

[0078] If the final state of the transaction cannot be obtained after actively querying in step S5, the payment system displays an option for successful adjustment and an option for failed adjustment. After verifying the true final state of the transaction through offline methods (such as contacting downstream system maintenance by phone, querying the backend database, etc.), the operations personnel perform the following operations: S6.1: When an operator clicks the "Successful Adjustment" or "Failed Adjustment" option, the final state of the transaction is forcibly set.

[0079] S6.2: Based on the mandatory final state result and according to the timeout scenario (channel transaction timeout or core transaction timeout) and transaction type (debit remittance or credit remittance), the payment system automatically determines whether it is necessary to make up the account, reverse the transaction, or resend the channel, and presents the corresponding options (e.g., Figure 3 (As shown).

[0080] For debit remittance transactions, the timeout scenario is the channel transaction timeout (i.e., the final state of the payment channel transaction cannot be obtained after querying in step S4): If the transaction is successful: When the operations staff clicks the "Adjust Successful" option, the payment system forcibly sets the transaction's final state to "successful" and automatically determines if a reconciliation is needed, highlighting the reconciliation option. After the operations staff clicks the reconciliation option, the payment system calls the core accounting system to synchronously complete the accounting, and finally asynchronously notifies the upstream electronic channel of the transaction's success.

[0081] If the actual transaction fails: the operations staff clicks the "Adjust Failure" option, and the payment system forcibly sets the final state of the transaction to failure. No reconciliation or correction is required, and the process ends (no need to notify the upstream, or notify the upstream that the transaction failed).

[0082] For debit transactions, the timeout scenario is the core transaction timeout (i.e., the final state of the transaction in the core accounting system cannot be obtained after querying in step S4): If the actual transaction is successful: the operations staff clicks the "Adjust Success" option, the payment system forces the transaction to be set to successful at the end, no need to make up the accounts or reverse the transaction, and the process ends (directly notifying the upstream of the successful transaction).

[0083] If the actual transaction fails: When the operations staff clicks the "Adjust Failed" option, the payment system forcibly marks the core accounting transaction as failed, then automatically determines if a reconciliation is needed, and the reconciliation option is highlighted. After the operations staff clicks the reconciliation option, the payment system calls the core accounting system to synchronously complete the reconciliation, and finally asynchronously notifies the upstream electronic channel of the transaction failure.

[0084] For credit remittance transactions, the timeout scenario is the core transaction timeout (i.e., the final state of the transaction in the core accounting system cannot be obtained after querying in step S4): If the actual transaction is successful: When the operations staff clicks the "Adjust Successful" option, the payment system will force the transaction's final state to be successful and automatically provide options for reversal or resend based on the error type, which the operations staff can then choose to trigger. If the transaction is reversed, the payment system calls the core accounting system to complete the reverse accounting, and the transaction status is updated to failure.

[0085] If the resend channel is selected, the payment system will resend the transaction to the payment channel and update the transaction status to success after receiving a successful response from the channel.

[0086] Finally, the upstream electronic channel will be notified of the transaction's final status asynchronously.

[0087] If the actual transaction fails: the operations staff clicks the "Adjust Failure" option, the payment system forces the transaction to end in failure, and the process ends when the transaction ends in failure.

[0088] For credit remittance transactions, the timeout scenario is the payment channel transaction timeout (i.e., the final state of the payment channel transaction cannot be obtained after querying in step S4): If the actual transaction is successful: the operations staff clicks the "Adjust Success" option, the payment system forces the transaction to be set to successful at the end, no need to make up the accounts or reverse the transaction, and the process ends (directly notifying the upstream of the successful transaction).

[0089] If the actual transaction fails: The operations staff clicks the "Adjust Failure" option, the payment system forcibly sets the payment channel transaction status to "Failed," and then automatically determines whether to provide a reversal or resend channel operation option, which is then selected and triggered by the operations staff. If the option to reverse is selected, the payment system calls the core accounting system to complete the reverse accounting, and the transaction status is updated to failure. If the resend channel is selected, the payment system will resend the transaction to the payment channel and update the transaction status to success after receiving a successful response from the channel.

[0090] Finally, the upstream electronic channel will be notified of the transaction's final status asynchronously.

[0091] Thus, regardless of any abnormal circumstances, every financial transaction can obtain a clear final state and complete the corresponding accounting processing.

[0092] Example 2 The transaction final state processing system provided in this embodiment of the invention includes a payment system, which further includes a storage unit, an asynchronous query unit, a final state judgment unit, an accounting processing unit, an error registration unit, an active query processing unit, and an offline verification processing unit. Each unit is deployed within the payment system and interacts through internal interfaces or message passing.

[0093] The storage unit is used to persistently store the first configuration table, the second configuration table, and the daytime error table.

[0094] The first configuration table configures the asynchronous query strategy and includes at least the following fields: channel code (downstream system), business type (or business type code), initial query interval t0 (seconds), interval time t (seconds), query time increment multiplier m, and total increment number n. For example, for a payment channel's repayment business, t0=10 seconds, t=15 seconds, m=2, and n=3 can be configured.

[0095] The second configuration table contains the service response code and its corresponding time threshold, and includes at least the following fields: channel code, service type, service response code, and time threshold (seconds). For example, the service response code "P0001" is configured to correspond to a time threshold of 1800 seconds.

[0096] The daytime error table is used to record all transaction records that have not reached their final state. It includes at least the following fields: Error ID, Error Daytime, Core Transaction Status, Error Type, Error Description, Error Handling Method, Error Handling Time, and Error Handling Status. Error types include Channel Transaction Timeout, Channel Transaction Failure, Core Transaction Timeout, and Core Transaction Failure. Error handling methods include query, reversal, reconciliation, resend channel, adjustment successful, adjustment failed, and ignore.

[0097] The asynchronous query unit is responsible for initiating the asynchronous status query process when an online transaction encounters an anomaly. Its specific workflow is as follows: When the payment system initiates an online transaction to a downstream system (including the core accounting system or payment channel), if a transaction response timeout occurs or the downstream system returns a "processing" status, the asynchronous query unit immediately reads the first configuration table in the storage unit.

[0098] Based on the parameters in the first configuration table, the initiation time of each query is calculated from the moment the transaction times out or returns "processing": the first query waits for t0 seconds, the second query waits for t0+t×m seconds, the third query waits for t0+2×t×m seconds, and so on, with the initiation time of the i-th (i≥1) query being t0+(i-1)×t×m seconds.

[0099] Asynchronous status queries are initiated to downstream systems in sequence according to the above time, while "processing" is returned to upstream electronic channels at the same time.

[0100] The asynchronous query unit receives instructions from the final state determination unit: if it receives an instruction to terminate subsequent queries, it stops any subsequent queries that have not yet been initiated; if it receives an instruction to continue the next query, it initiates the next query as planned.

[0101] The final state determination unit is responsible for analyzing the return results of each asynchronous state query and issuing corresponding control commands.

[0102] For each query initiated by the asynchronous query unit, the final state determination unit receives the result returned by the downstream system and performs the following determination: If the transaction final status (success or failure) is returned: the final status judgment unit immediately notifies the accounting unit to process the accounting, notifies the upstream electronic channel of the transaction final status, and issues a termination instruction to the asynchronous query unit.

[0103] If a non-final state is returned and contains a business response code: The final state determination unit queries the second configuration table in the storage unit. If the configuration for the business response code exists in the second configuration table, the duration from the original transaction initiation time to the current query response time is further calculated. If this duration has reached or exceeded the configured time threshold, it is determined to be a failed final state, the accounting unit is notified to perform accounting processing, the upstream electronic channel is notified of the transaction failure, and an instruction to terminate subsequent queries is issued to the asynchronous query unit.

[0104] If the time threshold is not reached, or if the business response code is not configured in the second configuration table, the transaction status will remain "processing", and a command to continue the next query will be sent to the asynchronous query unit.

[0105] Based on the instructions from the final state judgment unit, the accounting processing unit calls upon the external core accounting system to synchronously complete the supplementary accounting operation or the reversal operation: If the instruction requires a reversal operation (for scenarios where credit transactions fail), the accounting unit calls the reversal interface of the core accounting system to simultaneously complete the reverse posting.

[0106] If the instruction requires a supplementary accounting operation (for scenarios where a debit transaction was successfully completed but not yet posted), the accounting processing unit calls the posting interface of the core accounting system to synchronously complete the positive posting.

[0107] All calls are synchronous, ensuring that the accounting operation results are returned immediately.

[0108] The error registration unit monitors the working status of the asynchronous query unit. When the asynchronous query unit has completed all queries set in the first configuration table (i.e., all queries have been executed without receiving a termination instruction during the total number of queries), and after the final status judgment unit has determined that the transaction status is still "processing", the error registration unit performs the following operations: The relevant information of the transaction (error ID, error daytime, core transaction status, error type, error description, etc.) is recorded in the daytime error table in the storage unit.

[0109] Reminders to operations staff can be triggered via SMS, system messages, or other means.

[0110] The proactive query processing unit responds to proactive query requests from operations personnel and processes transactions in the daily error report. The specific process is as follows: The payment system provides an error handling interface to operations staff, displaying a list of transactions from the daily error report. When an operations staff member clicks the query option for a specific transaction, the proactive query processing unit is triggered.

[0111] The proactive query processing unit initiates a status query to the downstream system again based on the error type of the transaction (if it is a channel transaction timeout, it queries the payment channel; if it is a core transaction timeout, it queries the core accounting system).

[0112] The proactive query processing unit invokes the final state determination rules (reusing its final state determination, business response code + time threshold determination capabilities) in the final state determination unit to process the query results. This invocation is a single call and does not involve instructions to terminate subsequent queries.

[0113] Process according to the judgment results: (1) Processing after obtaining the final state of the transaction The payment system determines whether an accounting operation is required based on the transaction scenario (debit / credit, error type) and the specific final state obtained from the query: Scenarios where no accounting operations are required (directly updating transaction status): Debit to outgoing account, channel transaction timeout, obtain channel transaction failure final state → directly update transaction status to failure.

[0114] Debit back to account, core transaction timeout, obtain core transaction success final state → directly update transaction status to success.

[0115] Credit transfer, channel transaction timeout, obtaining the final status of successful channel transaction → directly update the transaction status to successful.

[0116] Credit remittance, core transaction timeout, obtain core transaction failure final state → directly update transaction status to failure.

[0117] Scenarios requiring accounting operations (options provided, triggered by operations personnel): Debit entries, channel transaction timeouts, and successful channel transaction final status → provide the option to perform a reconciliation operation. After the operations staff clicks, the accounting unit is invoked to synchronously complete the accounting, and the transaction status is updated to successful.

[0118] Debit entries, core transaction timeouts, obtaining the final state of a failed core transaction → provide options for reconciliation. After the operations staff clicks, the accounting unit is invoked to synchronously complete the accounting, and the transaction status is updated to success.

[0119] Credit remittance, channel transaction timeout, obtaining the final status of a failed channel transaction → provides the option to reverse the transaction. After the operations staff clicks this option, the accounting unit is invoked to synchronously complete the reverse posting, and the transaction status is updated to failed.

[0120] Credit remittance, core transaction timeout, obtaining the final successful state of a core transaction → provides two options: reversal and resend channel. If the operations staff chooses reversal, the accounting unit is invoked to complete the reverse posting, and the transaction status is updated to failure; if the resend channel is selected, the payment system resends the transaction to the payment channel, and updates the transaction status to success after receiving a successful response from the channel.

[0121] After completing the above operations, the payment system asynchronously notifies the upstream electronic channel of the transaction's final status.

[0122] (2) Handling when the final state of a transaction cannot be obtained If the final state determination unit still cannot obtain the final state of the transaction after active query (i.e., the downstream system returns a non-final state and cannot be automatically determined by the second configuration table, or the query times out, etc.), the active query processing unit will transfer control to the offline verification processing unit.

[0123] The offline verification and processing unit handles extreme cases where the final state of a transaction cannot be obtained even after an active query. Its workflow is as follows: The offline verification and processing unit displays two options to the operations staff: adjustment successful and adjustment failed.

[0124] After verifying the true final state of the transaction through offline methods (such as contacting downstream system maintenance by phone, querying the backend database, etc.), the operations personnel click the corresponding option to force set the transaction final state.

[0125] The offline verification and processing unit automatically determines whether to make up the difference, reverse the transaction, or resend the transaction based on the mandatory final state result, the timeout scenario (channel transaction timeout or core transaction timeout), and the transaction type (debit remittance or credit remittance), and presents the corresponding options: For debit remittance transactions, the timeout scenario is the channel transaction timeout (i.e., the final state of the payment channel transaction cannot be obtained after querying in step S4): If the transaction is successful: When the operations staff clicks the "Adjust Successful" option, the payment system forcibly sets the transaction's final state to "successful" and automatically determines if a supplementary payment is needed, highlighting the supplementary payment option. After the operations staff clicks, the accounting unit synchronously completes the accounting, and finally, the upstream electronic channel is asynchronously notified of the transaction's success.

[0126] If the actual transaction fails: the operations staff clicks the "Adjust Failure" option, and the payment system forces the transaction to be set to failure. No reconciliation or correction is required, and the process ends (the upstream electronic channel can be notified of the transaction failure).

[0127] For debit transactions, the timeout scenario is the core transaction timeout (i.e., the final state of the transaction in the core accounting system cannot be obtained after querying in step S4): If the actual transaction is successful: the operations staff clicks the "Adjust Success" option, the payment system forces the transaction to be set to successful at the end, no need to make up the accounts or reverse the transaction, and the process ends (directly notifying the upstream of the successful transaction).

[0128] If the actual transaction fails: When the operations staff clicks the "Adjust Failed" option, the payment system forcibly marks the core accounting transaction as failed, then automatically determines if a reconciliation is needed, and the reconciliation option is highlighted. After the operations staff clicks the reconciliation option, the payment system calls the core accounting system to synchronously complete the reconciliation, and finally asynchronously notifies the upstream electronic channel of the transaction failure.

[0129] For credit remittance transactions, the timeout scenario is the core transaction timeout (i.e., the final state of the transaction in the core accounting system cannot be obtained after querying in step S4): If the actual transaction is successful: When the operations staff clicks the "Adjust Success" option, the payment system forcibly sets the transaction's final state to success and automatically provides options for either reversal or resending based on the error type. The operations staff then chooses to trigger the following: If reversal is selected, the accounting unit is invoked to complete the reverse accounting, and the transaction status is updated to failure; if resending is selected, the transaction is resent to the payment channel, and the transaction status is updated to success upon receiving a success response. Finally, the upstream electronic channel is asynchronously notified of the transaction's final state.

[0130] If the actual transaction fails: the operations staff clicks the "Adjust Failure" option, the payment system forcibly sets the final state of the transaction to failure, and the processing ends when the final state of the transaction is failure; For credit remittance transactions, the timeout scenario is the payment channel transaction timeout (i.e., the final state of the payment channel transaction cannot be obtained after querying in step S4): If the actual transaction is successful: the operations staff clicks the "Adjust Success" option, the payment system forces the transaction to be set to successful at the end, no need to make up the accounts or reverse the transaction, and the process ends (directly notifying the upstream of the successful transaction).

[0131] If the actual transaction fails: The operations staff clicks the "Adjust Failure" option, the payment system forcibly sets the payment channel transaction status to "Failed," and then automatically determines whether to provide a reversal or resend channel operation option, which is then selected and triggered by the operations staff. If the option to reverse is selected, the payment system calls the core accounting system to complete the reverse accounting entry. If the resend channel is selected, the payment system will resend the transaction to the payment channel.

[0132] Finally, the upstream electronic channel will be notified of the transaction's final status asynchronously.

[0133] The following example illustrates the collaboration process of the above units: Initialization: The storage unit has been configured with the first configuration table (t0=10 seconds, t=15 seconds, m=2, n=3) and the second configuration table (service response code P0001, time threshold 1800 seconds).

[0134] Online transaction timeout: After the payment system initiates a credit transaction, the timeout occurs. The asynchronous query unit reads the first configuration table and initiates three asynchronous status queries at 10 seconds, 40 seconds, and 70 seconds as planned.

[0135] First query: The downstream system returns a business response code P0001. The final state judgment unit queries the second configuration table and finds that the configuration exists, but the current duration (10 seconds) has not exceeded 1800 seconds, so it issues a command to continue the next query.

[0136] The second query still returned P0001, and the timeout period of 40 seconds has not expired, so a third query is performed.

[0137] Third query: Returns P0001, 70 seconds have passed and the timeout has not yet occurred. All queries have been completed, and the final status remains "Processing". The error registration unit records this transaction in the daytime error table and sends an SMS notification to the operations staff.

[0138] Operations personnel proactively query: When operations personnel click to query on the error handling interface, the proactive query processing unit queries downstream again. If the final state judgment unit determines that it is still not a final state and cannot be automatically judged, it will be transferred to the offline verification processing unit.

[0139] Offline verification: Operations personnel contact the downstream system by phone to confirm that the transaction was actually successful. Clicking the "Adjust Success" option, the offline verification processing unit provides a resend channel option based on credit or core timeout scenarios. After clicking, the operations personnel call the accounting processing unit to resend the transaction. Upon receiving a success response, the status is updated to "success," and the upstream electronic channel is notified.

[0140] At this point, the system has completed the final state processing of a timed-out transaction.

[0141] Through the above-described modular design, the present invention achieves the following technical effects: The storage unit separates configuration data from business logic, reducing maintenance costs; the asynchronous query unit and the final state judgment unit achieve precise process control through instruction interaction, avoiding logical coupling; the error registration unit automatically monitors the query completion status and registers transactions that are not yet in a final state, ensuring data integrity; the hierarchical design of the proactive query processing unit and the offline verification processing unit enables most error transactions to be quickly resolved through proactive queries, with only a very small number requiring offline verification, significantly improving processing efficiency; the accounting processing unit, as a unified interface, isolates changes from the external core accounting system, enhancing the system's scalability.

[0142] Example 3 This invention also provides an electronic device, which includes a memory, a processor, and a computer program / instructions stored in the memory. The processor executes the computer program / instructions to implement the transaction finality processing method in Embodiment 1 of this invention.

[0143] Although not shown, the electronic device includes a processor that can perform various appropriate operations and processes based on programs and / or data stored in read-only memory (ROM) or loaded from a storage portion into random access memory (RAM). The processor can be a multi-core processor or may contain multiple processors. In some embodiments, the processor may include a general-purpose main processor and one or more specialized coprocessors, such as a central processing unit, graphics processing unit (GPU), neural network processor (NPU), digital signal processor (DSP), etc. Various programs and data required for device operation are also stored in RAM. The processor, ROM, and RAM are interconnected via a bus. Input / output (I / O) interfaces are also connected to the bus.

[0144] The processor and memory described above are used together to execute programs / instructions stored in the memory. When the program / instructions are executed by the computer, they can implement the methods, steps, or functions described in the above embodiments.

[0145] Although not shown, embodiments of the present invention also provide a computer-readable storage medium having a computer program / instructions stored thereon, which, when executed by a processor, implements the transaction finality processing method in Embodiment 1 of the present invention.

[0146] Readable storage media include both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0147] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention. Clearly, those skilled in the art can make various alterations and modifications to the invention without departing from its spirit and scope. Thus, if these modifications and modifications of the invention fall within the scope of the claims and their equivalents, the invention is also intended to include these modifications and modifications.

Claims

1. A method for processing the final state of a transaction, characterized in that, The method includes: Step S1: After the payment system initiates an online transaction to the downstream system, if the transaction times out or the downstream system returns a "processing" status, it reads the first configuration table, initiates multiple asynchronous status queries in sequence based on the query strategy set in the first configuration table, and returns "processing" to the upstream. Step S2: For each asynchronous status query, the payment system makes a judgment based on the query results returned by the downstream system: If the transaction is returned to its final state, the upstream supplier will be notified after the accounting is completed according to the transaction type, and subsequent queries will be terminated. If a non-final state is returned and a business response code is included, then the second configuration table is queried. The second configuration table is configured with the business response code and its corresponding time threshold. If the business response code is configured in the second configuration table and the time from the transaction initiation to the current query response has exceeded the corresponding time threshold, it is determined to be a failed final state. After completing the accounting processing according to the transaction type, the upstream is notified and subsequent queries are terminated; otherwise, the "processing" state is maintained and the next asynchronous state query continues. Step S3: If all queries have been completed and the transaction status is still "processing", then register the transaction in the daytime error table and remind the operations staff; Step S4: When the operations staff initiates an active query on the transactions in the daytime error table, the payment system queries the downstream system again and determines whether the transaction has reached its final state according to the rules for determining the final state of the transaction in Step S2. If the final state of the transaction is obtained, the system provides options for supplementary accounting, reversal, or resending based on the transaction scenario. After being triggered by the operations staff, the system calls the core accounting system to complete the accounting processing synchronously and notifies the upstream. Step S5: If the final state of the transaction still cannot be obtained in step S4, then provide options for successful adjustment and failed adjustment; after offline verification by the operations personnel, the final state of the transaction is forcibly set. The payment system automatically determines whether it is necessary to make up the account, reverse the transaction, or resend the channel based on the transaction type and timeout scenario, and provides corresponding operation options. After being triggered by the operations personnel, the core accounting system is called to complete the accounting process synchronously, and finally the upstream is notified.

2. The transaction final state processing method according to claim 1, characterized in that, The first configuration table includes channel code, service type, first query interval, subsequent query interval, query time increment multiplier, and total number of increments; the second configuration table includes channel code, service type, service response code, and time threshold.

3. The transaction final state processing method according to claim 1, characterized in that, The intraday error table includes error ID, error intraday time, core transaction status, error type, error description, error handling method, error handling time, and error handling status; the error type includes channel transaction timeout, channel transaction failure, core transaction timeout, and core transaction failure; the error handling method includes query, reversal, account refill, resend channel, adjustment successful, adjustment failed, and ignore.

4. The transaction final state processing method according to claim 1, characterized in that, In step S2, completing the accounting process includes: For credit transactions, where the core accounting system first deducts the payment and then sends it to the payment channel: If a timeout occurs in the core accounting system, the core transaction status is retrieved through a query: if it is a successful final state, the channel transaction process is triggered; if it is a failed final state, the transaction failure is returned to the upstream. If a timeout occurs in the payment channel, the transaction status of the payment channel is retrieved by querying: if it is a successful final state, a successful transaction is returned to the upstream; if it is a failed final state, a synchronous reversal operation is performed, and a failed transaction is returned to the upstream. For debit transactions, which are transactions where funds are first sent to the payment channel for deduction and then recorded by the core accounting system: If a timeout occurs in the core accounting system, the core transaction status is retrieved through querying: if it is a successful final state, a successful transaction is returned to the upstream; if it is a failed final state, a synchronous reconciliation operation is performed, and if the reconciliation fails, it is recorded in the intraday error table. If a timeout occurs in the payment channel, the transaction status of the payment channel is retrieved through query: if it is a successful final state, a synchronous reconciliation operation is performed and a successful transaction is returned to the upstream; if it is a failed final state, a failed transaction is returned to the upstream.

5. The transaction final state processing method according to claim 1, characterized in that, The supplementary accounting operation involves calling the core accounting system to synchronously complete the accounting entry, while the reversal operation involves calling the core accounting system to synchronously complete the reverse accounting entry.

6. The transaction final state processing method according to any one of claims 1 to 5, characterized in that, In step S4: When the transaction is a debit remittance transaction and the error type is channel transaction timeout, the payment system, after querying and determining in step S2, will: If the final state of a failed channel transaction is obtained, the transaction status is updated to failed; if the final state of a successful channel transaction is obtained, the option to perform a reconciliation operation is provided, which is triggered by the operations personnel and calls the core accounting system to complete the accounting. When the transaction is a credit remittance transaction and the error type is channel transaction timeout, the payment system, after querying and determining in step S2, will: If the channel transaction fails, a reversal option is provided, which is triggered by the operations staff and calls the core accounting system to complete the reverse accounting. If the final state of the channel transaction is obtained, the transaction status is updated to successful.

7. The transaction final state processing method according to any one of claims 1 to 5, characterized in that, In step S4: When the transaction is a debit remittance transaction and the error type is core transaction timeout, the payment system, after querying and determining in step S2, will: If the core transaction fails, an option to perform a reconciliation operation is provided, which is triggered by the operations staff and calls the core accounting system to complete the accounting; if the core transaction succeeds, the transaction status is updated to successful. When the transaction is a credit remittance transaction and the error type is core transaction timeout, the payment system, after querying and determining in step S2, will: If the core transaction fails, the transaction status is updated to failure. If the core transaction succeeds, either a reversal operation or a resend channel operation is provided, which is selected and triggered by the operations personnel. The reversal operation option calls the core accounting system to complete the reverse accounting, while the resend channel operation option updates the transaction status to success after receiving a successful channel response.

8. The transaction final state processing method according to any one of claims 1 to 5, characterized in that, In step S5: When the transaction is a debit transfer transaction, and the timeout scenario is a channel transaction timeout and the final state of the payment channel transaction cannot be obtained after querying in step S4, the following is verified offline by the operations personnel: If the actual transaction is successful, the final state of the transaction is forced by adjusting the success option, and then the option to make up the account is provided. After being triggered by the operations staff, the core accounting system is called to complete the accounting. If the actual transaction fails, the final state of the transaction will be forced to be set by adjusting the failure options, and the process will end. When the transaction is a debit remittance transaction, and the timeout scenario is a core transaction timeout, and the final state of the core accounting system transaction cannot be obtained after querying in step S4, the following verification was conducted offline by operations personnel: If the actual transaction is successful, the final state of the transaction will be forced by adjusting the success option, and the process will end. If the actual transaction fails, the core accounting transaction will be forced to fail by adjusting the failure option, and then a remediation operation option will be provided. After being triggered by the operations personnel, the core accounting system will be called to complete the remediation. When the transaction is a credit remittance transaction, and the timeout scenario is a core transaction timeout, and the final state of the core accounting system transaction cannot be obtained after querying in step S4, the following verification was conducted offline by operations personnel: If the actual transaction is successful, the final state of the transaction is forcibly set by adjusting the success option, and then the reversal operation option or the resend channel operation option is provided according to the error type, which is selected and triggered by the operations personnel. If the actual transaction fails, the final state of the transaction will be forcibly set to failure by adjusting the failure option, and the processing will end. When the transaction is a credit transfer transaction, and the timeout scenario is a channel transaction timeout and the final state of the payment channel transaction cannot be obtained after querying in step S4, the following verification was conducted offline by the operations personnel: If the actual transaction is successful, the final state of the transaction will be forced by adjusting the success option, and the process will end. If the actual transaction fails, the payment channel transaction status will be forcibly set to failed by adjusting the failure options, and then the reversal operation option or the resend channel operation option will be provided for the operators to choose to trigger.

9. A transaction final state processing system, including a payment system, characterized in that, The payment system includes: The storage unit is used to store a first configuration table, a second configuration table, and a daytime error table; wherein, the first configuration table is configured with an asynchronous query strategy, the second configuration table is configured with a business response code and its corresponding time threshold, and the daytime error table is used to register transaction records that have not obtained the final state of the transaction; The asynchronous query unit is used to read the first configuration table after executing an online transaction to the downstream system. If the transaction times out or the downstream system returns a "processing" status, the unit will initiate multiple asynchronous status queries to the downstream system in sequence based on the query strategy set in the first configuration table and return "processing" to the upstream system. The unit will also continue or terminate subsequent queries according to the instructions of the final status judgment unit. The final state determination unit receives the return result of each asynchronous state query, makes a judgment, and outputs the final state result and the source of the final state. If the transaction final state is returned, the accounting unit is notified to perform accounting processing according to the transaction type and the source of the final state, the upstream transaction final state is notified, and an instruction to terminate subsequent queries is sent to the asynchronous query unit. If a non-final state is returned and a business response code is included, the second configuration table is queried. If the business response code is configured in the second configuration table and the time elapsed from the transaction initiation to the current query response exceeds the corresponding time threshold, it is determined to be a failed final state. The accounting unit is notified to perform accounting processing according to the transaction type and failure source, the upstream transaction is notified of the failure, and an instruction to terminate subsequent queries is sent to the asynchronous query unit. Otherwise, an instruction to continue the next query is sent to the asynchronous query unit. The accounting processing unit is used to call the core accounting system to synchronously complete the supplementary accounting operation or the reversal operation according to the instructions of the final state judgment unit; The error registration unit is used to register the transaction in the daytime error table and trigger an operational staff reminder if the transaction status is still "processing" after the asynchronous query unit has completed all configured queries. The proactive query processing unit is used to respond to proactive queries from operations personnel regarding transactions in the daily error table, query the downstream system again, and call the rules for final state determination in the final state determination unit to determine whether the transaction has reached the final state. If the final state of the transaction is obtained, the unit provides options for supplementary accounting, reversal, or resending based on the transaction scenario. After being triggered by operations personnel, the unit calls the accounting processing unit to complete the accounting processing and notifies the upstream. The offline verification and processing unit is used to provide options for successful adjustment and failed adjustment if the final state of the transaction cannot be obtained after active inquiry. In response to the transaction final state set by the operations personnel after offline verification, the payment system automatically determines whether it is necessary to make up the account, reverse the transaction or resend the channel based on the transaction type and timeout scenario, and provides corresponding operation options. After being triggered by the operations personnel, the accounting processing unit is called to complete the accounting processing, and finally the upstream is notified.

10. A computer-readable storage medium having a computer program / instructions stored thereon, characterized in that, When the computer program / instruction is executed by the processor, it implements the transaction finality processing method as described in any one of claims 1 to 8.

Images