Third-party payment refusing intelligent appeal method, system and device and medium

Abstract

The invention discloses a third-party payment refusal intelligent appeal method, system and device and a medium, and the method specifically comprises the steps: collecting a refusal event flow of multiple payment channels in real time, and outputting a structured refusal data set; based on the structured payment refusing data set, analyzing the payment refusing description text and the transaction voucher image to obtain a standardized payment refusing classification code and structured transaction evidence; the standardized payment refusing classification codes and the structured transaction evidences are subjected to feature cascading and input to a dual-prediction decision module for processing, and order risk levels and complaint success rates are obtained; constructing an optimization model according to the order risk level and the appeal success rate, and solving an optimal appeal batch combination; and based on the optimal appeal batch combination, dynamically rendering proof materials according to payment channel API specifications, and submitting appeal through a self-adaptive retry mechanism. According to the invention, full-process automatic processing of the third-party payment refusing appeal is realized, the appeal efficiency and success rate are improved, and the labor cost and risk are reduced.

Description

Technical Field

[0001] This invention relates to the field of Internet technology, and in particular to a method, system, device and medium for intelligent appeal of third-party payment chargebacks. Background Technology

[0002] In today's era of rapid development in digital payments, third-party payment channels have become an indispensable part of commercial transactions. However, chargebacks through third-party payment channels occur frequently, causing numerous problems for merchants and platforms. Typically, when a chargeback occurs, merchants or platforms need to manually appeal to have it revoked, a process that exposes many issues that urgently need to be addressed.

[0003] First, the manual process for handling chargeback appeals from third-party payment channels is extremely cumbersome. Merchants or platform staff need to spend a significant amount of time and effort collecting and organizing massive amounts of chargeback order information and related materials. This information is scattered across multiple payment channels and different business systems, making manual collection not only inefficient but also prone to omissions or errors, increasing the risk and difficulty of subsequent processing.

[0004] Secondly, as business scales up, the number of chargeback orders may increase significantly. When faced with large-scale chargeback events, manual processing is clearly insufficient to meet the demand for rapid response. Due to limited manual processing capacity, a large backlog of chargeback orders prevents merchants from submitting appeals in a timely manner, potentially causing them to miss the optimal appeal window and expose them to greater economic losses and reputational risks.

[0005] Finally, manual operations are inevitably affected by human factors and prone to errors. During the process of compiling information on chargeback orders and preparing appeal materials, staff may, due to negligence, fatigue, or inaccurate understanding of business rules, result in incomplete or incorrect appeal materials. These errors may lead to appeal rejection, reduce the success rate of appeals, and further exacerbate the merchant's losses.

[0006] Furthermore, manual appeals require a significant investment of human resources, including information gathering, material preparation, and drafting appeal statements. This not only increases the business's operating costs but also consumes employees' time and energy that could be used for more valuable tasks, leading to resource waste and reduced overall operational efficiency. Summary of the Invention

[0007] The purpose of this invention is to provide a method, system, device, and medium for intelligent appeals against third-party payment chargebacks, which realizes fully automated processing of the third-party payment chargeback appeal process, improves appeal efficiency and success rate, and reduces labor costs and risks, thereby solving at least one of the aforementioned problems in the prior art.

[0008] In a first aspect, the present invention provides a smart appeal method for third-party payment chargebacks, the method specifically comprising: The distributed message middleware collects chargeback event streams from multiple payment channels in real time, and uses a stream processing engine to aggregate event time windows, outputting a structured chargeback dataset. Based on the structured chargeback dataset, the chargeback description text and transaction voucher image are parsed through a multimodal parsing channel to obtain standardized chargeback classification codes and structured transaction evidence; The standardized chargeback classification code and structured transaction evidence are concatenated and input into the dual prediction decision module for processing to obtain the order risk level and appeal success rate; With appeal cost as a constraint and maximizing the expected amount recovered as the objective function, an optimization model is constructed based on the order risk level and appeal success rate to solve for the optimal combination of appeal batches. Based on the optimal combination of appeal batches, the evidence materials are dynamically rendered according to the payment channel API specifications, and the appeal is submitted through an adaptive retry mechanism.

[0009] Secondly, the present invention provides a third-party payment chargeback intelligent appeal system, the system specifically comprising: The first intelligent appeal module is used to collect chargeback event streams from multiple payment channels in real time through a distributed message middleware, and to aggregate event time windows using a stream processing engine to output a structured chargeback dataset. The second intelligent appeal module is used to parse the chargeback description text and transaction voucher image through a multimodal parsing channel based on the structured chargeback dataset to obtain standardized chargeback classification codes and structured transaction evidence; The third intelligent appeal module is used to concatenate standardized chargeback classification codes and structured transaction evidence, and input them into the dual prediction decision module for processing to obtain the order risk level and appeal success rate. The fourth intelligent appeal module is used to construct an optimization model based on the order risk level and appeal success rate, with appeal cost as the constraint and maximizing the expected recovery amount as the objective function, to solve for the optimal combination of appeal batches. The fifth intelligent appeal module is used to dynamically render supporting materials according to the payment channel API specifications based on the optimal appeal batch combination, and submit the appeal through an adaptive retry mechanism.

[0010] Thirdly, the present invention provides a computer device, comprising: a memory and a processor, and a computer program stored in the memory, wherein when the computer program is executed on the processor, it implements the third-party payment chargeback smart appeal method as described in any of the above methods.

[0011] Fourthly, the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the third-party payment chargeback intelligent appeal method as described in any of the above methods.

[0012] Compared with the prior art, the present invention has at least one of the following technical effects: 1. This invention automates the entire process of third-party payment chargeback appeals, improving appeal efficiency and success rate while reducing labor costs and risks.

[0013] 2. This invention enables automated collection and preliminary processing of chargeback events. This process requires no manual intervention, greatly improving the efficiency of data processing and enabling rapid response to large-scale chargeback events, avoiding the problems of cumbersome manual operation and slow response speed.

[0014] 3. This invention can extract chargeback information more comprehensively and accurately, reduce errors that may occur during manual operation, improve the accuracy and completeness of appeal materials, and thus increase the success rate of appeals.

[0015] 4. This invention can rationally allocate appeal resources, prioritize the processing of high-value, high-success-rate orders, avoid resource waste, and improve resource utilization efficiency.

[0016] 5. This invention can ensure that the evidence materials meet the requirements of different payment channels and improve the compliance of the appeal materials.

[0017] 6. This invention analyzes text and images through a multimodal parsing channel to obtain standardized classification codes and structured evidence, comprehensively and accurately extracting key information and improving the quality of appeal materials.

[0018] 7. This invention concatenates classification codes and transaction evidence features and inputs them into a dual prediction decision module to obtain the order risk level and appeal success rate, providing a scientific basis for appeal decisions.

[0019] 8. This invention verifies, calculates, transforms, and quantifies the feature set input to the second-level prediction model, and outputs a predicted appeal success rate with reliability assessment, thereby enhancing the credibility of the prediction results.

[0020] 9. This invention constructs an optimization model based on appeal costs and expected recovery amounts to solve for the optimal combination of appeal batches, rationally allocate resources, and improve appeal efficiency.

[0021] 10. This invention dynamically renders evidence materials according to the payment channel API specification and submits appeals through an adaptive retry mechanism, ensuring the compliance of evidence materials and improving the success rate of appeal submission. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0023] Figure 1 This is a flowchart illustrating a third-party payment chargeback intelligent appeal method according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the structure of a third-party payment chargeback intelligent appeal system provided in an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0024] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0025] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0026] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0027] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0028] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0029] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0030] In this application embodiment, the entity executing the process includes a terminal device. This terminal device includes, but is not limited to, devices capable of executing the methods disclosed in this application, such as servers, computers, smartphones, and tablets. Figure 1 A flowchart illustrating a third-party payment chargeback intelligent appeal method according to an embodiment of the present invention is shown below: S101 collects chargeback event streams from multiple payment channels in real time through a distributed message middleware, and uses a stream processing engine to aggregate event time windows to output a structured chargeback dataset.

[0031] In this embodiment, based on factors such as system performance requirements, reliability requirements, and compatibility with existing systems, Apache Kafka is selected as the distributed message middleware. Kafka has advantages such as high throughput, strong scalability, and good fault tolerance, which can meet the need for real-time collection of chargeback event streams from multiple payment channels. Multiple Kafka nodes are deployed to form a Kafka cluster. Multiple topics are set up in the cluster, each corresponding to a chargeback event stream from a third-party payment channel. A Kafka producer is configured in each third-party payment channel's system. The producer is responsible for sending chargeback events to the corresponding Kafka topic in real time. The producer needs to configure the message serialization method to ensure that the messages can be parsed correctly.

[0032] Apache Flink was chosen as the stream processing engine. Flink boasts powerful stream processing capabilities, supporting event-time processing, state management, and other functions, enabling effective processing of real-time collected chargeback event streams. Multiple Flink Task Managers and one Flink Job Manager are deployed to form a Flink cluster. The Job Manager is responsible for task scheduling and management, while the Task Manager is responsible for executing specific processing tasks. A dedicated job for processing chargeback event streams is created within the Flink cluster. This job consumes the chargeback event stream in real-time from various topics in the Kafka cluster through a Kafka Consumer.

[0033] Start Kafka producers in each third-party payment channel's system to ensure that chargeback events are sent to Kafka topics in real time. The producers will continuously listen for chargeback events from the payment channels, and once a new chargeback event occurs, it will be immediately sent to the corresponding Kafka topic. Start a job in the Flink cluster to process the chargeback event stream. The Kafka consumers in the job will pull the chargeback event stream from various topics in the Kafka cluster and convert it into Flink's internal data stream format.

[0034] In chargeback events, a time field that accurately reflects the event's occurrence time is identified; this field will serve as the basis for event time window aggregation. An appropriate time window size is set according to business needs. For example, a 5-minute time window means that the collected chargeback events are aggregated every 5 minutes. In the Flink job, Flink's window functions are used to aggregate the chargeback event stream using time windows. Within each time window, chargeback events are statistically analyzed, such as counting the number of chargeback events and the chargeback amount for each payment channel within that time window. Simultaneously, relevant information about chargeback events is organized and merged; for example, multiple chargeback events for the same order are merged into one record, and key information such as order number, payment channel, chargeback reason, and chargeback amount are extracted.

[0035] Define the data structure for the structured chargeback dataset based on business requirements. The structured chargeback dataset can contain the following fields: order number, payment channel, chargeback reason, chargeback amount, chargeback time, and event time window. In the Flink job, the aggregated chargeback event data is formatted according to the defined data structure, converting it into a structured data format.

[0036] In this embodiment, chargeback event streams can be collected and processed in real time, ensuring that merchants and the platform can obtain chargeback information promptly. By aggregating events through event time windows, chargeback events can be accurately counted and analyzed, avoiding omissions and errors. Both the distributed message middleware and the stream processing engine are scalable and can be expanded accordingly as business scales. Compared to traditional manual collection methods, this method significantly improves the efficiency of chargeback event processing and reduces labor costs.

[0037] S102, based on a structured chargeback dataset, uses a multimodal parsing channel to parse chargeback description text and transaction document images to obtain standardized chargeback classification codes and structured transaction evidence.

[0038] In this embodiment, the chargeback description text and transaction voucher image associated with each chargeback order are retrieved from the data storage system storing the structured chargeback dataset, according to the order number or other unique identifier.

[0039] A combination of rule-based and machine learning natural language processing techniques is employed. The rule-based approach handles common chargeback reason statements; for example, defining keywords and phrases allows for direct determination of the approximate category of the chargeback reason when these keywords and phrases appear in the text. The machine learning approach handles more complex text statements, training a classification model to categorize chargeback explanations.

[0040] A large amount of historical chargeback explanation text data was collected and manually labeled, with each text indicating the category of chargeback reason. This labeled data was then used as training data to train a machine learning classification model. The machine learning classification model was trained using algorithms such as decision trees and support vector machines. During training, methods such as cross-validation were used to evaluate and optimize the model, improving its classification accuracy.

[0041] Image recognition is performed using Convolutional Neural Networks (CNNs) from deep learning. CNNs can automatically extract features from images and identify key information in transaction voucher images. A large amount of transaction voucher image data was collected, including voucher images of different types and formats, and these images were annotated to highlight key information such as transaction amount, transaction time, and information of the transacting parties. This annotated data was then used to train the CNN model, adjusting its parameters to improve the model's accuracy in recognizing image information. The trained CNN model was deployed to the image parsing module, and during actual operation, the model was continuously optimized based on the parsing results, such as adjusting the model's threshold and adding new training data.

[0042] The preprocessed chargeback explanation text is input into the text parsing module. First, a rule-based method is used to perform preliminary parsing of the text to determine whether it contains common chargeback reason keywords and phrases. If so, the approximate category of the chargeback reason is directly determined. If not, a trained machine learning classification model is used to classify the text to obtain the category of the chargeback reason.

[0043] The preprocessed transaction voucher image is input into the image parsing module. A CNN model is used to extract and recognize features from the image, identifying key information such as transaction amount, transaction time, information of both parties, and transaction order number. The identified information is then organized and stored to form structured transaction evidence.

[0044] Based on industry standards and business needs, a standardized chargeback classification coding system was developed. The chargeback reason categories obtained from the text parsing module were mapped to the standardized chargeback classification codes. The structured transaction evidence obtained from the image parsing module underwent further structuring processing to ensure that each transaction evidence field had a clear definition and format.

[0045] In this embodiment, compared to traditional manual parsing methods, the multimodal parsing channel can quickly and automatically parse chargeback text and transaction document images, significantly improving processing efficiency. Employing technologies such as natural language processing and deep learning, it can accurately identify chargeback reasons and key information in transaction documents, reducing human error. Standardizing the parsing results allows data from different sources and formats to be represented uniformly, facilitating subsequent data analysis and processing. The multimodal parsing channel can be flexibly expanded according to business needs, such as adding parsing capabilities for new chargeback reason categories or transaction document types.

[0046] S103 concatenates standardized chargeback classification codes and structured transaction evidence, and inputs them into the dual prediction decision module for processing to obtain the order risk level and appeal success rate.

[0047] In this embodiment, standardized chargeback classification codes are standardized representations of chargeback reasons, with different codes corresponding to different chargeback reason categories. For example, code "001" might represent "unauthorized transaction," and "002" might represent "goods not received," etc. These codes reflect the core issues of chargeback orders and are one of the important bases for assessing order risk and appeal success rates.

[0048] Structured transaction evidence includes key information such as transaction amount, transaction time, information of the parties involved in the transaction, and transaction order number.

[0049] The standardized chargeback classification code and structured transaction evidence are integrated using a sequential concatenation approach. First, the standardized chargeback classification code is used as a feature field. Then, each field from the structured transaction evidence is added sequentially after this code, forming a new feature vector. For example, the chargeback classification code is placed first, followed by the transaction amount, transaction time, information about the transacting parties, and the transaction order number.

[0050] Before cascading, ensure that the format of each feature is consistent. For numerical features, such as transaction amount, retain a certain number of decimal places; for date and time features, such as transaction time, use a specific date and time format; for text features, such as information about the transacting parties, remove unnecessary spaces and special characters. Obtain standardized chargeback classification codes and structured transaction evidence from the feature processing module through the data interaction interface. Combine them into a complete feature vector according to the determined cascading method and format consistency requirements.

[0051] The dual-prediction decision-making module consists of two sub-modules: an order risk assessment sub-module and an appeal success rate prediction sub-module. These two sub-modules can operate independently or collaborate to process the input features.

[0052] The cascaded feature vector is input into the order risk assessment submodule. Based on the established risk assessment rules, the submodule matches and analyzes each feature in the feature vector. For example, it checks the chargeback reason category corresponding to the chargeback classification code and, combined with features such as transaction amount and transaction time, determines the order's risk level. Risk levels can be categorized into three levels: low risk, medium risk, and high risk.

[0053] The cascaded feature vector is input into the appeal success rate prediction submodule. The submodule analyzes and calculates the feature vector based on the established prediction model to predict the appeal success rate of the rejected order.

[0054] The order risk level output by the order risk assessment submodule and the appeal success rate output by the appeal success rate prediction submodule are integrated to form a complete assessment result.

[0055] In this embodiment, by cascading and comprehensively analyzing features such as chargeback reasons and transaction evidence, the risk of chargeback orders can be assessed more comprehensively, avoiding the limitations of single-feature assessment. The dual-prediction decision module processes data from two perspectives: order risk and appeal success rate. By combining historical data and business rules, the accuracy of predictions is improved. The output order risk level and appeal success rate results provide strong support for merchants and the platform's appeal decisions, helping merchants allocate resources rationally, improve appeal success rates, and reduce economic losses. The feature cascading method and the dual-prediction decision module can be flexibly adjusted and expanded according to business needs, such as adding new features or optimizing assessment rules and prediction models.

[0056] S104 uses appeal cost as a constraint and maximizing the expected recovery amount as the objective function. An optimization model is constructed based on the order risk level and appeal success rate to solve for the optimal combination of appeal batches.

[0057] In this embodiment, an upper limit for appeal costs is determined based on the merchant's actual financial situation and resource constraints. For example, the total cost a merchant can use for chargeback appeals this month is 10,000 yuan. When constructing the optimization model, the constraint is that the sum of the appeal costs of all selected orders does not exceed this upper limit.

[0058] The objective function is to maximize the expected recovery amount. The expected recovery amount is related to the success rate of the appeal for each order. For each order, the expected recovery amount can be expressed as the order amount multiplied by the appeal success rate. When constructing the optimization model, the goal is to select a set of orders for appeal to maximize the sum of the expected recovery amounts for this set of orders.

[0059] Define a decision variable for each rejected order, using 0 or 1 to indicate whether the order is selected for appeal. Construct constraint expressions based on appeal cost constraints. Construct objective function expressions based on the expected recovered amount objective function.

[0060] Heuristic algorithms or rule-based methods can be used to solve the optimization model. For example, a greedy algorithm can be used to select orders for appeal in order of priority according to certain rules (such as the ratio of expected recovery amount to appeal cost from high to low) until the appeal cost constraint is met.

[0061] For each order, calculate the ratio of its expected recovery amount to the appeal cost. This ratio reflects the expected recovery amount that a unit of appeal cost can bring; the higher the ratio, the higher the appeal priority of the order. Sort all orders according to the priority index from high to low. Then, select orders from the sorted order list for appeal in turn. After selecting an order each time, calculate the sum of the appeal costs of the currently selected orders. If the sum of appeal costs does not exceed the appeal cost upper limit, continue to select the next order; if it exceeds the upper limit, stop selecting. The final set of selected orders is the optimal appeal batch combination.

[0062] In this embodiment, under the constraint of limited appeal costs, the optimal combination of appeal batches is selected, avoiding resource waste and improving resource utilization efficiency. By maximizing the expected recovered amount, merchants can gain more economic benefits and reduce losses caused by chargebacks. The output optimal combination of appeal batches provides merchants with a clear basis for appeal decisions, helping them to rationally plan their appeal work.

[0063] S105, based on the optimal combination of appeal batches, dynamically renders the evidence materials according to the payment channel API specifications, and submits the appeal through an adaptive retry mechanism.

[0064] In this embodiment, API documentation is collected for each payment channel involved in the optimal appeal batch combination. The API documentation details the payment channel's requirements for appeal evidence, including material format (e.g., PDF, JPEG), content requirements (e.g., required transaction information, voucher images), submission method (e.g., HTTP request format, parameters), and interface address. The collected API documentation is parsed to extract key information, which is then stored in the system's configuration file or database. For example, the evidence format requirements, content requirements, and interface address for each payment channel are stored separately for subsequent dynamic rendering of evidence and API interaction.

[0065] Based on the evidentiary requirements of different payment channels, a universal material template is designed. The template includes fixed text content (such as the appeal title and merchant information) and variable data fill areas (such as order information and transaction voucher images). For each order in the optimal appeal batch combination, relevant information is extracted from the structured chargeback dataset and parsed transaction evidence according to the corresponding payment channel's API specifications and filled into the corresponding material template. For example, text information such as order number, transaction amount, and transaction time are filled into the corresponding areas of the PDF template, and transaction voucher images are inserted into designated locations. Simultaneously, the filled materials are formatted and optimized according to the payment channel's requirements, such as adjusting image size and compressing files, to generate evidentiary materials that conform to the payment channel's API specifications.

[0066] The payment channel API interaction module submits dynamically rendered evidence materials to the payment channel's appeal interface via HTTP requests. During submission, key information such as submission time, order number, and payment channel is recorded and stored in the log module. The payment channel API interaction module receives the response from the payment channel and determines whether the appeal submission was successful based on the response.

[0067] The retry control module determines whether to retry, as well as the number of retries and the interval, based on the reason for failure and the preset retry strategy. For example, if the problem is a network connection timeout or a server unresponsiveness, the retry control module can set an initial retry interval (e.g., 5 seconds) and gradually increase the interval time with each retry (e.g., increasing by 5 seconds each time), up to a maximum of 3 retries. This avoids frequent retries caused by network fluctuations and allows sufficient time for network recovery. If the evidence materials do not meet the requirements, such as incorrect formatting or missing content, the retry control module can first feed back the failure information to the evidence material rendering module, allowing the evidence material rendering module to re-examine and correct the evidence materials before retrying. The number of retries can be set according to the severity of the problem, such as a maximum of 2 retries.

[0068] The retry control module controls the payment channel API interaction module to retries according to the established retry strategy. During each retry, key information such as the retry time, order number, payment channel, reason for failure, and number of retries is recorded and sent to the log recording module for storage. If the retry is successful, it is processed according to the success handling procedure; if the maximum number of retries is reached and the retry still fails, the final failure log information is recorded, and the order is marked as an appeal submission failure.

[0069] The payment channel API interaction module continuously monitors the appeal processing results returned by the payment channel. Upon receiving a result, it parses the result to extract key information, such as whether the appeal was successful and the amount recovered. The parsed appeal processing result is then fed back to the merchant's or platform's relevant system and recorded in the log module.

[0070] In this embodiment, dynamically rendering supporting evidence ensures that the generated evidence meets the requirements of different payment channels, reducing appeal failures due to non-compliant evidence. The adaptive retry mechanism adopts appropriate retry strategies based on different reasons for failure, improving the success rate of appeal submissions and avoiding failures caused by network issues or temporary system malfunctions. Automating the rendering of supporting evidence and the appeal submission process reduces manual intervention, improves the efficiency of appeal processing, and enables merchants to obtain appeal results faster, reducing economic losses and reputational risks.

[0071] In some embodiments, step S101 above, which involves real-time collection of chargeback event streams from multiple payment channels using a distributed message middleware and aggregation of event time windows using a stream processing engine to output a structured chargeback dataset, specifically includes: Through the channel adapter layer of the distributed message middleware, raw chargeback event streams from multiple payment channels are received in real time. Each event in the raw chargeback event stream includes a merchant identifier, order number, and timestamp. The original chargeback event stream is input into the stream processing engine, and the event time window segmentation strategy is applied to aggregate the time dimension based on the sliding window mechanism. Within each defined time window, data cleaning and key field extraction operations are performed synchronously to obtain the window dataset; Perform multidimensional aggregation calculations on the window dataset, grouping and statistically analyzing the number of events, order list, and total amount by merchant and channel to obtain the aggregation results; Convert the aggregation results into a structured chargeback dataset with a pre-defined pattern.

[0072] In this embodiment, a channel adapter layer is built in the distributed message middleware, with a specific adapter developed for each payment channel. The adapter is responsible for interfacing with the payment channel's interface, receiving the raw chargeback event stream in real time according to the communication protocol (e.g., HTTP, WebSocket) and message format (e.g., JSON, XML) specified by the payment channel. Upon receiving the raw chargeback event stream, the adapter parses each event, extracting key information such as merchant identifier, order number, and timestamp. Simultaneously, it performs preliminary validation of the events, checking for correct format and missing key fields. If an event format error or missing key fields are found, the event is marked as invalid, and relevant information is recorded for subsequent analysis. The parsed and validated raw chargeback events are forwarded to the message queue of the distributed message middleware for processing by the subsequent stream processing engine. The message queue adopts a distributed architecture, possessing high availability and scalability, ensuring reliable transmission and storage of the event stream.

[0073] In the stream processing engine cluster, configure the event time window partitioning strategy. Choose a sliding window mechanism, and set the sliding window size and sliding step according to business needs. The stream processing engine reads the raw chargeback event stream from the message queue and allocates the events to the corresponding time windows based on the event timestamps. For each time window, the stream processing engine maintains a window state, recording the event information that has arrived within that window. As new events arrive, the stream processing engine dynamically updates the window state. When the window slides, expired events are removed from the window state, and newly arrived events are added. Simultaneously, the stream processing engine persists the window state to prevent data loss due to system failures.

[0074] Data cleaning rules are defined in the stream processing engine to remove noisy and anomalous data from the original chargeback events. During data cleaning, key fields, such as merchant name, order amount, and chargeback reason, are extracted from each event. Key field extraction is based on predefined field mapping rules, mapping fields from the original events to corresponding fields in the structured dataset. After data cleaning and key field extraction, the event information within each time window is integrated into a window dataset. The window dataset contains key field information for all valid events within that window.

[0075] Based on business requirements, a grouping strategy was determined to group statistics by merchant and payment channel. This involves aggregating and calculating chargeback events for each merchant across each payment channel. Within each defined time window, multidimensional aggregation calculations are performed on the window dataset to calculate aggregation metrics such as the number of events, order list, and total amount for each group. The aggregation results for each time window are stored in the temporary storage area of ​​the stream processing engine and dynamically updated as the window slides. When the window slides to a new time point, the aggregation metrics within that window are recalculated, and the corresponding aggregation results are updated.

[0076] A predefined schema for the structured chargeback dataset is established, including the field names, types, and meanings of the data tables. The aggregation results for each time window are transformed according to the predefined schema to generate the structured chargeback dataset. The transformed data is then stored in a data storage system, such as a relational database (MySQL, Oracle, etc.) or a distributed file system (HDFS, etc.).

[0077] In this embodiment, the combination of distributed message middleware and stream processing engine enables real-time reception and processing of chargeback event streams, ensuring data timeliness and accuracy. The distributed architecture design allows the system to easily handle large-scale business demands, and it can be scaled up by adding nodes as the number of payment channels and chargeback events increases.

[0078] In some embodiments, step S102 above, which involves parsing the chargeback description text and transaction document image through a multimodal parsing channel based on the structured chargeback dataset to obtain standardized chargeback classification codes and structured transaction evidence, specifically includes: In the text parsing channel, the chargeback description text is extracted from the structured chargeback dataset and input into the pre-trained language model. Semantic features are extracted through a multi-layer Transformer encoder to generate chargeback classification codes that conform to international payment standards. In the image analysis channel, transaction voucher images are extracted from the structured chargeback dataset and input into the target detection model to locate the bounding boxes of key information regions. Optical character recognition technology is then applied to extract the text content of the regions, forming structured transaction evidence. Establish a cross-channel collaborative verification mechanism. When the output of the text parsing channel indicates a specific type of non-payment, the image parsing channel will be automatically triggered to extract relevant evidence.

[0079] In this embodiment, the chargeback explanation text is accurately extracted from the structured chargeback dataset based on predefined field identifiers. A language model pre-trained on a large amount of text data, such as the BERT model based on the Transformer architecture, is selected. The extracted and processed chargeback explanation text is input into the pre-trained language model. During input, the text is segmented into word vector sequences that the model can understand, and necessary special markers (such as [CLS], [SEP], etc.) are added to meet the model's input requirements.

[0080] The pre-trained language model processes the input word vector sequence through a multi-layer Transformer encoder to extract semantic features of the text. The vector corresponding to the [CLS] tag in the last layer of the model contains the semantic information of the entire text and is used as the semantic representation of the text. Based on international payment standards, the categories for chargeback classification and their corresponding encoding rules are predefined. A classifier (such as a fully connected layer) is used to classify the semantic representation of the text, generating chargeback classification codes that conform to international payment standards. The generated chargeback classification codes are then validated to check whether they comply with the predefined encoding rules and format requirements.

[0081] From the structured chargeback dataset, transaction voucher images are extracted based on predefined field identifiers. A suitable object detection model, such as the YOLO series or Faster R-CNN, is selected. The transaction voucher images are input into the object detection model, which uses learned features to locate the bounding boxes of key information regions in the image. For example, in the transaction voucher image, the model locates the order number, transaction amount, transaction time, and merchant name regions. The object detection model outputs the bounding box coordinates for each key information region. For each key information region bounding box located by the object detection model, Optical Character Recognition (OCR) technology, such as the Tesseract OCR engine, is applied to recognize the text within the bounding box. The OCR engine converts the characters in the image into editable text. Post-processing is performed on the recognized text, such as removing extra spaces and correcting spelling errors, to improve the accuracy of the text. The text recognized from each key information region is organized according to a predefined structured format to form structured transaction evidence.

[0082] Based on business experience and international payment standards, we define judgment rules for specific chargeback types. For example, when the chargeback classification code indicates a chargeback type of "goods not as described," it is considered that this chargeback type requires supplementary verification with image evidence. These judgment rules are stored in the cross-channel collaborative verification module.

[0083] After the text parsing channel generates a chargeback classification code, the cross-channel collaborative verification module determines whether the chargeback type is a specific chargeback type based on predefined judgment rules. If it is a specific chargeback type, the image parsing channel is automatically triggered, requiring it to extract additional related evidence items relevant to that chargeback type.

[0084] The image analysis channel extracts relevant evidence items based on trigger requirements and integrates them with previously generated structured transaction evidence. The cross-channel collaborative verification module verifies the integrated evidence, checking the consistency and logic between the text and image evidence. For example, it checks whether the product issue described in the chargeback statement text matches the actual product shown in the image evidence. If the verification passes, the integrated evidence is stored in the data storage and management module; if the verification fails, an anomaly is recorded for subsequent manual review and processing.

[0085] In this embodiment, the multimodal parsing channel processes text and image information separately, fully leveraging the advantages of different modalities to comprehensively and accurately extract key information about chargeback events. The chargeback classification codes generated by the text parsing channel conform to international payment standards, facilitating data interaction and sharing with other payment institutions and systems. The cross-channel collaborative verification mechanism ensures consistency and logical coherence between text and image evidence, improving the reliability and accuracy of chargeback processing. The generated structured chargeback classification codes and structured transaction evidence are easy to store, manage, and retrieve, providing strong data support for subsequent chargeback appeals, risk assessments, and other operations.

[0086] In some embodiments, step S103 above, which involves concatenating the standardized chargeback classification code and structured transaction evidence into a dual prediction decision module for processing to obtain the order risk level and appeal success rate, specifically includes: The standardized chargeback classification code is combined with the structured transaction evidence to form a unified feature vector; A unified feature vector is input into the first-level prediction model, and a fraud risk score is calculated through the gradient boosting decision tree algorithm to generate a discrete order risk level. When the order risk level is low, the basic feature set is used; When the order risk level is medium or high, add transaction frequency characteristics or equipment risk characteristics respectively; Input the basic feature set or the feature set after adding features into the second-level prediction model, apply the regression algorithm based on ensemble learning, and output the predicted appeal success rate.

[0087] In this embodiment, key features are extracted from standardized chargeback classification codes. For example, chargeback classification codes are categorized according to their corresponding chargeback types, and the frequency or number of occurrences of each chargeback type is counted as a feature of that chargeback classification code. Simultaneously, considering the hierarchical relationship of the chargeback classification codes, the coding information at different levels is encoded and converted into numerical features. Different numerical identifiers are assigned to subcategories such as "Logistics information not updated" under the broad category of "Goods not received".

[0088] The various fields in structured transaction evidence are analyzed and their features extracted. For example, features such as the amount and trend of the amount can be extracted from the transaction amount field; features such as the time period and interval between transactions can be extracted from the transaction time field; and features such as the merchant's industry category and credit rating can be extracted from the merchant name field. For image evidence (such as product images), image processing techniques can be used to extract color features, texture features, etc.

[0089] Features extracted from standardized chargeback classification codes and those extracted from structured transaction evidence are concatenated. Features from different sources are arranged sequentially in a specific order to form a unified feature vector. For example, features from chargeback classification codes are arranged first, followed by features from structured transaction evidence such as transaction amount, transaction time, and merchant name. During the concatenation process, features are normalized to convert features with different dimensions to the same numerical range, preventing some features from having an excessively large value and thus unduly influencing the model.

[0090] A unified feature vector is input into the first-level prediction model, which employs the gradient boosting decision tree algorithm. The gradient boosting decision tree algorithm iteratively constructs multiple decision trees, each attempting to correct the errors of the previous tree, thereby gradually improving the model's prediction accuracy. During training, historical chargeback order data is used as the training set, with the actual risk level of the orders (e.g., low, medium, high) used as labels to train the model.

[0091] After training, the model calculates a fraud risk score on the input uniform feature vector. The fraud risk score is a continuous numerical value that reflects the likelihood of an order being fraudulent. A higher score indicates a greater likelihood of fraud.

[0092] Based on predefined thresholds, the fraud risk score is discretized into discrete order risk levels. For example, the threshold for low risk is set to [0, 30), the threshold for medium risk is [30, 70), and the threshold for high risk is [70, 100]. Different order risk levels are generated when the fraud risk score falls within different threshold ranges.

[0093] When the order risk level is low, a basic feature set is used. This basic feature set includes some common features that significantly impact risk assessment, such as transaction amount, transaction time, and merchant credit rating. These features can provide a preliminary assessment of order risk in most cases, and their calculations are relatively simple, improving the model's processing efficiency.

[0094] When the order risk level is medium, a transaction frequency feature is added to the basic feature set. The transaction frequency feature reflects the number of transactions a user makes within a certain period of time; a higher transaction frequency may indicate a risk of abnormal transaction behavior by the user. For example, the number of transactions a user makes in the past week can be counted and added as a new feature to the basic feature set, forming a feature set suitable for medium-risk orders.

[0095] When an order's risk level is high, device risk features are added to the basic feature set. Device risk features include information about the device used by the user, such as the device's IP address, model, and geographical location. Abnormal device information may indicate fraudulent activity; for example, multiple orders from different regions using the same IP address. Adding device risk features to the basic feature set allows for a more comprehensive assessment of the risk of high-risk orders.

[0096] The basic feature set, or the feature set with added features, is input into the second-level prediction model, which applies a regression algorithm based on ensemble learning. Ensemble learning improves the model's predictive performance and stability by combining multiple weak learners (such as decision tree regression models) to build a strong learner. During training, historical appeal data of rejected orders are used as the training set, and the actual appeal success rate of the orders is used as the label to train the model.

[0097] After training, the model calculates the appeal success rate prediction value on the input feature set. The predicted appeal success rate is a continuous value ranging from 0 to 1, representing the likelihood of a successful order appeal. The closer the predicted value is to 1, the greater the likelihood of a successful appeal; the closer the predicted value is to 0, the smaller the likelihood of a successful appeal.

[0098] In this embodiment, feature concatenation integrates features from different sources, fully utilizing information from chargeback classification codes and transaction evidence to improve the accuracy of risk assessment. Selecting different feature sets for appeal success rate prediction based on different order risk levels allows for more accurate assessment of appeal situations for orders with different risk levels, avoiding feature redundancy and wasted computational resources. Employing gradient boosting decision tree algorithms and ensemble learning-based regression algorithms effectively improves the model's predictive performance and stability, providing a reliable basis for payment institutions' risk management and decision-making.

[0099] Furthermore, the step of inputting the basic feature set or the feature set after adding features into the second-level prediction model, applying a regression algorithm based on ensemble learning, and outputting a predicted appeal success rate specifically includes: The feature verification gateway receives the basic feature set or the feature set after adding features, performs dimension matching verification, and automatically performs alignment and filling when missing features are found. The validated feature set is input into the pre-trained ensemble learning model, and the original prediction value is generated through forward propagation calculation of multi-level decision trees. The original predicted values ​​are transformed in probability space and mapped to the normalized interval using an S-shaped function to obtain the basic success rate prediction. Based on the internal tree structure of the ensemble learning model, the confidence interval of the prediction results is calculated simultaneously to quantify the uncertainty of the prediction. Combine the basic success rate prediction and confidence interval to output the appeal success rate prediction with reliability assessment.

[0100] In this embodiment, the feature verification gateway is responsible for receiving the basic feature set or the feature set with appended features. These feature sets may come from different data processing stages and may be affected by factors such as network fluctuations and data format conversions during transmission. The feature verification gateway ensures accurate reception of the feature set data through a standardized interface protocol.

[0101] The received feature set undergoes dimensionality matching verification. Pre-trained ensemble learning models use feature sets with specific dimensions and feature order during training; therefore, the input feature set must match these dimensions. The feature verification gateway checks whether the dimensions of the feature set match the model's expected dimensions and whether the positions of each feature are correct. For example, if the model expects a feature set of dimension [n], but the received feature set has a dimension of dimension [m] (m≠n), then a dimensionality mismatch is determined.

[0102] When missing features are detected, the feature validation gateway automatically performs alignment and imputation. For missing features, an appropriate imputation method is selected based on the feature type and business rules. For example, for numerical features, the mean, median, or mode of the feature in historical data can be used for imputation; for categorical features, the category with the highest frequency of the feature in historical data can be used for imputation. Through automatic alignment and imputation, it is ensured that the feature set can be successfully input into the pre-trained ensemble learning model.

[0103] The validated feature set is then input into a pre-trained ensemble learning model. This pre-trained ensemble learning model is a strong learner composed of multiple weak learners (such as decision trees) combined through ensemble learning. During training, the model has already learned the complex relationship between features and appeal success rates.

[0104] The multi-level decision trees in the model process the input feature set through forward propagation. Each decision tree branches based on the value of the feature set, starting from the root node and traversing down different branches until a leaf node is reached. Each leaf node corresponds to a predicted value. The predicted values ​​from multiple decision trees are combined in a certain way (such as weighted averaging) to generate the original predicted value. For example, assuming the ensemble learning model consists of 5 decision trees, and each decision tree generates a predicted value for the input feature set, namely 0.3, 0.4, 0.35, 0.45, and 0.38, then the original predicted value can be obtained by simple averaging: (0.3 + 0.4 + 0.35 + 0.45 + 0.38) / 5 = 0.376.

[0105] The original predicted value is usually a numerical value within a specific range, but to more intuitively represent the appeal success rate, it needs to be mapped to a normalized interval [0, 1]. The range and distribution of the original predicted value may be affected by the model training data and features, and may not directly correspond to the probability value.

[0106] A sigmoid function (such as the logistic function) is applied to the original predicted values ​​to perform a probability space transformation. The sigmoid function is monotonically increasing and ranges from [0, 1], mapping the original predicted values ​​to a normalized interval. For example, the expression for the logistic function is f(x) = 1 / (1 + e^(-x)), where x is the original predicted value. By substituting the original predicted value into the sigmoid function, the base success rate prediction is obtained. For example, if the original predicted value is 0.376, substituting it into the logistic function yields f(0.376) ≈ 0.593, meaning the base success rate prediction is approximately 59.3%.

[0107] The internal structure of an ensemble learning model consists of multi-level decision trees. Each decision tree contains rich information, such as feature split points and sample distributions in leaf nodes. By analyzing these tree structures, the uncertainty of the prediction results can be quantified.

[0108] Based on a tree structure, statistical methods are used to calculate the confidence interval of the prediction results. For example, for each decision tree, the distribution of appeal success rates of samples at its leaf nodes can be statistically analyzed. By calculating the statistics of these distributions (such as standard deviation, quantiles, etc.) and combining them with ensemble learning methods, the confidence interval of the prediction results is obtained. The confidence interval represents the range of uncertainty of the predicted value. For example, a calculated confidence interval of [0.5, 0.7] indicates that the predicted appeal success rate has a high probability of falling between 50% and 70%.

[0109] The baseline success rate forecast and confidence interval are combined. The baseline success rate forecast provides a point estimate of the appeal success rate, while the confidence interval provides the range of uncertainty for that estimate. By combining the two, a more comprehensive description of the appeal success rate forecast can be obtained.

[0110] The results output module outputs the combined results, namely, the predicted appeal success rate with reliability assessment. For example, the output format could be "The predicted appeal success rate is 59.3%, with a confidence interval of [50%, 70%]". Such output allows payment institutions to have a clearer understanding of the reliability of the predicted value, thereby making more reasonable decisions when formulating processing strategies.

[0111] In this embodiment, the feature set is received and verified through a feature verification gateway to ensure that the feature set input into the model is complete and accurate, avoiding prediction bias caused by missing or incorrect features. Employing an ensemble learning model and probability space transformation enables the generation of more accurate basic success rate predictions. Simultaneously, confidence intervals are calculated based on a tree structure to quantify prediction uncertainty, providing payment institutions with more comprehensive prediction information. The appeal success rate prediction with reliability assessment helps payment institutions better evaluate the appeal risk of orders and formulate reasonable handling strategies, such as prioritizing orders with high appeal success rates and allocating customer service resources, thereby improving the overall operational efficiency and customer satisfaction of payment institutions. The pre-trained ensemble learning model can adapt to feature sets of different types and sizes. Through automatic alignment and filling of feature sets and flexible model adjustments, it can handle various complex payment chargeback scenarios.

[0112] In some embodiments, step S104 above, which involves constructing an optimization model based on order risk level and appeal success rate, with appeal cost as a constraint and maximizing expected recovery amount as the objective function, to solve for the optimal appeal batch combination, specifically includes: Based on the order risk level and appeal success rate, calculate the unit cost recovery value of each order and generate a candidate order value list; Based on the preset budget constraints, construct a state space containing the remaining budget and pending orders, and initialize the dynamic programming solution matrix; Traverse the candidate order value list, perform value evaluation on each order by solving the matrix using dynamic programming, and obtain the solution result; Based on the solution results, a batch execution plan containing order priority and resource allocation weight is generated, and the batch execution cost is monitored in real time, and the resource allocation strategy for subsequent batches is dynamically adjusted.

[0113] In this embodiment, the order data processing module collects relevant information for each order from the payment system's database, including the order risk level, appeal success rate, expected recovery amount, and expected appeal cost. The order risk level reflects the likelihood of fraud in the order; the appeal success rate indicates the probability of a successful appeal; the expected recovery amount is the amount of funds that can be recovered if the appeal is successful; and the expected appeal cost is the resource investment required to process the appeal for that order.

[0114] Based on the collected order information, the unit cost recovery value for each order is calculated. Unit cost recovery value represents the amount recovered for every unit of cost invested, and is a key indicator for measuring the appeal value of an order. For example, for order A, the expected recovery amount is 1000 yuan, and the expected appeal cost is 200 yuan, then its unit cost recovery value is 1000 / 200 = 5 yuan / yuan; for order B, the expected recovery amount is 800 yuan, and the expected appeal cost is 300 yuan, then its unit cost recovery value is 800 / 300 ≈ 2.67 yuan / yuan.

[0115] The calculated unit cost recovery value of each order is sorted to generate a candidate order value list. Orders in the list are arranged in descending order of unit cost recovery value to prioritize higher-value orders during subsequent processing. Simultaneously, relevant information for each order is recorded, such as order number, risk level, appeal success rate, expected recovery amount, and expected appeal cost.

[0116] Payment institutions set a budget constraint for appeals based on their own resources and business needs. This budget constraint represents the maximum cost available for order appeals within a certain period. For example, the appeal budget might be set at 10,000 yuan.

[0117] Based on a preset budget constraint, a state space is constructed containing the remaining budget and pending orders. Each state in the state space represents the remaining budget amount and the set of unprocessed orders at a certain moment. For example, the initial state is a remaining budget of 10,000 yuan, and the set of pending orders is all orders in the candidate order value list.

[0118] Initialize the dynamic programming solution matrix. Rows in the matrix represent different remaining budget amounts, and columns represent different sets of orders to be processed. Each element in the matrix represents the maximum expected recovery amount achievable under the corresponding state. Initially, the elements in the matrix can be initialized according to certain rules. For example, when the remaining budget is 0, the maximum expected recovery amount is 0; when the set of orders to be processed is empty, the maximum expected recovery amount is also 0.

[0119] The optimization model building and solution module iterates through each order sequentially according to the candidate order value list. For each order, it considers adding it to the current processing batch and updates the state space.

[0120] A value assessment is performed on each order using a dynamic programming solution matrix. For the current order, assuming that adding it to the processing batch reduces the corresponding appeal cost of the remaining budget, the order is removed from the pending order set. Then, the maximum expected recovery amount corresponding to the updated state is found in the dynamic programming solution matrix and compared with the maximum expected recovery amount without adding the order. If adding the order results in a larger expected recovery amount, the corresponding element in the dynamic programming solution matrix is ​​updated, and the addition status of the order is recorded; otherwise, the original state remains unchanged.

[0121] After iterating through all candidate orders, the final element in the dynamic programming solution matrix represents the maximum expected recovery amount achievable under budget constraints, along with the corresponding order combination. Based on the recorded order inclusion status, the solution results can be generated, including the optimal appeal batch combination and the order information contained in each batch.

[0122] Based on the solution results, a batch execution plan is generated that includes order priority and resource allocation weights. Order priorities are determined according to their order within the optimal appeal batch combination, with higher-priority orders processed first. Simultaneously, based on the estimated appeal cost and estimated recovery amount for each order, corresponding resources, such as manpower and time, are allocated to each batch, forming resource allocation weights. For example, higher-priority orders are allocated more customer service personnel and more processing time.

[0123] The batch execution monitoring module monitors the execution cost of each batch in real time during the order appeal processing. By recording the actual human and material resources invested, it calculates the actual appeal cost and compares it with the estimated appeal cost.

[0124] If the execution cost of a batch is found to significantly exceed the expected cost, or if the remaining budget is insufficient to support the processing of subsequent batches, the batch execution monitoring module will dynamically adjust the resource allocation strategy for subsequent batches based on the actual situation. For example, for batches with cost overruns, the resource allocation for similar orders in subsequent batches can be appropriately reduced; if the remaining budget is tight, orders with high unit cost recovery value can be prioritized, while low-value orders can be suspended or delayed.

[0125] In this embodiment, by calculating the unit cost recovery value and constructing an optimization model, higher-value orders can be prioritized, maximizing the expected recovery amount within limited budget constraints and improving resource utilization efficiency. The application of dynamic programming algorithms makes the solution process more scientific and accurate, taking into account the combined effects of different orders to generate optimal appeal batch combinations and execution plans. Real-time monitoring of batch execution costs and dynamic adjustment of resource allocation strategies enable timely responses to various changes during processing, ensuring that appeal processing proceeds smoothly within budget and improving the payment institution's operational flexibility and risk response capabilities. By optimizing the order appeal batch combination, the payment institution's chargeback recovery success rate can be improved, reducing financial losses, while simultaneously enhancing customer satisfaction and strengthening the payment institution's market competitiveness.

[0126] In some embodiments, step S105 above, which involves dynamically rendering evidence materials based on the optimal appeal batch combination and according to the payment channel API specification, and submitting the appeal through an adaptive retry mechanism, specifically includes: According to the API specifications of the target payment channel, match the corresponding evidence template from the pre-built template library; Based on the optimal combination of appeal batches, the standardized evidence data of orders within the batch is dynamically populated into the evidence template to generate a channel-adapted evidence material package. Initiate the initial appeal submission via an encrypted transmission channel and simultaneously monitor the API response status; When a submission failure is detected, an adaptive retry strategy is triggered based on the error type analysis results. Continuously track changes in the appeal status until a final resolution is obtained.

[0127] In this embodiment, after determining the optimal batch combination of appeals, the payment channels involved in the orders within that batch are first identified. Payment institutions typically collaborate with multiple payment channels, each with its own specific identifier and API interface. By querying the payment channel field in the order information, the payment channel that needs to be processed is identified.

[0128] For the identified payment channels, obtain their API specification documents. These documents detail the payment channels' requirements for supporting documentation, including file formats (e.g., PDF, JPEG), field names, data types, and data length limits. Payment institutions typically have dedicated interface management teams responsible for maintaining and updating the API specification information for each payment channel.

[0129] The module matches the corresponding evidence template from a pre-built template library. This library stores pre-designed evidence templates for different payment channels and order types. The template matching module performs a precise search within the library based on the API specifications of the payment channel.

[0130] Based on the optimal batch combination of appeals, standardized evidence data of orders within each batch is extracted. The standardized evidence data is collected and organized in advance during the order processing, including basic order information (such as order number, transaction amount, transaction time, etc.), transaction vouchers (such as payment screenshots, bank statements, etc.), customer communication records (such as chat logs, email correspondence, etc.), etc.

[0131] The extracted standardized evidence data is dynamically populated into the matched evidence template. The template reserves corresponding field positions, and data binding technology is used to associate the standardized evidence data of the order with the fields in the template. For example, the order number is populated into the "Order Number" field in the template, and the transaction amount is populated into the "Transaction Amount" field. During the population process, necessary format conversions are performed on the data according to API specifications, such as converting the date format to the format required by the payment channel.

[0132] After data population is complete, a channel-adapted evidence package is generated. This package may contain multiple files, such as PDF documents or image-based transaction receipts. The system will package these files into a single, unified evidence package, naming and storing it according to the payment channel's requirements.

[0133] To ensure the security of appeal data, appeals are submitted via an encrypted transmission channel. A secure network connection is established between the payment institution and the payment channel, and the transmitted data is encrypted using encryption protocols such as SSL / TLS. Before submitting an appeal, the system automatically establishes an encrypted transmission channel to ensure that the data is not stolen or tampered with during transmission.

[0134] The generated evidence package is sent to the payment channel's API interface via an encrypted transmission channel. The appeal submission module constructs a request message according to the API specification, submitting the evidence package as a request parameter. During the submission process, information such as the submission time and request message content is recorded for subsequent tracking and troubleshooting.

[0135] Synchronously monitor API response status. Upon receiving an appeal request, the payment channel's API will return a corresponding response status code and information. The appeal submission module will receive and parse this response information in real time to determine whether the appeal submission was successful. For example, a returned status code of 200 indicates a successful submission; a returned status code of 400 or 500, or an error code, indicates a failed submission.

[0136] When a submission failure is detected, the error analysis module performs an in-depth analysis of the returned error information to determine the error type. Common error types include network connection errors, API timeouts, incorrect evidence formats, and missing data. The error analysis module categorizes and judges errors based on keywords and status codes in the error messages.

[0137] Based on the error type analysis results, an adaptive retry strategy is triggered. This strategy employs different retry methods depending on the error type. For example, if it's a network connection error, the system will automatically re-establish the encrypted transmission channel after a period of time and resubmit the appeal; if it's an incorrect format of the supporting documents, the system will prompt the user to modify the documents and resubmit; if it's an API timeout, the system will adjust the retry interval to avoid putting pressure on the payment channel system with frequent retries.

[0138] To avoid resource waste and system performance degradation caused by infinite retries, a retry limit is set. When the preset limit is reached, if the submission still fails, the system will stop retrying, record the failure information, and notify relevant personnel for manual handling.

[0139] The status tracking module establishes a connection with the payment channel's status query interface to continuously track changes in the appeal status. Payment channels typically provide a status query interface, allowing payment institutions to check the processing progress and results of appeals. The status tracking module periodically sends status query requests to the payment channel to obtain the latest appeal status information.

[0140] The system promptly updates the obtained appeal status information to the payment institution's internal system and notifies relevant personnel. For example, when the appeal status changes from "pending" to "processing," the system records the time of the status change and notifies customer service personnel via email, SMS, or other means. When the appeal status changes to "appeal successful" or "appeal failed," the system generates a corresponding processing result report for management personnel to review and analyze.

[0141] Depending on the final outcome, appropriate measures will be taken. If the appeal is successful, the payment institution will promptly credit the recovered funds to the account and update the customer's account information; if the appeal fails, the reasons for the failure will be analyzed to provide a reference for subsequent appeal processing.

[0142] In this embodiment, evidence templates are dynamically matched and evidence data is populated according to the API specifications of different payment channels. The generated evidence package fully complies with the requirements of the payment channels, improving the appeal success rate. Encrypted transmission channels and adaptive retry mechanisms ensure secure transmission and reliable submission of appeal data, reducing submission failures caused by network issues or payment channel malfunctions.

[0143] Reference Figure 2 An embodiment of the present invention provides a third-party payment chargeback intelligent appeal system 2, wherein the system 2 specifically includes: The first intelligent appeal module 201 is used to collect chargeback event streams from multiple payment channels in real time through a distributed message middleware, and to aggregate event time windows using a stream processing engine to output a structured chargeback dataset. The second intelligent appeal module 202 is used to parse the chargeback description text and transaction voucher image through a multimodal parsing channel based on the structured chargeback dataset to obtain standardized chargeback classification codes and structured transaction evidence; The third intelligent appeal module 203 is used to concatenate standardized chargeback classification codes and structured transaction evidence, and input them into the dual prediction decision module for processing to obtain the order risk level and appeal success rate. The fourth intelligent appeal module 204 is used to construct an optimization model based on the order risk level and appeal success rate, with appeal cost as the constraint and maximizing the expected recovery amount as the objective function, to solve for the optimal combination of appeal batches. The fifth intelligent appeal module 205 is used to dynamically render supporting materials according to the payment channel API specifications based on the optimal appeal batch combination, and submit the appeal through an adaptive retry mechanism.

[0144] It is understandable that, such as Figure 1 The content shown in the third-party payment chargeback smart appeal method embodiment is applicable to the third-party payment chargeback smart appeal system embodiment. The specific functions implemented by the third-party payment chargeback smart appeal system embodiment are as follows: Figure 1 The third-party payment chargeback smart appeal method shown is the same as the embodiment, and the beneficial effects achieved are the same as those described above. Figure 1 The beneficial effects achieved by the third-party payment chargeback smart appeal method embodiment shown are also the same.

[0145] It should be noted that the information interaction and execution process between the above systems are based on the same concept as the method embodiments of the present invention. For details on their specific functions and technical effects, please refer to the method embodiments section, which will not be repeated here.

[0146] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the system can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0147] Reference Figure 3 The present invention also provides a computer device 3, including: a memory 302 and a processor 301, and a computer program 303 stored on the memory 302. When the computer program 303 is executed on the processor 301, it implements the third-party payment chargeback smart appeal method as described in any of the above methods.

[0148] The computer device 3 may be a desktop computer, laptop, handheld computer, or cloud server, etc. The computer device 3 may include, but is not limited to, a processor 301 and a memory 302. Those skilled in the art will understand that... Figure 3 The computer device 3 is merely an example and does not constitute a limitation on the computer device 3. It may include more or fewer components than shown in the figure, or combine certain components, or different components, such as input / output devices, network access devices, etc.

[0149] The processor 301 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.

[0150] In some embodiments, the memory 302 may be an internal storage unit of the computer device 3, such as a hard disk or memory of the computer device 3. In other embodiments, the memory 302 may be an external storage device of the computer device 3, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 3. Furthermore, the memory 302 may include both internal and external storage units of the computer device 3. The memory 302 is used to store the operating system, applications, boot loader, data, and other programs, such as the program code of the computer program. The memory 302 can also be used to temporarily store data that has been output or will be output.

[0151] This invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the third-party payment chargeback intelligent appeal method as described in any of the above methods.

[0152] In this embodiment, if the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a photographing device / terminal device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0153] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0154] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0155] In the embodiments disclosed in this application, it should be understood that the disclosed devices / terminal equipment and methods can be implemented in other ways. For example, the device / terminal equipment embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling or direct coupling or communication connection may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0156] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

Claims

1. A smart appeal method for third-party payment chargebacks, characterized in that, The method specifically includes: The distributed message middleware collects chargeback event streams from multiple payment channels in real time, and uses a stream processing engine to aggregate event time windows, outputting a structured chargeback dataset. Based on the structured chargeback dataset, the chargeback description text and transaction voucher image are parsed through a multimodal parsing channel to obtain standardized chargeback classification codes and structured transaction evidence; The standardized chargeback classification code and structured transaction evidence are concatenated and input into the dual prediction decision module for processing to obtain the order risk level and appeal success rate; With appeal cost as a constraint and maximizing the expected amount recovered as the objective function, an optimization model is constructed based on the order risk level and appeal success rate to solve for the optimal combination of appeal batches. Based on the optimal combination of appeal batches, the evidence materials are dynamically rendered according to the payment channel API specifications, and the appeal is submitted through an adaptive retry mechanism.

2. The method according to claim 1, characterized in that, The process involves real-time collection of chargeback event streams from multiple payment channels using a distributed message middleware, and aggregation of event time windows using a stream processing engine to output a structured chargeback dataset. Specifically, this includes: Through the channel adapter layer of the distributed message middleware, raw chargeback event streams from multiple payment channels are received in real time. Each event in the raw chargeback event stream includes a merchant identifier, order number, and timestamp. The original chargeback event stream is input into the stream processing engine, and the event time window segmentation strategy is applied to aggregate the time dimension based on the sliding window mechanism. Within each defined time window, data cleaning and key field extraction operations are performed synchronously to obtain the window dataset; Perform multidimensional aggregation calculations on the window dataset, grouping and statistically analyzing the number of events, order list, and total amount by merchant and channel to obtain the aggregation results; Convert the aggregation results into a structured chargeback dataset with a pre-defined pattern.

3. The method according to claim 1, characterized in that, The structured chargeback dataset is used to parse the chargeback description text and transaction document images through a multimodal parsing channel to obtain standardized chargeback classification codes and structured transaction evidence, specifically including: In the text parsing channel, the chargeback description text is extracted from the structured chargeback dataset and input into the pre-trained language model. Semantic features are extracted through a multi-layer Transformer encoder to generate chargeback classification codes that conform to international payment standards. In the image analysis channel, transaction voucher images are extracted from the structured chargeback dataset and input into the target detection model to locate the bounding boxes of key information regions. Optical character recognition technology is then applied to extract the text content of the regions, forming structured transaction evidence. Establish a cross-channel collaborative verification mechanism. When the output of the text parsing channel indicates a specific type of non-payment, the image parsing channel will be automatically triggered to extract relevant evidence.

4. The method according to claim 1, characterized in that, The process of concatenating standardized chargeback classification codes and structured transaction evidence, and then inputting them into a dual-prediction decision module for processing to obtain the order risk level and appeal success rate, specifically includes: The standardized chargeback classification code is combined with the structured transaction evidence to form a unified feature vector; A unified feature vector is input into the first-level prediction model, and a fraud risk score is calculated through the gradient boosting decision tree algorithm to generate a discrete order risk level. When the order risk level is low, the basic feature set is used; When the order risk level is medium or high, add transaction frequency characteristics or equipment risk characteristics respectively; Input the basic feature set or the feature set after adding features into the second-level prediction model, apply the regression algorithm based on ensemble learning, and output the predicted appeal success rate.

5. The method according to claim 4, characterized in that, The process of inputting the basic feature set or the feature set with added features into the second-level prediction model, applying a regression algorithm based on ensemble learning, and outputting a predicted appeal success rate specifically includes: The feature verification gateway receives the basic feature set or the feature set after adding features, performs dimension matching verification, and automatically performs alignment and filling when missing features are found. The validated feature set is input into the pre-trained ensemble learning model, and the original prediction value is generated through forward propagation calculation of multi-level decision trees. The original predicted values ​​are transformed in probability space and mapped to the normalized interval using an S-shaped function to obtain the basic success rate prediction. Based on the internal tree structure of the ensemble learning model, the confidence interval of the prediction results is calculated simultaneously to quantify the uncertainty of the prediction. Combine the basic success rate prediction and confidence interval to output the appeal success rate prediction with reliability assessment.

6. The method according to claim 1, characterized in that, The optimization model, which uses appeal cost as a constraint and maximizing the expected recovery amount as the objective function, is constructed based on order risk level and appeal success rate to solve for the optimal combination of appeal batches. Specifically, it includes: Based on the order risk level and appeal success rate, calculate the unit cost recovery value of each order and generate a candidate order value list; Based on the preset budget constraints, construct a state space containing the remaining budget and pending orders, and initialize the dynamic programming solution matrix; Traverse the candidate order value list, perform value evaluation on each order by solving the matrix using dynamic programming, and obtain the solution result; Based on the solution results, a batch execution plan containing order priority and resource allocation weight is generated, and the batch execution cost is monitored in real time, and the resource allocation strategy for subsequent batches is dynamically adjusted.

7. The method according to any one of claims 1 to 6, characterized in that, The process of dynamically rendering supporting evidence materials according to the payment channel API specifications based on the optimal appeal batch combination and submitting the appeal through an adaptive retry mechanism specifically includes: According to the API specifications of the target payment channel, match the corresponding evidence template from the pre-built template library; Based on the optimal combination of appeal batches, the standardized evidence data of orders within the batch is dynamically populated into the evidence template to generate a channel-adapted evidence material package. Initiate the initial appeal submission via an encrypted transmission channel and simultaneously monitor the API response status; When a submission failure is detected, an adaptive retry strategy is triggered based on the error type analysis results. Continuously track changes in the appeal status until a final resolution is obtained.

8. A third-party payment chargeback intelligent appeal system, characterized in that, The system specifically includes: The first intelligent appeal module is used to collect chargeback event streams from multiple payment channels in real time through a distributed message middleware, and to aggregate event time windows using a stream processing engine to output a structured chargeback dataset. The second intelligent appeal module is used to parse the chargeback description text and transaction voucher image through a multimodal parsing channel based on the structured chargeback dataset to obtain standardized chargeback classification codes and structured transaction evidence; The third intelligent appeal module is used to concatenate standardized chargeback classification codes and structured transaction evidence, and input them into the dual prediction decision module for processing to obtain the order risk level and appeal success rate. The fourth intelligent appeal module is used to construct an optimization model based on the order risk level and appeal success rate, with appeal cost as the constraint and maximizing the expected recovery amount as the objective function, to solve for the optimal combination of appeal batches. The fifth intelligent appeal module is used to dynamically render supporting materials according to the payment channel API specifications based on the optimal appeal batch combination, and submit the appeal through an adaptive retry mechanism.

9. A computer device, characterized in that, include: The memory and processor, and the computer program stored in the memory, which, when executed on the processor, implement the third-party payment chargeback smart appeal method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, It stores a computer program, which, when executed by a processor, implements the third-party payment chargeback intelligent appeal method as described in any one of claims 1 to 7.

Images