Exception handling method and device based on quick payment, equipment and storage medium

Abstract

The invention discloses an exception handling method and device based on quick payment, equipment and a storage medium. The method comprises the steps that a transaction request is received, the transaction request is used for requesting a target payment transaction, and the transaction request comprises at least one of a payment instruction, transaction user identity information and payment channel information; performing feature extraction on the transaction request to obtain transaction request features; the transaction request features are input to a pre-trained compensation decision generation model, a target compensation decision output by the compensation decision generation model is obtained, and the compensation decision generation model is used for outputting a target transaction compensation decision for the target payment transaction when it is judged that the target payment transaction is abnormal, transaction anomalies are eliminated by executing the target compensation decision. The method supports the dynamic generation of the compensation decision, can respond to the transaction abnormity in real time to generate the targeted compensation decision without manual intervention, improves the payment abnormity processing efficiency, and saves the labor cost and the time cost.

Description

Technical Field

[0001] This application relates to the field of big data technology, and in particular to an anomaly handling method, apparatus, device, and storage medium based on quick payment. Background Technology

[0002] With the rapid development of e-commerce and mobile payments, quick payment has become increasingly important. To ensure the success rate and user experience during the quick payment process, the payment system needs to have efficient and intelligent anomaly handling capabilities.

[0003] Currently, common quick payment systems in the industry primarily employ the following compensation strategies in the anomaly handling phase: First, they pre-set the number of retries (e.g., 3 times) and backup payment channels for each transaction. When an anomaly occurs, the quick payment system mechanically repeats the payment according to the set number of retries, automatically switching to the backup payment channel after a final failed retry. This process lacks real-time awareness and response, and cannot dynamically adjust compensation strategies, resulting in low efficiency in anomaly handling. Second, after detecting a transaction failure, the transaction is suspended and a work order is generated. Operations personnel manually analyze the cause of the failed transaction and manually select whether to retry or change the payment channel. This method heavily relies on manual operation, is time-consuming, and significantly increases labor and time costs, leading to low anomaly handling efficiency. Therefore, improving the efficiency of anomaly handling in quick payments has become an urgent technical problem to be solved. Summary of the Invention

[0004] This application provides a method, apparatus, device, and storage medium for handling anomalies based on quick payment. It can support the dynamic generation of compensation decisions and generate targeted compensation decisions in real time for transaction anomalies without human intervention, thereby improving the efficiency of payment anomaly handling and saving labor and time costs.

[0005] In a first aspect, embodiments of this application provide an exception handling method based on quick payment, the method comprising:

[0006] Receive a transaction request, the transaction request being used to request a target payment transaction, the transaction request including at least one of the following: payment instruction, transaction user identity information, payment channel information;

[0007] The transaction request is subjected to feature extraction to obtain transaction request features;

[0008] The transaction request features are input into a pre-trained compensation decision generation model to obtain a target compensation decision output by the compensation decision generation model. The compensation decision generation model is used to output a target transaction compensation decision for the target payment transaction when it is determined that a transaction anomaly has occurred in the target payment transaction, so as to eliminate the transaction anomaly by executing the target compensation decision.

[0009] Secondly, embodiments of this application also provide an anomaly handling device based on quick payment, the device comprising:

[0010] A receiving module is used to receive a transaction request, the transaction request being used to request a target payment transaction, the transaction request including at least one of the following: payment instruction, transaction user identity information, and payment channel information;

[0011] The feature extraction module is used to extract features from the transaction request to obtain transaction request features;

[0012] The processing module is used to input the transaction request features into a pre-trained compensation decision generation model to obtain the target compensation decision output by the compensation decision generation model. The compensation decision generation model is used to output a target transaction compensation decision for the target payment transaction when it is determined that a transaction anomaly has occurred in the target payment transaction, so as to eliminate the transaction anomaly by executing the target compensation decision.

[0013] Thirdly, embodiments of this application provide an electronic device, including:

[0014] One or more processors;

[0015] Memory, used to store one or more programs.

[0016] When the one or more programs are executed by the one or more processors, the one or more processors implement the exception handling method based on quick payment as described in any embodiment of this application.

[0017] Fourthly, embodiments of this application provide a storage medium storing a computer program thereon, which, when executed by a processor, implements the exception handling method based on quick payment described in any embodiment of this application.

[0018] This application proposes an anomaly handling method, apparatus, device, and storage medium based on quick payment. Specifically, in the technical solution of this application, a pre-trained compensation decision generation model can provide a corresponding compensation decision for the target payment transaction when an anomaly is detected. This is essentially a dynamic compensation decision generation method. In contrast, existing technologies mechanically perform payments repeatedly according to a set number of retries and automatically switch to a backup payment channel after a failed retry. This lacks awareness and response to real-time transaction conditions, and cannot dynamically adjust compensation strategies, resulting in low efficiency in payment anomaly handling. Furthermore, existing technologies rely heavily on manual processing, which is time-consuming and significantly increases labor and time costs. Therefore, compared to existing technologies, the anomaly handling method based on quick payment proposed in this application supports dynamic generation of compensation decisions. It can generate targeted compensation decisions in real time for transaction anomalies without human intervention, thereby improving payment anomaly handling efficiency and saving labor and time costs. Moreover, the technical solution of this application is simple and convenient to implement, easy to popularize, and has a wider range of applications. Attached Figure Description

[0019] Figure 1 A flowchart illustrating an exception handling method based on quick payment provided in an embodiment of this application;

[0020] Figure 2 A flowchart illustrating an exception handling method based on quick payment provided in another embodiment of this application;

[0021] Figure 3 A flowchart illustrating an exception handling method based on quick payment provided in another embodiment of this application;

[0022] Figure 4 A flowchart illustrating an exception handling method based on quick payment provided in another embodiment of this application;

[0023] Figure 5 A schematic diagram of the structure of an exception handling device based on quick payment provided in an embodiment of this application;

[0024] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0025] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the application and not intended to limit it. Furthermore, it should be noted that, for ease of description, the accompanying drawings show only the parts relevant to the present application, not the entire structure.

[0026] Figure 1 This is a flowchart illustrating an exception handling method based on quick payment according to an embodiment of this application. This method can be executed by an exception handling device or electronic device based on quick payment. The device or electronic device can be implemented by software (such as a system) and / or hardware, and can be integrated into any smart device with network communication capabilities. Figure 1 As shown, the exception handling method based on quick payment may include the following steps:

[0027] S101. Receive a transaction request. The transaction request is used to request a target payment transaction. The transaction request includes at least one of the following: payment instruction, transaction user identity information, and payment channel information.

[0028] In this step, a transaction request is a structured data packet sent to the payment platform by the client system (such as an app or webpage) on the target user's terminal when the target user initiates a payment operation. This transaction request includes the necessary information for the payment, enabling the payment platform to identify who is making the payment, to whom, and through which the payment is made.

[0029] A payment request may include at least one of the following: payment instructions, transaction user identity information, and payment channel information. The payment instructions may include information such as transaction amount, currency type, product description, and payment type. The transaction user identity information may include user ID and payment device information. The payment channel information may include channel type, channel subtype, and the merchant's configured ID within that channel. It should be noted that all transaction user identity information collected in this solution is authorized by the user, follows the principle of minimum necessity, and an authorization management entry is provided on the payment interface for users to choose independently.

[0030] It should be emphasized that all information collected in this application is information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data comply with the relevant laws, regulations and standards of the relevant countries and regions, necessary confidentiality measures have been taken, and there is no violation of public order and good morals. Corresponding operation portals are provided for users to choose to authorize or refuse.

[0031] S102. Extract features from the transaction request to obtain the transaction request features.

[0032] In this step, the transaction request is transformed into a set of structured, quantifiable features to drive subsequent transaction compensation decisions. In this application, machine learning algorithms can be used to extract features from the transaction request; this application does not impose any limitations on this method.

[0033] S103. Input the transaction request features into the pre-trained compensation decision generation model to obtain the target compensation decision output by the compensation decision generation model. The compensation decision generation model is used to output the target transaction compensation decision for the target payment transaction when it is determined that a transaction abnormality has occurred in the target payment transaction, so as to eliminate the transaction abnormality by executing the target compensation decision.

[0034] In this step, the compensation decision generation model is a machine learning model pre-trained using training sample data. This training sample data includes a large amount of historical transaction data and effective compensation decisions corresponding to failed transactions.

[0035] In this application, the compensation decision generation model is used to determine whether a target payment transaction will experience a transaction anomaly, and when it is determined that a target payment transaction has experienced a transaction anomaly, it outputs a target transaction compensation decision for the target payment transaction, so as to eliminate the transaction anomaly by executing the target compensation decision.

[0036] In this application, if a user refuses to implement the automated compensation decision, the system will automatically transfer the process to manual review (see S204).

[0037] One possible implementation involves pre-training steps A1-A3 for the compensated decision generation model:

[0038] A1. Obtain training sample data, which includes at least one of the following: historical transaction data, channel status logs, and user behavior feature data.

[0039] A2. Extract features from the training sample data to obtain the features of the training sample data.

[0040] A3. Input the features of the training sample data into the first neural network model for training, and construct a compensation decision generation model based on the first neural network model after training.

[0041] The following is an explanation of steps A1-A3 above:

[0042] The above-mentioned historical transaction data includes historical successful / failed transaction samples; the channel status log is a set of data that records the historical operating status of each payment channel (such as channel load rate); the user behavior characteristic data includes the behavior characteristics of multiple users (such as user identity information, user credit rating, transaction frequency, number of transaction failures, etc.), which are only for illustrative purposes and this application does not impose any restrictions on them.

[0043] Machine learning models can be used to extract features from training sample data, resulting in multidimensional training sample data features. These multidimensional features may include at least one of the following: transaction amount, user credit rating, device fingerprint, geographic location, and channel load rate. The training sample data features are then input into a first neural network model for training, and a compensating decision generation model is constructed based on the trained first neural network model. Optionally, the first neural network model can be a neural network model capable of generating decision trees, and the compensating decision generation model is a decision tree model. Preferably, the minimum sample splitting threshold of the decision tree model can be 5000, and the maximum depth can be 8; these are merely examples and do not constitute any limitation in this application.

[0044] Further, optionally, incremental transaction data is acquired, which refers to newly generated payment transaction data. The compensation decision generation model is then trained online based on this incremental transaction data to obtain an updated compensation decision generation model. In other words, as transaction data continues to be generated, the newly generated payment transaction data can be used to iteratively train the aforementioned first neural network model, thereby obtaining an updated compensation decision generation model. The updated compensation decision generation model better understands the current channel status and user behavior, thus enabling it to provide faster and more accurate compensation decisions. In this application, the average processing time for abnormal transactions can be reduced to 0.8 seconds, and the payment interruption time can be reduced to below 0.3 seconds, which can significantly improve the user experience.

[0045] The anomaly handling method for quick payment provided in this application embodiment receives a transaction request. The transaction request requests a target payment transaction and includes at least one of the following: payment instruction, transaction user identity information, and payment channel information. Feature extraction is performed on the transaction request to obtain transaction request features. The transaction request features are input into a pre-trained compensation decision generation model to obtain a target compensation decision output by the compensation decision generation model. The compensation decision generation model is used to output a target transaction compensation decision for the target payment transaction when it determines that a transaction anomaly has occurred, so as to eliminate the transaction anomaly by executing the target compensation decision.

[0046] In other words, in the technical solution of this application, when a pre-trained compensation decision generation model determines that a transaction anomaly has occurred in the target payment transaction, it can provide a corresponding target transaction compensation decision. This is essentially a dynamic compensation decision generation method. In contrast, existing technologies mechanically perform payments repeatedly according to a set number of retries and automatically switch to a backup payment channel after a final failed retry. This lacks awareness and response to real-time transaction conditions, and cannot dynamically adjust compensation strategies, resulting in low efficiency in handling payment anomalies. Furthermore, existing technologies rely heavily on manual processing, which is time-consuming and significantly increases labor and time costs. Therefore, compared to existing technologies, the anomaly handling method based on quick payment proposed in this application supports dynamic generation of compensation decisions. It can generate targeted compensation decisions in real time for transaction anomalies without human intervention, thereby improving payment anomaly handling efficiency, saving labor and time costs, and greatly enhancing the user experience. Moreover, the technical solution of this application is simple and convenient to implement, easy to popularize, and has a wider range of applications.

[0047] Figure 2 This is a flowchart illustrating an exception handling method based on quick payment, provided as another embodiment of this application. Further optimizations and extensions are possible based on the above technical solution, and it can be combined with the various optional implementation methods described above. For example... Figure 2 As shown, the exception handling method based on quick payment may include the following steps:

[0048] S201. Generate target transaction compensation task based on the target transaction compensation decision.

[0049] In this step, after receiving the target transaction compensation decision, the compensation decision execution end (such as the compensation decision execution engine) generates a target transaction compensation task based on the target transaction compensation decision. It should be noted that in this application, the decoupling degree between the core payment system and the exception handling module (i.e., the compensation decision execution end) can reach 95%, which not only significantly improves the stability, maintainability, elasticity and security of the system, but also provides an important architectural foundation for intelligent payment exception governance.

[0050] S202. Distribute the target transaction compensation task to the compensation decision execution end through the message queue, so that the compensation decision execution end can execute the target transaction compensation task.

[0051] In this application, the architecture of the message queue for compensation decision-making is designed as follows: 1) Load balancing is achieved using message queue partitioning; 2) Each partition handles specific types of compensation tasks (such as channel switching / retry tasks); 3) The consumer cluster can dynamically scale up and down.

[0052] After receiving the target transaction compensation task at the compensation decision execution end, it is persisted to the database cluster and the compensation decision operation is executed asynchronously; the callback result is written to the cache (TTL=24h).

[0053] In this application, if a user refuses to automatically execute a transaction compensation decision, the system will automatically transfer the process to manual review (S204).

[0054] S203. When the target transaction compensation task fails to be executed at the compensation decision execution end, the retry operation for the target transaction compensation task is repeatedly executed after waiting for a preset time until the target transaction compensation task is successfully executed or the number of retry operations is equal to the preset retry number threshold.

[0055] In this application, the number of retries for compensation decisions and the interval between each retrieval are pre-set, i.e., the preset duration. By setting a preset retrieval threshold, infinite retries caused by permanent failures (such as data errors or logical defects) can be effectively prevented, avoiding the invalidation of system resources (CPU, memory, database connections, etc.) and ensuring system stability and service quality. The "wait for the preset duration before retrying" design allows for the use of strategies such as exponential backoff or fixed intervals, which alleviates downstream service pressure and improves the retry success rate, reflecting a balance between system load and user experience.

[0056] In this step, if the target transaction compensation task fails to execute at the compensation decision execution end, the first step is repeated until the target transaction compensation task succeeds or the number of retry operations equals a preset retry threshold, such as N times. The first step includes: waiting a preset time for the i-th retry operation on the target transaction compensation task. Here, the initial default value of i is 0, and i is incremented by one for each retry operation.

[0057] Optionally, in this application, when a transaction anomaly occurs in the target payment transaction, the TCC mode is immediately activated. The TCC mode includes a Try phase, a Confirm phase, and a Cancel phase. In the Try phase, the transaction resources required for the target payment transaction are frozen, and a target transaction compensation task is generated for the target compensation operation. In the Confirm phase, the target transaction compensation task is executed. In the Cancel phase, the frozen transaction resources are rolled back.

[0058] In this application, based on the TCC mode, cross-service transaction consistency is achieved using the database's binary log; 2. Transaction state machine (Pending / Confirmed / Cancelled); 3. Automatic triggering of the Cancel phase operation upon timeout (default timeout = 30s).

[0059] S204. If the number of retry operations equals the preset retry threshold and the target transaction compensation task fails, a manual review mechanism is triggered to select and trigger the transaction compensation decision through manual review.

[0060] In this step, when the number of retries for the target transaction compensation task reaches the preset retry threshold, the manual review mechanism is triggered, and the transaction anomaly is subsequently handled manually.

[0061] The following is an explanation using a specific example.

[0062] In the following scenario, when a user uses quick payment, the third-party payment channel AA returns "System busy (503)". First, obtain and identify the transaction request characteristics: transaction amount = 200 yuan, user credit rating = A, channel load rate = 85%; then, input the above transaction request into the compensation decision generation model, and the compensation decision generation model outputs the target transaction compensation decision: "Switch to payment channel A for payment → delay for 10 seconds → retry". After receiving the target transaction compensation decision, the transaction execution end calls the API interface of payment channel A and sets a 10-second retry operation. If the transaction still fails after multiple retries through payment channel A, the manual review mechanism is immediately triggered for manual processing.

[0063] This application supports the dynamic combination of multiple compensation strategies, which greatly improves the flexibility of compensation strategies.

[0064] One possible implementation is to execute steps B1-B2 after triggering the manual review mechanism:

[0065] B1. Display the compensation strategy configuration interface. The compensation strategy configuration interface contains multiple compensation decision controls, and each compensation decision control corresponds to a transaction compensation decision.

[0066] In this step, one compensation decision control corresponds to one transaction compensation decision. Staff can select the compensation decision control. The specific operation method for this selection operation can be any of the following: drag operation, click operation (single or double click, etc.), long press operation, etc.

[0067] The transaction compensation decisions corresponding to the aforementioned multiple compensation decision controls include payment channel switching, delayed retry, and fund freezing, etc. These are merely examples, and the embodiments of this application do not impose any limitations on them.

[0068] B2. In response to the selection operation of the target compensation decision control, the transaction compensation decision corresponding to the selection operation is determined as the target transaction compensation decision, and the target compensation decision control is any one of multiple compensation decision controls.

[0069] In this step, staff select one of several compensation decision controls from the compensation strategy configuration interface and designate it as the target compensation decision control. The transaction compensation decision corresponding to this target compensation decision control is then set as the new transaction compensation decision (i.e., the target transaction compensation decision is updated). By providing a visual, operable, and traceable manual compensation decision update mechanism, the system's automation capabilities are ensured while empowering business personnel with the initiative to intervene and optimize strategies in real time.

[0070] Optionally, the transaction compensation decision corresponds to a transaction error code. The exception handling method based on quick payment proposed in this application further includes steps C1-C2:

[0071] C1. In the event that the target transaction compensation task fails to execute, generate the target transaction error code.

[0072] C2. Determine the transaction compensation decision corresponding to the target transaction error code as the target compensation decision.

[0073] Optionally, transaction error codes are standardized according to different payment link layers. Specifically, transaction error codes are divided into multiple non-overlapping transaction error code segments based on different payment link layers. Each transaction error code segment includes multiple transaction error codes. The payment link layers include at least one of the following: payment channel layer, protocol layer, system layer, network layer, and security layer. The transaction error codes within a transaction error code segment correspond one-to-one with the layer sections within the payment link layer. For example, the standardized error code system standard codes are divided into L1-L5 levels, namely: L1 level: channel layer errors (100-199), L2 level: protocol layer errors (200-299), L3 level: system layer errors (300-399), L4 level: network layer errors (400-499), and L5 level: security layer errors (500-599). Each transaction error code is associated with a detailed description document.

[0074] Furthermore, a transaction error code mapping table (including regular expression matching) can be established for each payment channel. Simultaneously, when the payment channel updates its error code, the transaction error code is automatically updated via API. This allows all payment channels to use a unified transaction error code, significantly improving the efficiency of transaction error code recognition.

[0075] Optionally, during the manual review and determination of the target transaction compensation decision, certain conditions must be followed to select the compensation decision setting that meets those conditions, i.e., conditional branch configuration is supported. For example, when the transaction error code is 503, transaction compensation decision A is executed; when the transaction error code is 504, transaction compensation decision B is executed; and when the transaction error code is 505, transaction compensation decision C is executed, as an example only.

[0076] The exception handling method based on quick payment proposed in this application uses a message queue as a task distribution channel, decoupling the compensation decision generation end from the execution end, allowing both to be independently expanded, deployed, and maintained. Distributing target transaction compensation tasks through the message queue ensures idempotency between the Confirm and Cancel phases, preventing data errors caused by repeated execution. Simultaneously, the high throughput and persistence characteristics of the message queue guarantee reliable delivery and sequential processing of compensation tasks in high-concurrency scenarios, improving overall system efficiency. Furthermore, by introducing an automatic retry mechanism (with pre-set waiting time and maximum retry threshold), the system can automatically recover and retry after compensation decision tasks fail due to momentary failures (such as network jitter or temporary service unavailability), avoiding interruptions in the compensation process due to occasional anomalies and significantly enhancing the overall system's robustness and self-healing capabilities. When the automatic retry operation reaches its limit and still fails, the system naturally enters the next stage (i.e., manual review). This mechanism clarifies the boundaries of responsibility between automated and manual processing, laying the foundation for building an operation and maintenance system that is "automated as the primary method and manual as a backup."

[0077] Figure 3 This is a flowchart illustrating an exception handling method based on quick payment, provided as another embodiment of this application. Further optimizations and extensions are possible based on the above technical solution, and it can be combined with the various optional implementation methods described above. For example... Figure 3 As shown, the exception handling method based on quick payment may include the following steps:

[0078] S301. Collect transaction environment data, which includes at least one of the following: payment channel health indicators, real-time transaction characteristics, and risk warning information.

[0079] In this step, payment channel health metrics include at least one of the following: throughput, transaction success rate, response time, transaction failure rate, availability status, and remaining transaction limit. Real-time transaction characteristics include sudden large transactions, current transaction amount, user location, device type, time period, and historical behavior. Risk warning information may include risk warnings from external institutions, such as abnormal logins and regulatory restrictions.

[0080] S302. Input the transaction environment data into the target prediction model to obtain the channel transaction success rate output by the target prediction model. The target prediction model is used to predict the transaction success rate of the payment channel.

[0081] The aforementioned target prediction model can predict the transaction success rate of payment channels and is a pre-trained model. This target prediction model can be a neural network sequence model.

[0082] As mentioned above, transaction environment data can provide comprehensive, dynamic, and high-dimensional input features for the target prediction model, reflecting the true state of the current payment environment.

[0083] In this step, transaction environment data is input into the target prediction model to obtain the channel transaction success rate predicted by the target prediction model. For example, with a 10-minute input sequence of transaction environment data, the target prediction model can predict the success rate of the payment channel in the next 5 minutes.

[0084] By collecting multi-dimensional transaction environment data (such as payment channel health indicators, real-time transaction characteristics, risk warning information, etc.) and inputting them into the target prediction model, the system can perceive changes in the external environment in real time and dynamically predict the transaction success rate of each payment channel. This can significantly improve the accuracy and timeliness of the prediction, which is better than static configuration or historical average estimation methods.

[0085] One possible implementation is to include the channel transaction success rate in the transaction request. This would allow the compensation decision generation model to perceive channel performance based on the channel transaction success rate and make better transaction compensation decisions.

[0086] S303. Every first time interval, the target prediction model is updated using a sliding window verification method with a preset window size of the second time interval, wherein the first time interval is greater than or equal to the second time interval.

[0087] In this step, a model update process is triggered every first duration (e.g., hourly). The data used for the update comes from a sliding time window with a window length of a second duration (e.g., 30 minutes). The first duration is greater than or equal to the second duration to ensure that the data windows used for each update do not overlap or only partially overlap, avoiding data leakage. This also ensures that the model is always retrained or its parameters are tuned based on the latest and most representative historical data. This allows the target prediction model to continuously adapt to changes in the payment environment (such as fluctuations in channel performance, shifts in user behavior, and the emergence of new fraud patterns), preventing model aging and resulting in inaccurate predictions.

[0088] S304. Obtain the success rate sequence of the target payment channel, which includes the success rates of multiple channel transactions of the target payment channel arranged in chronological order.

[0089] In this step, based on the output of the target prediction model, historical transaction success rate data for the target payment channel at different points in time can be continuously collected and organized into a time series, i.e., a success rate series, in chronological order. For example, for the target payment channel, the transaction success rate is recorded every 5 minutes.

[0090] S305. Input the success rate sequence and dynamic success rate fluctuation threshold into the early warning model to determine the target early warning level corresponding to the target payment channel.

[0091] The aforementioned early warning model is used to analyze the changing patterns of success rate sequences and identify whether there are abnormal declines, sharp fluctuations, or trend deterioration.

[0092] As mentioned above, the dynamic success rate fluctuation threshold can be adaptively adjusted based on factors such as historical performance, business period (e.g., higher tolerance during peak sales periods), and seasonality. For example, an alert is triggered when abnormal fluctuations are detected (e.g., a 50% drop in success rate).

[0093] In this step, the early warning model combines the success rate sequence of the target payment channel with the dynamic success rate fluctuation threshold to output the early warning result corresponding to the target payment channel, i.e., the target early warning level.

[0094] One possible implementation includes warning levels comprising at least one of the following: red warning, orange warning, and yellow warning. Specifically, a red warning is issued when the success rate in the success rate sequence is below a lower limit. An orange warning is issued when the channel transaction success rate falls within a first numerical range. A yellow warning is issued when the channel transaction success rate falls within a second numerical range, where the second numerical range does not overlap with the first numerical range, and the upper limit of the second numerical range is less than or equal to the lower limit of the first numerical range.

[0095] For example, when the transaction success rate of a payment channel is less than 5%, the channel is considered completely unusable and a red alert will be triggered; when the transaction success rate of a payment channel is greater than or equal to 10% and less than 20%, the channel performance is considered severely degraded and an orange alert will be triggered; when the transaction success rate of a payment channel is greater than or equal to 20% and less than 30%, the channel performance is considered abnormal and a yellow alert will be triggered.

[0096] In this step, by setting a target warning level for the target payment channel, we can achieve intelligent, hierarchical, and context-aware judgment of the health status of the target payment channel, thus avoiding false alarms or missed alarms.

[0097] S306. Conduct early warning operations on target payment channels based on target early warning levels.

[0098] In this step, based on the target early warning level output by the target prediction model for the target payment channel, the corresponding level of response early warning operation is triggered.

[0099] For example, when the target warning level is red, a red warning is issued for the target payment channel; when the target warning level is orange, an orange warning is issued for the target payment channel; and when the target warning level is yellow, a yellow warning is issued for the target payment channel. This way, upon receiving a warning for the target payment channel, staff will immediately take appropriate action.

[0100] Optionally, based on the warning level output by the model, the system can automatically trigger corresponding response actions. The warning level mechanism allows the system to respond differently according to the severity of the problem, avoiding unnecessary business losses caused by a "one-size-fits-all" shutdown of channels, while ensuring that high-risk issues are handled in a timely manner, optimizing resource allocation and emergency response speed.

[0101] For example, when the target warning level is red, the system will automatically trigger the suspension of the channel and trigger manual review or switch to a backup channel; when the target warning level is orange, the system will automatically trigger the reduction of the channel's selection weight; when the target warning level is yellow, the system will automatically trigger logging and notify staff to observe.

[0102] The anomaly handling method based on quick payment proposed in this application captures the changing trends, periodicity, and abrupt changes in the success rate of channel transactions through an early warning model. Combined with a success rate fluctuation threshold (rather than a static fixed threshold), it can effectively distinguish between normal fluctuations (such as natural declines during off-peak hours at night) and real failures, significantly reducing false alarm and false negative rates. Simultaneously, the system can proactively detect channel performance degradation trends (even providing early warnings before a transaction completely fails), allowing for early intervention (such as reducing weight or switching payment channels as compensation decisions), thereby improving the overall stability, availability, and disaster recovery capabilities of the payment chain.

[0103] Figure 4 This is a flowchart illustrating an exception handling method based on quick payment, provided as another embodiment of this application. Further optimizations and extensions are possible based on the above technical solution, and it can be combined with the various optional implementation methods described above. For example... Figure 4 As shown, the exception handling method based on quick payment may include the following steps:

[0104] S401. Construct a state space based on historical transaction status data. The historical transaction status data includes at least one of the following: channel status, transaction characteristics, and historical compensation decision results.

[0105] S402. Construct the action space based on a preset number of compensation decisions.

[0106] S403. Determine the reward function based on the success rate and delay time of the compensation decision.

[0107] S404. Based on the state space, action space, and reward function, perform reinforcement learning training on the reinforcement learning model to obtain the trained reinforcement learning model. The trained reinforcement learning model learns the success rate of each compensation decision in different transaction states.

[0108] S405. Input the transaction request features into the trained reinforcement learning model to obtain the target compensation decision output by the trained reinforcement learning model.

[0109] The following is a detailed explanation of steps S401-S405.

[0110] The aforementioned historical transaction status data includes at least one of the following: channel status, transaction characteristics, and historical compensation decision results. Channel status includes, for example, the current availability, error rate, and response latency of the payment channel; transaction characteristics include, for example, transaction amount, user level, device type, geographical location, and transaction time; historical compensation decision results include, for example, what kind of compensation was performed on similar transactions in the past (retry, switching channels, refund, etc.) and whether the compensation was ultimately successful.

[0111] In this application, historical transaction state data can be obtained from historical transaction logs, and a state space can be constructed to represent the "environment state" in reinforcement learning. By constructing a state space that can comprehensively reflect "the current transaction situation", a basis can be provided for the reinforcement learning model to determine "what action to take under what circumstances".

[0112] In this application, all compensation strategies supported by the transaction execution end (such as "retry the original channel", "switch to backup channel A", "manual review", "direct refund", etc.) are defined as finite discrete options, constituting an action space. This explicitly defines all reasonable operations that the reinforcement learning agent can perform, enabling it to select the optimal transaction compensation decision from these options given a state.

[0113] In this application, a reward function is designed to quantify the merits of each transaction compensation decision. The reward function is designed as follows: the higher the probability of the compensation success rate (positive reward), the greater the reward; the longer the compensation takes (negative penalty), the smaller the reward. It can be expressed as R = α⋅compensation success rate − β⋅delay time. Here, α and β are weighting coefficients that can be adjusted according to business objectives (e.g., prioritizing success rate or timeliness). For example, R = compensation success rate × 0.8 - delay time × 0.2.

[0114] In this application, after the reinforcement learning model is trained, the transaction request features are input into the trained reinforcement learning model to obtain the target compensation decision output by the trained reinforcement learning model. The experience replay pool used for training can have a capacity of 1 million, as illustrated in this example.

[0115] Optionally, a daily strategy report (e.g., the top 5 effective compensation decisions) can be generated. Inefficient compensation decisions can be automatically eliminated (e.g., if a compensation decision has a success rate of <30% for 3 consecutive days, it is considered an inefficient compensation decision and automatically eliminated). Manual intervention is also supported (team members can force the activation / deactivation of compensation decisions).

[0116] The exception handling method based on quick payment proposed in this application involves training a reinforcement learning model using a state space, action space, and reward function. This trained model learns which compensation decision will yield the maximum long-term cumulative reward under a given transaction state. In other words, it learns the success rate of each compensation decision under different transaction states. After training, transaction request features are input into the model to obtain the target compensation decision. Thus, the trained reinforcement learning model can adaptively predict the expected success rate and overall reward of each compensation decision under any new transaction state, thereby selecting the optimal transaction compensation decision.

[0117] In this application, the distributed transaction execution end adopts an idempotent interface gateway. Specifically, it supports a dual verification mechanism: 1. Transaction request ID (UUID) verification: caching the IDs of the most recent 100,000 payment transactions; 2. Version number verification: each transaction request carries a version number (initially 1, incremented by 1 upon retry); 3. Verification logic: if the ID is the same and the version number is greater than or equal to 1, the original result is returned directly. The interface modification also adheres to the following specifications: 1. All downstream systems must support GET / POST dual modes (idempotency verification); 2. The response header must include the "X-Request-ID" field; 3. The interface timeout is set to 3 seconds (automatically marked as abnormal if exceeded). Therefore, this application, through the combined design of an idempotent interface gateway, dual verification, and standardized interface specifications, achieves high-performance, highly observable, and highly maintainable distributed transaction execution capabilities while ensuring absolute idempotency of transactions. This not only benefits business aspects such as preventing financial losses and improving user experience, but also brings long-term value at the engineering level, including system architecture standardization, automated operation and maintenance, and rapid fault location, making it particularly suitable for payment business scenarios with high concurrency and high reliability requirements.

[0118] Figure 5 This is a schematic diagram of an exception handling device based on quick payment provided in an embodiment of this application. Figure 5 As shown, the anomaly handling device based on quick payment includes: a receiving module 501, a feature extraction module 502, and a processing module 503; wherein,

[0119] The receiving module 501 is used to receive a transaction request, the transaction request being used to request a target payment transaction, the transaction request including at least one of the following: payment instruction, transaction user identity information, and payment channel information;

[0120] Feature extraction module 502 is used to extract features from the transaction request to obtain transaction request features;

[0121] The processing module 503 is used to input the transaction request features into a pre-trained compensation decision generation model to obtain the target compensation decision output by the compensation decision generation model. The compensation decision generation model is used to output a target transaction compensation decision for the target payment transaction when it is determined that a transaction abnormality has occurred in the target payment transaction, so as to eliminate the transaction abnormality by executing the target compensation decision.

[0122] In one possible implementation, the transaction request also includes a channel transaction success rate, and the processing module is further configured to:

[0123] Collect transaction environment data, which includes at least one of the following: payment channel health indicators, real-time transaction characteristics, and risk warning information;

[0124] The transaction environment data is input into the target prediction model to obtain the channel transaction success rate output by the target prediction model. The target prediction model is used to predict the transaction success rate of payment channels.

[0125] Every first time interval, the target prediction model is updated using a sliding window verification method with a preset window size and a second time interval, wherein the first time interval is greater than or equal to the second time interval.

[0126] In one possible implementation, the processing module is further configured to:

[0127] Obtain a success rate sequence for the target payment channel, wherein the success rate sequence includes multiple channel transaction success rates of the target payment channel arranged chronologically;

[0128] The success rate sequence and dynamic success rate fluctuation threshold are input into the early warning model to determine the target early warning level corresponding to the target payment channel;

[0129] The target payment channel is given an early warning based on the target early warning level.

[0130] In one possible implementation, the processing module is further configured to:

[0131] Based on historical transaction status data, a state space is constructed, wherein the historical transaction status data includes at least one of the following: channel status, transaction characteristics, and historical compensation decision results.

[0132] Based on a preset number of compensation decisions, an action space is constructed;

[0133] Based on the success rate and delay time of the compensation decision, determine the reward function;

[0134] The reinforcement learning model is trained using the state space, the action space, and the reward function to obtain a trained reinforcement learning model. The trained reinforcement learning model learns the success rate of executing each compensation decision in different transaction states.

[0135] One possible implementation is that the processing module is specifically used for:

[0136] Acquire incremental transaction data, which is newly generated payment transaction data;

[0137] The compensation decision generation model is learned online based on the incremental transaction data to obtain an updated compensation decision generation model.

[0138] In one possible implementation, the processing module is further configured to:

[0139] Based on the target transaction compensation decision, a target transaction compensation task is generated;

[0140] The target transaction compensation task is distributed to the compensation decision execution end via a message queue, so that the compensation decision execution end executes the target transaction compensation task.

[0141] When the target transaction compensation task fails to be executed at the compensation decision execution terminal, the retry operation for the target transaction compensation task is repeatedly executed after waiting for a preset time until the target transaction compensation task is successfully executed or the number of retry operations is equal to the preset retry number threshold.

[0142] In one possible implementation, the processing module is further configured to:

[0143] If the number of times the retry operation is executed is equal to the preset retry threshold and the target transaction compensation task fails, a compensation strategy configuration interface is displayed. The compensation strategy configuration interface contains multiple compensation decision controls, and each compensation decision control corresponds to a transaction compensation decision.

[0144] In response to a selection operation on a target compensation decision control, the transaction compensation decision corresponding to the selection operation is determined as the target transaction compensation decision, wherein the target compensation decision control is any one of the plurality of compensation decision controls.

[0145] The above-described exception handling device based on quick payment can execute the method provided in any embodiment of this application, and has the corresponding functional modules and beneficial effects for executing the method. Technical details not described in detail in this embodiment can be found in the exception handling method based on quick payment provided in any embodiment of this application.

[0146] This invention also provides a computer program product.

[0147] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays, application-specific integrated circuits (ASICs), application-specific standard products (ASICs), systems-on-a-chip (SoCs), payload programmable logic devices, computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer program products, which may include one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be an application-specific or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0148] Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention, with reference to... Figure 6 , Figure 6 The electronic device 12 shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of this application. Figure 6 As shown, the electronic device 12 is represented in the form of a general-purpose computing device. The components of the electronic device 12 may include, but are not limited to: one or more processors or processing units 16, system memory 28, and bus 18 connecting different system components (including system memory 28 and processing unit 16).

[0149] Bus 18 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. Examples of these architectures include, but are not limited to, industry-standard architecture buses, microchannel architecture buses, enhanced industry-standard architecture buses, Video Electronics Standards Association (VESA) local buses, and peripheral component interconnect buses.

[0150] Electronic device 12 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by electronic device 12, including volatile and non-volatile media, removable and non-removable media.

[0151] System memory 28 may include computer system readable media in the form of volatile memory, such as random access memory 30 and / or cache memory 32. Electronic device 12 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 34 may be used to read and write non-removable, non-volatile magnetic media ( Figure 6 Not shown; usually referred to as a "hard drive"). Although Figure 6 As not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk may be provided. In these cases, each drive may be connected to bus 18 via one or more data media interfaces. Memory 28 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of this application.

[0152] A program / utility 40 having a set (at least one) of program modules 46 may be stored, for example, in memory 28. Such program modules 46 include, but are not limited to, an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 46 typically perform the functions and / or methods described in the embodiments of this application.

[0153] Electronic device 12 can also communicate with one or more external devices 14 (e.g., keyboard, pointing device, display 24, etc.), and with one or more devices that enable a user to interact with electronic device 12, and / or with any device that enables electronic device 12 to communicate with one or more other computing devices (e.g., network card, modem, etc.). This communication can be performed via input / output (I / O) interface 22. Furthermore, electronic device 12 can also communicate with one or more networks (e.g., local area network, wide area network, and / or public network, such as the Internet) via network adapter 20. As shown, network adapter 20 communicates with other modules of electronic device 12 via bus 18. It should be understood that, although... Figure 6 As not shown, other hardware and / or software modules may be used in conjunction with electronic device 12, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, independent disk redundant array systems, tape drives, and data backup storage systems.

[0154] The processing unit 16 executes various functional applications and data processing by running programs stored in the system memory 28. For example, it implements an anomaly handling method based on quick payment provided in this embodiment of the invention: receiving a transaction request, the transaction request being used to request a target payment transaction, the transaction request including at least one of the following: payment instruction, transaction user identity information, payment channel information; extracting features from the transaction request to obtain transaction request features; inputting the transaction request features into a pre-trained compensation decision generation model to obtain a target compensation decision output by the compensation decision generation model, the compensation decision generation model being used to output a target transaction compensation decision for the target payment transaction when it is determined that a transaction anomaly has occurred in the target payment transaction, so as to eliminate the transaction anomaly by executing the target compensation decision.

[0155] This invention provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements an anomaly handling method based on quick payment as provided in all embodiments of this invention: receiving a transaction request, the transaction request being used to request a target payment transaction, the transaction request including at least one of the following: payment instruction, transaction user identity information, and payment channel information; extracting features from the transaction request to obtain transaction request features; inputting the transaction request features into a pre-trained compensation decision generation model to obtain a target compensation decision output by the compensation decision generation model, the compensation decision generation model being used to output a target transaction compensation decision for the target payment transaction when it is determined that a transaction anomaly has occurred in the target payment transaction, so as to eliminate the transaction anomaly by executing the target compensation decision. The computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium can be, for example, but not limited to, an electronic device, apparatus, or device that is electrical, magnetic, optical, electromagnetic, infrared, or semiconductor, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: electrical connections having one or more wires, portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory (erasable programmable read-only memory or flash memory), optical fibers, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination of the foregoing. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an electronic device, apparatus, or device that executes instructions.

[0156] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in conjunction with an electronic device, apparatus, or device that executes instructions.

[0157] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including but not limited to wireless, wire, optical fiber, radio frequency, etc., or any suitable combination thereof.

[0158] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages ​​as well as conventional procedural programming languages, such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including local area networks (LANs) or wide area networks (WANs), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0159] It should be noted that the information collected in this application is information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data all comply with the relevant laws, regulations and standards of the relevant countries and regions, necessary confidentiality measures have been taken, and they do not violate public order and good morals. Corresponding operation portals are provided for users to choose to authorize or refuse.

[0160] Note that the above description is merely a preferred embodiment of the present invention and the technical principles employed. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in detail through the above embodiments, the present invention is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of the present invention, the scope of which is determined by the scope of the appended claims.

Claims

1. An anomaly handling method based on quick payment, characterized in that, The method includes: Receive a transaction request, the transaction request being used to request a target payment transaction, the transaction request including at least one of the following: payment instruction, transaction user identity information, payment channel information; The transaction request is subjected to feature extraction to obtain transaction request features; The transaction request features are input into a pre-trained compensation decision generation model to obtain a target compensation decision output by the compensation decision generation model. The compensation decision generation model is used to output a target transaction compensation decision for the target payment transaction when it is determined that a transaction anomaly has occurred in the target payment transaction, so as to eliminate the transaction anomaly by executing the target compensation decision.

2. The method according to claim 1, characterized in that, The transaction request also includes the channel transaction success rate, and the method further includes: Collect transaction environment data, which includes at least one of the following: payment channel health indicators, real-time transaction characteristics, and risk warning information; The transaction environment data is input into the target prediction model to obtain the channel transaction success rate output by the target prediction model. The target prediction model is used to predict the transaction success rate of payment channels. Every first time interval, the target prediction model is updated using a sliding window verification method with a preset window size and a second time interval, wherein the first time interval is greater than or equal to the second time interval.

3. The method according to claim 2, characterized in that, The method further includes: Obtain a success rate sequence for the target payment channel, wherein the success rate sequence includes multiple channel transaction success rates of the target payment channel arranged chronologically; The success rate sequence and dynamic success rate fluctuation threshold are input into the early warning model to determine the target early warning level corresponding to the target payment channel; The target payment channel is given an early warning based on the target early warning level.

4. The method according to claim 1, characterized in that, The method further includes: Based on historical transaction status data, a state space is constructed, wherein the historical transaction status data includes at least one of the following: channel status, transaction characteristics, and historical compensation decision results. Based on a preset number of compensation decisions, an action space is constructed; Based on the success rate and delay time of the compensation decision, determine the reward function; The reinforcement learning model is trained using the state space, the action space, and the reward function to obtain a trained reinforcement learning model. The trained reinforcement learning model learns the success rate of executing each compensation decision in different transaction states.

5. The method according to claim 1, characterized in that, The method further includes: Acquire incremental transaction data, which is newly generated payment transaction data; The compensation decision generation model is learned online based on the incremental transaction data to obtain an updated compensation decision generation model.

6. The method according to claim 1, characterized in that, The method further includes: Based on the target transaction compensation decision, a target transaction compensation task is generated; The target transaction compensation task is distributed to the compensation decision execution end via a message queue, so that the compensation decision execution end executes the target transaction compensation task. When the target transaction compensation task fails to be executed at the compensation decision execution terminal, the retry operation for the target transaction compensation task is repeatedly executed after waiting for a preset time until the target transaction compensation task is successfully executed or the number of retry operations is equal to the preset retry number threshold.

7. The method according to claim 6, characterized in that, The method further includes: If the number of times the retry operation is executed is equal to the preset retry threshold and the target transaction compensation task fails, a compensation strategy configuration interface is displayed. The compensation strategy configuration interface contains multiple compensation decision controls, and each compensation decision control corresponds to a transaction compensation decision. In response to a selection operation on a target compensation decision control, the transaction compensation decision corresponding to the selection operation is determined as the target transaction compensation decision, wherein the target compensation decision control is any one of the plurality of compensation decision controls.

8. An anomaly handling device based on quick payment, characterized in that, The device includes: A receiving module is used to receive a transaction request, the transaction request being used to request a target payment transaction, the transaction request including at least one of the following: payment instruction, transaction user identity information, and payment channel information; The feature extraction module is used to extract features from the transaction request to obtain transaction request features; The processing module is used to input the transaction request features into a pre-trained compensation decision generation model to obtain the target compensation decision output by the compensation decision generation model. The compensation decision generation model is used to output a target transaction compensation decision for the target payment transaction when it is determined that a transaction anomaly has occurred in the target payment transaction, so as to eliminate the transaction anomaly by executing the target compensation decision.

9. An electronic device, characterized in that, include: One or more processors; Memory, used to store one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the exception handling method based on quick payment as described in any one of claims 1 to 7.

10. A storage medium, characterized in that, The system contains a data processing program that is run by a processor to perform the exception handling method based on quick payment as described in any one of claims 1-7.

Images