Method, medium, apparatus, and program product for generating a protest document

Abstract

The specification provides a method, medium, device and program product for generating a protest document, automatically collecting evidence through a robot process, automatically arranging a protest document through a protest model, arranging a protest document based on a document generation rule corresponding to a payment service provider, and automatically submitting the arranged protest document to a payment institution through an application programming interface, realizing an automated end-to-end protest process from evidence collection, protest statement generation, and protest document generation and submission, reducing the operation complexity in the generation process of the protest document, and improving the protest efficiency.

Description

Technical Field

[0001] This specification relates to one or more embodiments in the field of computer technology, and more particularly to a method, medium, apparatus, and program product for generating a non-payment defense document. Background Technology

[0002] In e-commerce scenarios, buyers may initiate chargebacks on completed transactions due to reasons such as non-receipt of goods, damaged goods, or goods not matching the description, i.e., raising objections to the payment service provider and requesting a refund. To respond to such chargebacks, merchants need to submit evidence such as logistics vouchers, transaction records, and product information to the payment service provider to prove the legality and compliance of their transactions and strive for a refund. However, in related technologies, when initiating chargeback defenses, merchants need to manually collect and organize evidence such as logistics screenshots and shipping documents from different channels (such as logistics companies and e-commerce platforms), then draft defense statements according to the requirements of the payment service provider, and finally compile the evidence and defense statements into a defense document that meets the requirements of the payment service provider and manually submit it to the payment service provider. It is evident that the traditional chargeback defense document generation process is highly complex and inefficient. Summary of the Invention

[0003] In view of the above, one or more embodiments of this specification provide the following technical solutions: According to a first aspect of one or more embodiments of this specification, a method for generating a non-payment defense document is provided, the method comprising: Upon detecting a chargeback event against a target order, a robotic process is triggered. This robotic process uses a programmable browser to automate the process by accessing a designated source of evidence based on the unique identifier of the target order, in order to obtain the evidence required to defend against the chargeback event from the designated source of evidence. The target reason for non-payment and the evidence obtained are input into the non-payment defense model generated after multi-stage fine-tuning, and the structured defense statement output by the non-payment defense model is obtained; wherein, the multi-stage fine-tuning includes: a first-stage fine-tuning based on sample defense statements of the winning defense, and a second-stage fine-tuning based on sample pairs composed of sample defense statements of the winning defense and sample defense statements of the losing defense; According to the document generation rules of the payment service provider, the structured defense arguments and the evidence are integrated and arranged to generate a defense document, which is then submitted to the payment service provider through the application programming interface.

[0004] According to a second aspect of one or more embodiments of this specification, an electronic device is provided, comprising: a processor; a memory for storing processor-executable instructions; wherein the processor implements the steps of the method described in the first aspect of one or more embodiments of this specification by executing the executable instructions.

[0005] According to a third aspect of one or more embodiments of this specification, a computer-readable storage medium is provided that stores computer instructions thereon, which, when executed by a processor, implement the steps of the method described in the first aspect of one or more embodiments of this specification.

[0006] According to a fourth aspect of one or more embodiments of this specification, a computer program product is provided, comprising a computer program / instructions that, when executed by a processor, implement the steps of the method described in the first aspect of one or more embodiments of this specification.

[0007] The method for generating non-payment defense documents in this specification automatically triggers a programmable browser-based automated robot process to obtain the necessary evidence for the non-payment defense from a designated evidence source after detecting a non-payment event, solving the problem of time-consuming and labor-intensive manual collection. Furthermore, the reasons for non-payment and the evidence are input into a multi-stage fine-tuned non-payment defense model. This model first undergoes a first-stage fine-tuning using successful defense arguments, enabling it to learn the language style and logical structure of high-quality arguments, thereby generating a basic text that conforms to professional standards and is persuasive. Then, a second-stage fine-tuning is performed using sample pairs consisting of successful and unsuccessful defense arguments, guiding the model to distinguish and avoid negative features that lead to defeat, thus improving the win rate. The model generated after these two stages of fine-tuning can automatically generate persuasive defense arguments. Next, based on the document generation rules of the payment service provider, the structured defense arguments and evidence are integrated and arranged to generate a defense document, which is then automatically submitted to the payment service provider through the application programming interface. This achieves an automated end-to-end chargeback defense process, from evidence collection and defense argument generation to the generation and submission of the defense document, reducing the operational complexity in the chargeback defense document generation process and improving the efficiency of chargeback defense. Attached Figure Description

[0008] Figure 1 This is a schematic diagram illustrating an application scenario provided by an exemplary embodiment.

[0009] Figure 2 This is a flowchart of a method for generating a non-payment defense document, provided in an exemplary embodiment.

[0010] Figure 3 This is a schematic diagram of a two-stage fine-tuning process provided in an exemplary embodiment.

[0011] Figure 4 This is a schematic diagram of a system architecture provided in an exemplary embodiment.

[0012] Figure 5 This is a schematic diagram of the structure of a device provided in an exemplary embodiment. Detailed Implementation

[0013] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0014] Figure 1 This is a flowchart illustrating an application scenario of an embodiment of this specification. The application scenario includes issuing banks, card organizations, acquiring banks, and e-commerce platforms. Issuing banks are financial institutions that issue payment cards to buyers and are responsible for processing buyers' payment accounts; card organizations (such as Visa and Mastercard) act as clearing networks, connecting issuing and acquiring banks, setting transaction rules, and handling interbank clearing; acquiring banks are financial institutions that provide payment collection services to merchants and are responsible for managing merchants' settlement accounts; e-commerce platforms act as transaction matchmakers, providing product display, order management, and transaction records; and merchants are the providers of goods or services. All participating parties form a closed-loop transaction chain with the e-commerce platform through the payment network.

[0015] In the specific chargeback defense process, a buyer can initiate a chargeback when they believe a transaction is disputed. Specifically, the buyer first submits a chargeback request to the issuing bank. After review, the issuing bank forwards the request to the card network. The card network then notifies the acquiring bank through its clearing network. The acquiring bank immediately freezes the merchant's relevant account assets and notifies the e-commerce platform. The e-commerce platform simultaneously informs the merchant of the transaction dispute. Upon receiving the notification, the merchant must collect evidence such as order details, logistics vouchers, and communication records, compile a defense statement, generate a standardized defense document, and submit it to the acquiring bank. The acquiring bank forwards the defense materials to the issuing bank through the card network for final review. If the review is successful, the assets will be unfrozen and returned to the merchant's account; if the review fails, the assets will be transferred to the buyer's account to resolve the dispute.

[0016] Understandable. Figure 1The application scenarios illustrated are merely illustrative and not intended to limit this specification. For example, in other embodiments, the chargeback defense process is also applicable to payment systems built by third-party payment institutions (such as payment gateways and digital wallet service providers) and e-commerce platforms, without relying on traditional bank issuing banks, acquiring banks, and card organization networks. Therefore, the scope of this specification aims to cover various application scenarios of defenses based on transaction dispute handling and evidence submission.

[0017] In the aforementioned process, merchants need to manually perform operations such as evidence collection and organization, drafting of defense statements, and preparation and submission of defense documents, which is highly complex and inefficient. Therefore, this specification provides a method for generating a chargeback defense document. This method automatically collects evidence through a robotic process, automatically organizes the defense document using a chargeback defense model, arranges the defense document based on the document generation rules corresponding to the payment service provider, and automatically submits the arranged defense document to the payment institution through an application programming interface. This achieves an automated end-to-end chargeback defense process from evidence collection, defense statement generation, to defense document generation and submission, reducing the operational complexity of the chargeback defense document generation process and improving the efficiency of chargeback defense. The specific implementation details of this specification embodiment are illustrated below with reference to the accompanying drawings.

[0018] See Figure 2 This specification provides an embodiment of a method for generating a non-payment defense document, the method comprising: Step S12: Upon detecting a chargeback event against the target order, a robot process is triggered. This robot process uses a programmable browser to automate the process by accessing a designated source of evidence based on the unique identifier of the target order, in order to obtain the evidence required to defend against the chargeback event from the designated source of evidence. Step S14: Input the target reason for non-payment and the evidence obtained into the non-payment defense model generated after multi-stage fine-tuning, and obtain the structured defense statement output by the non-payment defense model; wherein, the multi-stage fine-tuning includes: the first stage fine-tuning based on the sample defense statement of the defense success, and the second stage fine-tuning based on the sample pairs composed of the sample defense statement of the defense success and the sample defense statement of the defense failure; Step S16: Based on the document generation rules of the payment service provider, integrate and arrange the structured defense arguments and evidence to generate a defense document, and submit the defense document to the payment service provider through the application programming interface.

[0019] The methods described in this specification can be applied to e-commerce platforms. In one embodiment, the method can be automatically executed by the e-commerce platform upon triggering a specific event (such as detecting a chargeback event), generating and submitting a defense document without any human intervention. In another embodiment, the e-commerce platform can collaborate with the merchant; for example, the merchant can determine whether a defense document needs to be generated, or the merchant can confirm the generated defense statement and / or defense document before proceeding with subsequent operations.

[0020] In step S12, the e-commerce platform can detect chargeback events for target orders. Target orders can include all orders on the e-commerce platform, or orders that meet specific conditions, such as transaction amounts falling within a preset threshold range or product types belonging to a preset category set.

[0021] When an e-commerce platform receives a chargeback event against a target order, it can trigger a robotic process to automatically obtain the evidence needed for a chargeback defense. This evidence includes, but is not limited to, logistics documents, transaction records, chat logs, payment screenshots, product inspection reports, customs clearance documents, proof of delivery (POD), proof of return address, and / or logistics tracking screenshots. A robotic process is an automated program that uses software technology to simulate human actions on a computing device, automatically executing repetitive and rule-based tasks. It can complete interactive actions such as clicking, inputting, and reading based on preset logic. In some embodiments, the robotic process can be of the type Robotic Process Automation (RPA) or Playwright. When obtaining evidence, RPA can simulate manual operations such as logging into the evidence source, entering the order number, clicking the query button, and downloading evidence based on the unique identifier of the target order. Playwright, on the other hand, can automatically construct the evidence source URL based on the unique identifier of the target order through a programmable browser, automatically access the evidence source, and accurately extract the content of the evidence source as the evidence needed for a chargeback defense.

[0022] Taking evidence including logistics documents as an example, the evidence source includes the official website of the logistics platform. After the buyer initiates a chargeback application with the issuing bank, the issuing bank can forward the chargeback notice to the acquiring bank through the card network. The acquiring bank then synchronizes the chargeback notice, which includes the transaction tracking number, to the e-commerce platform. Upon receiving the chargeback notice, the e-commerce platform can locate the unique identifier information (such as the order number) of the order corresponding to the transaction in the order management system based on the transaction tracking number. Then, it triggers a robot process to automatically log in to the logistics platform's official website. By parsing the characteristics of web page elements, intelligently matching element identifiers (such as ID, XPath, or text content), and adapting to dynamic loading, it accurately locates the logistics query entry point, inputs the unique identifier information of the target order, and automatically triggers the query logic. After the official website returns the query results, logistics documents (such as proof of receipt, transit records, etc.) can be obtained through screenshots or download interfaces, and the logistics documents are returned to the e-commerce platform. The entire process requires no manual intervention, achieving efficient and accurate evidence collection.

[0023] In some embodiments, changes in the page layout of the evidence source, adjustments to the dynamic loading mechanism, permission restrictions, or temporary data unavailability may prevent the automatic retrieval of required evidence from the specified evidence source. In such scenarios, if the target evidence cannot be successfully obtained from the specified evidence source, a failure analysis mechanism can be initiated. First, the sequence of operations performed on the specified evidence source is obtained, including timestamps, coordinates, and triggering events for user interactions such as clicking, scrolling, text input, and selecting dropdown menus. Simultaneously, a webpage snapshot and the Document Object Model (DOM) structure at the moment of each operation are acquired. The webpage snapshot captures the static rendered image of the current page, fully preserving the visual element layout and text information; while the webpage DOM structure parses and records the HTML tag hierarchy, element attributes, and node relationships in a tree-like format, accurately reflecting the underlying code architecture of the page. Subsequently, the above operation sequence data, webpage snapshots, and webpage DOM structure are input into a multimodal language model for screenshot failure analysis. This multimodal language model uses cross-modal alignment technology to map operation sequences to changes in web page elements within the DOM structure, obtaining the correspondence between each operation in the sequence and the changes in web page elements. Based on this correspondence, it identifies the key steps the user is attempting to obtain evidence. A computer vision module analyzes the position and state of visual elements in the web page snapshot, and then fuses the obtained visual information with the semantic information of the web page DOM structure. Based on the fused visual and semantic information, it determines the reason for the screenshot failure. For example, the target element might not be rendered due to asynchronous page loading, CSS style changes might cause the web page element to be hidden, the user's operation might not trigger the correct event, or the evidence source might have added anti-crawler verification mechanisms. The multimodal language model can generate a structured analysis report based on the analysis results, pointing out the root cause of the screenshot failure (such as "target data container not loaded" or "element dynamically masked"), and providing natural language explanations and correction suggestions.

[0024] Specifically, a multimodal language model can temporally associate each operation in an operation sequence (such as clicking a button with the ID btn_detail) with a changed element node in the webpage's DOM structure. For example, if the operation sequence records that a user clicked the "View Details" link at timestamp T1, the multimodal language model can automatically compare the webpage snapshots before and after the operation to identify nodes that were added, deleted, or had their attributes changed. Through this cross-modal alignment, the multimodal language model can generate a correspondence between operations and changes in webpage elements, thereby identifying the key steps the user attempted to take to obtain evidence. For example, the multimodal language model can determine that the user's intention was to wait for the details area to load after clicking "View Details" and then capture evidence of that area. If the screenshot fails at this step, the multimodal language model can focus on the DOM change event corresponding to that operation as the key object of failure analysis.

[0025] Then, the multimodal language model can invoke a built-in computer vision module, which can parse the position and state of visual elements in previously saved webpage snapshots based on convolutional neural networks (such as ResNet or ViT). For example, the vision module can detect whether there is a loading rotating icon, a gray overlay, or a semi-transparent pop-up covering the target evidence area on the page, and can locate the bounding box coordinates and visibility state of these visual elements. In addition, the multimodal language model can extract semantic information of the webpage DOM structure at the corresponding time, including but not limited to the text content of elements (such as data loading failed, please retry), role attributes (such as warnings, dialog boxes), accessibility labels, and states implied by CSS class names (such as errors, timeouts). The multimodal language model can perform multimodal fusion of the visual parsing results (such as an error message box marked with a red border) and DOM semantic information (the div node corresponding to the error message box contains the text "request timeout"), and the fusion methods include but are not limited to using cross-attention mechanisms or feature concatenation before inputting into the joint inference layer. Based on the fused visual and semantic features, the multimodal language model can pinpoint the specific reasons that may lead to screenshot failure. For example: "After step 3 in the operation sequence (clicking the 'Get Electronic Receipt' button), a hidden receipt container is added to the page DOM structure, but its parent node is invisible due to the CSS property 'display:none'; at the same time, this area appears as a gray block in the webpage snapshot, and the visual module does not detect the receipt text. It is determined that although the DOM node has been created, it has not been successfully rendered. It is speculated that the asynchronous request timed out, resulting in data not being filled. It is recommended to add explicit waiting and re-trigger data loading." Based on this analysis result, the retry strategy can be automatically adjusted (e.g., extending the waiting time, refreshing the page, or switching alternative evidence sources), thereby improving the robustness and automation of the non-payment defense document generation process.

[0026] In some embodiments, situations such as abnormal evidence sources, access restrictions, or missing data may occur, making it impossible to obtain evidence from the specified evidence source. In such cases, users can be guided to manually upload supporting materials, and key fields in the supporting materials, such as tracking number, shipping time, receipt time, and recipient, can be parsed. Then, a pre-defined evidence generation template is invoked, and the key fields are filled into the template to generate evidence. By invoking the evidence generation template, unstructured or heterogeneous raw information uploaded by users can be transformed into structured evidence that conforms to industry norms and standards after semantic parsing, key field extraction, and mapping. This template can have built-in preset data organization logic and verification mechanisms, which can parse the raw supporting materials provided by users (such as fragmented text, images, or log fragments), and integrate discrete information into a standardized framework defined by the template through automated field matching and standardized conversion, ensuring that the generated evidence has a uniform format.

[0027] In some embodiments, evidence requirement configuration information can be pre-generated to define the mapping relationship between chargeback reasons and the required set of evidence. This evidence requirement configuration information can be a multi-dimensional matrix, which may include the type of payment service provider, the chargeback reason, and the type of evidence. Furthermore, the evidence requirement configuration information may also include the degree of necessity of evidence, such as required evidence and optional evidence, where required evidence refers to evidence that must be provided, and optional evidence refers to evidence that can be provided or not. Further, the degree of necessity of evidence may also include recommended evidence. In the example where the payment service provider is Visa, for the chargeback reason of "goods not received," required evidence includes the tracking number and status certificate, shipping date record, and proof that the product description matches the order; recommended evidence includes buyer's signature record, delivery address confirmation, and customer service communication records.

[0028] The aforementioned matrix can be stored in a structured manner in the knowledge graph. Whenever the card organization updates its rules, it only needs to update the corresponding matrix entries without modifying the code logic.

[0029] After obtaining evidence from the evidence source, the target evidence set corresponding to the target reason for non-payment can be obtained based on the mapping relationship between the non-payment reason and the evidence set in the evidence requirement configuration information. If the evidence obtained from the specified data source covers the target evidence set, that is, all the evidence in the target evidence set (which may refer to all the evidence in the target evidence set or all the required evidence) is included in the evidence obtained from the specified data source, then the target reason for non-payment and the obtained evidence are input into the non-payment defense model generated after multi-stage fine-tuning. In this embodiment, before generating the non-payment statement through the non-payment defense model, the completeness of the evidence is first judged. Only when all the required evidence has been obtained (i.e., the evidence is complete) is the non-payment statement generated through the non-payment defense model, thereby reducing the problem of low defense success rate due to insufficient evidence.

[0030] Furthermore, if the evidence obtained from the designated data source does not cover the target evidence set, the initial scores of necessary and optional evidence obtained from the designated data source can be weighted and summed based on preset weights to obtain an evidence completeness score. To reflect the difference in the criticality of different pieces of evidence for winning the case, the preset weight of necessary evidence is configured to be significantly greater than the preset weight of optional evidence (for example, the weight of necessary evidence can be set to 0.8, and the weight of optional evidence to 0.2; or the weight of necessary evidence can be set to 0.7, and the weight of optional evidence to 0.3). If the evidence completeness score is lower than the preset score (e.g., lower than 0.7), the missing evidence is identified, and the missing evidence is obtained from the corresponding evidence source according to the mapping relationship between evidence and evidence source recorded in the evidence requirement configuration information. For example, in a chargeback event where the reason for the chargeback is "the cardholder did not receive the goods," the logistics receipt is necessary evidence, and its absence has a significant impact on the completeness score, while the customer service communication record is optional evidence, and its absence has a smaller impact on the completeness score. When it is detected that the completeness score is below standard due to missing logistics receipts, a query request can be automatically initiated to the query interface of the logistics platform's official website based on the mapping relationship "logistics receipt - logistics platform official website" to supplement and obtain the evidence.

[0031] Furthermore, if the evidence obtained from the specified data source does not cover the target evidence set, an evidence missing report can be generated. This report lists the currently obtained evidence, the missing evidence, and the estimated impact of the missing evidence on the success rate of the argument, for reference by operations personnel or merchants. Specifically, the evidence completeness score and the type of required evidence can be input into the prediction model to predict the estimated impact of the missing evidence on the success rate of the argument.

[0032] In some embodiments, the acquired evidence includes one or more pieces of evidence. If the acquired evidence includes multiple pieces of evidence, in order to ensure the logical consistency of the evidence chain, conflict detection is required. This involves identifying whether there are direct contradictions (such as "shipped" versus "goods lost"), partial contradictions, or inconsistencies such as timeline breaks, through methods such as semantic contradiction rules and timeline consistency checks. Specifically, the evidence type of each piece of evidence can first be determined. If multiple pieces of evidence of the same type exist, conflict detection is performed on these multiple pieces of evidence of the same type. Evidence of the same type refers to a set of evidence used to prove the same factual claim. If a conflict is detected, the priority of the multiple pieces of evidence of the same type is determined.

[0033] When determining the priority of similar pieces of evidence, a timeliness score, a completeness score, and a reliability score can be assigned to multiple pieces of similar evidence. The timeliness, completeness, and reliability scores for each piece of similar evidence are then weighted and summed to obtain a comprehensive score for that piece of evidence. The priority of these multiple pieces of similar evidence is then determined based on their comprehensive scores. Specifically, the timeliness score indicates the proximity of the time period in which the evidence was produced to the time of the dispute; the greater the proximity, the higher the timeliness score. The completeness score reflects the completeness of the evidence; the greater the completeness, the higher the completeness score. The reliability score reflects the reliability of the evidence, encompassing three dimensions: probative value (direct proof against the defense's claims), source credibility (the neutrality and authority of the provider), and immutability (anti-forgery capability). The stronger the probative value, the higher the source credibility, and the higher the immutability, the higher the reliability score.

[0034] Several dimensions of some embodiments are shown in the table below: Then, the highest priority evidence can be selected from multiple pieces of similar evidence. For example, when both the merchant's "shipping certificate" and the logistics platform's "lost goods record" are obtained simultaneously, a direct contradiction in the logistics status is detected. After calculation, the logistics platform's "lost goods record" has a higher overall score than the merchant's own shipping certificate because it has higher source credibility (third-party platform) and timeliness. Therefore, the system selects the "lost goods record" as valid evidence and determines the attribution of responsibility accordingly to adjust the defense strategy.

[0035] In step S14, the target reasons for nonpayment and the evidence obtained can be input into the nonpayment defense model generated after multi-stage fine-tuning, and the structured defense statement output by the nonpayment defense model can be obtained. In order to improve the quality of the defense statement output by the model and guide the model to understand the characteristics of the winning defense statement, a two-stage approach can be used to generate the nonpayment defense model.

[0036] See Figure 3 In the first stage of fine-tuning the non-payment defense model, a large number of labeled sample defense statements from successful defenses are input as training data, based on a pre-trained general language model. After receiving each sample, the model generates a corresponding predicted defense statement. Subsequently, the semantic and structural deviations between the predicted defense statement and the successful sample defense statements are quantified by calculating the textual differences (e.g., using cross-entropy loss or sequence loss functions). Based on this loss function, the model parameters are adjusted layer by layer using backpropagation, gradually bringing the prediction results closer to the successful sample defense statements. This process can be iteratively optimized through multiple rounds until the model reaches a preset convergence criterion on the validation set (e.g., the loss function value is below a threshold or the generation quality meets the standard). This first stage of fine-tuning can be called supervised fine-tuning. After fine-tuning, the model can accurately capture the key elements of the successful sample defense statements (such as logical structure, legal basis, and evidence citation norms), thereby generating logically rigorous, legally grounded, and evidence-compliant structured defense statements for new non-payment events.

[0037] In the second-stage fine-tuning of the non-payment defense model, the supervised fine-tuned model is first used as the base, with input consisting of sample pairs of winning and losing defense arguments. For each non-payment event, the model can generate predicted defense arguments for both winning and losing samples. Subsequently, the preference signal of the model's generated winning arguments relative to losing arguments is quantified using a preference loss function (such as log probability difference), that is, maximizing the model's preference strength for winning defense arguments and minimizing the model's preference strength for losing defense arguments. Based on the above preference signal, the model parameters are updated using a policy gradient method (such as PPO), so that the model tends to output structured arguments that match the features of winning defense arguments in subsequent generation. This process can be iterated over multiple rounds, dynamically adjusting the model weights until the model's generation probability of winning defense arguments on the validation set is significantly better than that of losing defense arguments. This second-stage fine-tuning can be called preference optimization.

[0038] In some embodiments, the risk level of the non-payment event can be determined before generating a defense statement using the non-payment defense model. Only if the determined risk level is one that requires a defense is the target reason for non-payment and the evidence obtained input into the non-payment defense model to generate a defense statement. Otherwise, the process ends. The risk level of the non-payment event can be determined based on the following: First, it's possible to obtain the buyer's intent characteristics in chargeback events, including but not limited to the buyer's historical behavioral characteristics, the target order's transaction characteristics, the target order's interactive behavior characteristics, and / or associated network characteristics. The buyer's historical behavioral characteristics include the number and frequency of historical chargebacks (e.g., the number of chargebacks in the past 6 / 12 months), the proportion of chargeback amount to total transaction amount, historical refund success rate, the frequency distribution of disputes with different merchants, account duration and activity, etc. The target order's transaction characteristics include the transaction amount and its deviation from the buyer's historical average transaction amount, the time interval between order placement and chargeback, the product category (which can be physical goods, virtual goods, or services), the payment verification method, and whether the same shipping address and device as in the historical records were used, etc. The target order's interactive behavior characteristics include whether the buyer communicated with the merchant before the chargeback, the content and tone of the communication (e.g., whether a reasonable refund request was rejected), whether a refund application was initiated through the platform's customer service channels, and the timing of the chargeback (whether it occurred after the service was completed), etc. The associated network characteristics include information such as device fingerprints, IP addresses, and delivery addresses. This information can be used to identify whether there is a pattern of multiple accounts associated with the same natural person (a fraud pattern of one person having multiple accounts); and whether there are known fraud network associations.

[0039] Then, buyer intent characteristics can be input into a pre-defined rule engine for matching to determine the risk level of chargeback events. The rule engine can use deterministic rules for risk assessment. For example: if a buyer's number of chargebacks exceeds a pre-defined threshold within a historical period, it can be marked as high-risk fraud; if the transaction has been verified using 3DS 2.0 and the cardholder has passed biometric authentication, the issuing bank assumes liability shift, and the merchant does not need to raise a chargeback defense; for cases where refunds have been processed, refund vouchers can be submitted for a chargeback defense. The rule engine processes quickly and provides definitive results, filtering out some chargeback events that do not require a defense.

[0040] If a match fails, the features of the chargeback event can be input into a pre-trained classification model to determine the risk level of the chargeback event. The classification model can be a gradient boosting tree model (such as XGBoost or LightGBM), which performs well in handling structured features, has strong interpretability, and fast inference speed. The classification model can output a probability distribution of the buyer's intent, for example: 75% probability of malicious fraud, 20% probability of bona fide dispute, and 5% probability of a reasonable refund.

[0041] The above solution constructs a two-layer decision-making architecture, combining the deterministic matching of the rule engine with the intelligent inference of the classification model. It can accurately determine the risk level of chargeback events based on multi-dimensional buyer intent characteristics, taking into account both processing efficiency and adaptability to complex scenarios.

[0042] In some embodiments, the risk levels of chargeback events are classified as follows: If the determined risk level is A or B, the risk level of the non-payment event can be determined as a risk level that requires defense; if the determined risk level is C or D, the risk level of the non-payment event can be determined as a risk level that does not require defense.

[0043] In some embodiments, a graph structure can also be used to organize the evidence and related information involved in the chargeback defense process. Specifically, the graph structure can be used to establish the relationship between order characteristics, chargeback reasons, historical chargeback events, and chargeback defense results (used to characterize successful or unsuccessful defenses). Based on the graph structure, after a chargeback event is detected, the chargeback reason of the chargeback event and the order characteristics of the target order can be extracted. Reference order characteristics matching the extracted order characteristics and reference chargeback reasons matching the extracted chargeback reasons can be retrieved from the graph structure. Historical chargeback events associated with the reference order characteristics and reference chargeback reasons that have been successfully defended can be identified. The defense statement generation template used when defending historical chargeback events, the target chargeback reason of the chargeback event, and the obtained evidence are input into the chargeback defense model generated after multi-stage fine-tuning. The structured defense statement output by the chargeback defense model, which follows the format requirements of the defense statement generation template, is obtained.

[0044] In step S16, the structured defense arguments and evidence can be integrated and arranged according to the document generation rules of the payment service provider to generate a defense document.

[0045] The document generation rules corresponding to the payment service provider refer to the standardized specifications for structuring defense materials in accordance with relevant laws, regulations, and platform requirements. These rules clarify the format, content elements, evidence organization methods, and submission technical requirements of the defense documents, ensuring their legality, completeness, and verifiability. For example, a unified document format must be used, including pre-defined metadata fields; structured defense statements must be arranged hierarchically according to the points of contention; evidence must correspond one-to-one with the claims in the defense statements; and compliant electronic signatures and timestamps must be attached.

[0046] Integrated arrangement refers to the organization of structured defense arguments and evidentiary materials. For example, a mixed text and image format can be used, embedding defense arguments and key evidence screenshots (such as transaction vouchers and communication records) into the same document, allowing for quick location of evidence and defense argument clauses via hyperlinks or anchors. Alternatively, the arrangement can be divided into chapters based on points of contention: each chapter first lists the defense claims, followed by a corresponding list of evidence and explanations, with evidence numbers consistent with their citation positions in the defense arguments. If the evidence includes non-text files such as audio or video, it can be converted to a format supported by the e-commerce platform and linked as an attachment, with an attachment index marked in the main document.

[0047] The generated defense document can include the following: document title (e.g., "Defense Statement Regarding XX Payment Refusal Incident"), basic information about the payment refusal incident (e.g., transaction time, amount, dispute type), key points of the payment refusal defense (listing the factual and legal basis in bullet points), and a list of evidence (explaining the name, type, source, and proof of each piece of evidence). For example, a defense document for a transaction dispute might include: 1) a defense statement denying fraud allegations; 2) an attachment containing screenshots of the complete chat history between the two parties, proving the compliance of the performance process; 3) citing Article X of the "Administrative Measures for Payment Services" as legal basis; and 4) an electronic signature declaring the authenticity of the content promised by the defense party. A verification code required by the e-commerce platform can also be attached at the end of the document to ensure it has not been tampered with during transmission.

[0048] After generating the defense document, it can be submitted to the payment service provider immediately via the application programming interface (API). First, metadata such as the chargeback event number and the defender's identity information can be embedded as parameters in the defense request. Then, the defense document is converted to binary format using Base64 or similar encoding and embedded in the request body, along with a digital signature generated based on the e-commerce platform's key to ensure the immutability of the submitted content. Next, the request is authenticated using the key issued by the e-commerce platform to prevent unauthorized operations. Finally, the submission receipt returned by the API is received, and the unique acceptance number and status code are parsed to determine the submission result. If the receipt indicates success, the process ends. If errors such as format mismatch or signature expiration occur, the issue should be quickly investigated according to the API documentation, and the submission should be resubmitted until the platform confirms acceptance.

[0049] The above embodiments describe the process of defending against a chargeback event. In addition, before a chargeback event is detected, it is possible to predict whether a target order will trigger a chargeback event, and if the prediction is yes, to collect the evidence required for a chargeback defense in advance. This method is called chargeback prediction.

[0050] Specifically, before a chargeback event is detected for a target order, and assuming the current time reaches a preset time point, the system can acquire chargeback risk characteristics related to the target order. These preset time points include transaction completion (T+0), goods delivery (T+N days), when the buyer initiates a customer service inquiry regarding the target order, and when abnormal operations are detected (such as a buyer initiating multiple refund requests within a short period or chargeback behavior in associated accounts). Chargeback risk characteristics include, but are not limited to, logistics anomaly characteristics (such as delay days, number of delivery failures), service interaction quality assessment characteristics (customer service response timeliness, negative review rate), industry cyclical dynamic risk characteristics (holiday fluctuations, industry seasonal trends), and multi-platform shared risk characteristics (payment network fraud warnings, risks associated with specific card number segments). These characteristics not only cover static information at the time of the transaction but also dynamic risk signals and external risk intelligence during the delivery process. For example, logistics delivery anomalies are a strong predictor of chargebacks due to goods not received, and poor service experience is a related signal for disputed chargebacks. Then, the chargeback risk characteristics are input into a pre-trained chargeback prediction model, which dynamically scores the data based on historical data and real-time characteristics to obtain the model's output chargeback probability. If the chargeback probability exceeds a preset threshold (e.g., 60%), the target order is deemed to have a chargeback risk. At this point, tiered preventative interventions can be triggered based on the risk level. For example, for low-risk orders, proactively send logistics tracking information to enhance transparency; for medium-risk orders, resolve potential disputes in advance through customer service outreach calls; for high-risk orders, recommend that merchants proactively offer compensation to reduce the buyer's motivation to chargeback; and for extremely high-risk orders, simultaneously prepare defense materials and notify the merchant to shorten response time.

[0051] Figure 4 A schematic diagram of the system architecture of an embodiment of this specification is shown. The system includes multiple functional modules that work together, and their specific functions are as follows: First, the system receives raw chargeback event information from the chargeback order input module and triggers the pre-chargeback process. Then, the system comprehensively obtains basic information such as transaction data and user communication records for the target order through chargeback information queries, order information queries, and communication information queries. During this process, ID change detection confirms event uniqueness, failure reason detection parses the specific chargeback code, script repair suggestions provide adjustment solutions for possible data anomalies, and supplementary logistics retrieval automatically retrieves missing logistics documents from the associated system.

[0052] Next, the AI+ defense process begins. The system utilizes the AI ​​topology screening module to perform structured analysis of the current chargeback event, combining topology screening question generation and information to construct a reasoning path suitable for the event. The chargeback reasoning module collaborates with the dynamic LoRa reasoning module, performing dynamic logical reasoning based on real-time session data from context management and compressed, streamlined information. Offline model testing pre-validates the reasoning results, while preference alignment ensures that the generated defense strategy aligns with business preferences. Simultaneously, SFT quality learning and ablation strategy elimination mechanisms continuously optimize model performance, and entropy alignment (i.e., entropy alignment) maintains the stability of the reasoning process. The entire AI process is also supported by a knowledge base and leverages digital life management and accompanying decomposition to achieve real-time question parsing throughout the user's lifecycle.

[0053] Subsequently, the process orchestration module takes over the overall execution path. This module performs node-level scheduling for each of the aforementioned stages and ensures high system availability through node-level retries and automatic retries. Subtree screening and generation, along with sub-ontology format specification, are used to break down and manage complex inference subtasks. Context persistence and context updates maintain the continuous flow of session state, and login point management controls the authorization verification of critical operations. The unified risk control module is activated at this stage, providing decision support for auxiliary and blocking capabilities, such as determining whether to allow the continued generation of defense letters. The dynamic summary and message center of the physical system are responsible for recording the process status in real time and outputting logs for subsequent manual evaluation and topology screening sampling.

[0054] The system then enters the AI-powered defense letter generation stage. Based on the template generation module, the system creates a basic letter structure and determines the recipient's channel format requirements by combining the sender's face string with the face string recognition. The real-time rendering module dynamically previews the letter content, and the document generation module outputs the initial version of the defense letter. During this process, the system automatically utilizes capabilities related to text and image layout, long-image adaptive optimization, and mixed text and image layout (represented by the text and image layout box in the image), integrating automatically generated logistics documents, logistics trajectories, and trajectory images provided by the micro-image engine with the textual statement for unified layout. In addition to polishing and minor optimizations to refine the language, static cleaning and context cleaning further purify the text quality.

[0055] Furthermore, the process incorporates various auxiliary capabilities to automatically capture evidence. These auxiliary capability modules trigger automatic generation of logistics documents, supplementary logistics retrieval, and logistics trajectory queries, automatically obtaining key evidence such as delivery receipts and delivery records from third-party interfaces or databases. The blocking capability module interrupts abnormal processes when necessary. The system also integrates business rules such as waybill templates, return policies, and reward-based payment control, as well as the MCP tool as an external service bridge. The final generated defense letter undergoes model gray-scale verification and evaluation (including manual evaluation and topology screening sampling) before being output in a standardized format, completing the fully automated processing from chargeback input to defense letter generation.

[0056] Figure 5 This is a schematic structural diagram of a device provided in an exemplary embodiment. For example... Figure 5 As shown, device 400 mainly consists of a communication interface 402, a user interface 404, a processor 406, and a data storage 408. These components are interconnected and communicate with each other via a system bus, network, or other connection mechanism 410. The communication interface 402 enables device 400 to communicate with other devices, access networks, and transmission networks via analog or digital modulation. For example, the communication interface 402 may include a chipset and antenna for wireless communication with a radio access network or access point. Furthermore, the communication interface 402 can be a wired interface such as Ethernet, Token Ring, or a USB port, or a wireless interface such as Wi-Fi, Bluetooth, Global Positioning System (GPS), or a wide-area wireless interface (e.g., WiMAX or LTE). Of course, the communication interface 402 can also support other forms of physical layer interfaces and standard or proprietary communication protocols. The communication interface 402 may also include multiple physical communication interfaces, such as Wi-Fi, Bluetooth, and wide-area wireless interfaces.

[0057] User interface 404 includes receiving user input and providing output to the user. Therefore, user interface 404 may include input components such as a keypad, keyboard, touch-sensitive or presence-sensitive panel, computer mouse, trackball, joystick, microphone, still camera, and video camera, and output components such as a display screen (which may be combined with a touch-sensitive panel), CRT, LCD, LED, display using DLP technology, printer, and other similar devices known or developed in the future. User interface 404 may also generate auditory output via speakers, speaker jacks, audio output ports, audio output devices, headphones, and other similar devices known or developed in the future. In some embodiments, user interface 404 may include software, circuitry, or other forms of logic capable of transmitting and receiving data from external user input / output devices. Additionally or alternatively, device 400 may support remote access from other devices via communication interface 402 or another physical interface (not shown). User interface 404 may be configured to receive user input, the position and movement of which may be indicated by an indicator or cursor described herein. User interface 404 may also be configured as a display device for rendering or displaying text fragments.

[0058] Processor 406 may contain one or more general-purpose processors and / or special-purpose processors.

[0059] Data storage 408 may include one or more volatile and / or non-volatile storage components and may be integrated wholly or partially with processor 406. Data storage 408 may include removable and non-removable components.

[0060] Processor 406 is capable of executing program instructions 418 (e.g., compiled or uncompiled program logic and / or machine code) stored in data storage 408 to perform the various functions described herein. Data storage 408 may comprise a non-transitory computer-readable medium on which program instructions are stored, which, when executed by device 400, enable device 400 to perform any methods, processes, or functions disclosed in this specification and / or the accompanying drawings. Processor 406 executing program instructions 418 may result in processor 406 using data 412.

[0061] For example, program instructions 418 may include an operating system 422 (e.g., an operating system kernel, device drivers, and / or other modules) installed on device 400 and one or more applications 420 (e.g., a browser, social application, or game application). Similarly, data 412 may include operating system data 416 and application data 414. Operating system data 416 is primarily accessible to the operating system 422, while application data 414 is primarily accessible to one or more applications 420. Application data 414 may reside in a file system visible or hidden from the user of device 400.

[0062] Application 420 can communicate with operating system 422 through one or more application programming interfaces (APIs). These APIs help application 420 read and / or write application data 414, transmit or receive information via communication interface 402, receive or display information on user interface 404, etc.

[0063] In some terminology, application 420 may be simply referred to as "app". Furthermore, application 420 can be downloaded to device 400 through one or more online app stores or app markets. However, applications can also be installed on device 400 in other ways, such as through a web browser or a physical interface on device 400 (e.g., a USB port).

[0064] Based on the same concept as the methods described above, this specification also provides an electronic device, including: a processor; a memory for storing processor-executable instructions; wherein the processor performs the steps of the method as described in any of the above embodiments by executing the executable instructions.

[0065] Based on the same concept as the methods described above, this specification also provides a computer-readable storage medium having computer instructions stored thereon that, when executed by a processor, implement the steps of the methods as described in any of the above embodiments.

[0066] Based on the same concept as the methods described above, this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the methods as described in any of the above embodiments.

[0067] What those skilled in the art will understand is: In this specification, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitation, the presence of additional identical or equivalent elements in a process, method, product, or apparatus that includes said elements is not excluded.

[0068] In this specification, “a,” “an,” and “the” do not specifically refer to the singular, but may also include the plural.

[0069] In this specification, ordinal numbers such as "first," "second," etc., do not necessarily indicate order; they are often used to distinguish between objects. For example, "first server" and "second server" usually refer to two servers. To differentiate between these two servers, they are described as "first server" and "second server." Of course, sometimes these two servers may be the same server.

[0070] In this specification, unless explicitly stated otherwise, "receiving and sending data" does not necessarily mean direct receiving and sending; it can also mean indirect receiving and sending. For example, A receiving data sent by B can be understood as A directly receiving the data sent by B, or it can be understood as A indirectly receiving the data sent by B through other entities such as C. Similarly, B sending data to A can be understood as B sending the data directly to A, or it can be understood as B indirectly sending the data to A through other entities such as C. Here, C can be one entity, or it can be two or more entities.

[0071] In this specification, unless explicitly stated otherwise, the relationships between structures can be direct or indirect. For example, when describing "A is connected to B," unless it is explicitly stated that A and B are directly connected, it should be understood that A can be directly connected to B or indirectly connected to B. Similarly, when describing "A is on top of B," unless it is explicitly stated that A is directly above B (AB is adjacent and A is above B), it should be understood that A can be directly above B or indirectly above B (AB is separated by other elements, and A is above B). And so on.

[0072] This specification uses specific terms to describe embodiments thereof. Terms such as "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic associated with at least one embodiment of this specification. Therefore, it should be emphasized and noted that references to "an embodiment," "one embodiment," or "an alternative embodiment" in different locations throughout this specification do not necessarily refer to the same embodiment. Furthermore, those skilled in the art can combine and integrate the different embodiments or examples described herein, as well as the features of those different embodiments or examples, without contradiction.

[0073] Although one or more embodiments of this specification provide method steps as described in the embodiments or flowcharts, it is understood that the order of steps listed in the embodiments or flowcharts is only one of many possible execution orders and does not represent the only execution order. Therefore, when the claims involve method steps, any changes or adjustments to the order of such steps, or the parallelism between steps, are also within the scope of protection of the claims.

Claims

1. A method for generating a non-payment defense document, the method comprising: Upon detecting a chargeback event against a target order, a robotic process is triggered. This robotic process uses a programmable browser to automate the process by accessing a designated source of evidence based on the unique identifier of the target order, in order to obtain the evidence required to defend against the chargeback event from the designated source of evidence. The target reason for non-payment and the evidence obtained are input into the non-payment defense model generated after multi-stage fine-tuning, and the structured defense statement output by the non-payment defense model is obtained; wherein, the multi-stage fine-tuning includes: a first-stage fine-tuning based on sample defense statements of the winning defense, and a second-stage fine-tuning based on sample pairs composed of sample defense statements of the winning defense and sample defense statements of the losing defense; According to the document generation rules of the payment service provider, the structured defense arguments and the evidence are integrated and arranged to generate a defense document, which is then submitted to the payment service provider through the application programming interface.

2. The method according to claim 1, wherein the step of inputting the target reason for non-payment and the obtained evidence into the non-payment defense model generated after multi-stage fine-tuning is performed when the risk level of the non-payment event is determined to be a risk level requiring defense; the risk level is determined based on the following method: Obtain the buyer intent characteristics of the chargeback event; the buyer intent characteristics include the historical behavior characteristics of the buyer who initiated the chargeback event, the transaction characteristics of the target order, the interaction behavior characteristics of the target order, and / or the associated network characteristics; The buyer's intent characteristics are input into a preset rule engine for matching to determine the risk level of the chargeback event; If a match fails, the features of the chargeback event are input into a pre-trained classification model to determine the risk level of the chargeback event.

3. The method according to claim 1, further comprising: If evidence cannot be obtained from the designated evidence source, obtain the supporting materials uploaded by the user; Analyze the key fields in the supporting materials; Invoke the preset evidence generation template; The key fields are filled into the evidence generation template to generate evidence.

4. The method according to claim 1, further comprising: If evidence cannot be obtained from the designated evidence source, obtain the sequence of operations performed on the designated evidence source, as well as the webpage snapshot and webpage DOM structure of the designated evidence source when each operation in the sequence of operations is performed; The operation sequence, the webpage snapshot, and the webpage DOM structure are input into a multimodal language model to analyze the reasons for screenshot failure.

5. The method according to claim 4, wherein the multimodal language model performs screenshot failure analysis based on the following method: By using cross-modal alignment technology, the operation sequence is associated and mapped with the changes of web page elements in the web page DOM structure to obtain the correspondence between each operation in the operation sequence and the changes of web page elements. Based on the correspondence, the key steps that the user attempts to obtain evidence are identified. The computer vision module is used to analyze the position and state of visual elements in the webpage snapshot, and the obtained visual information is fused with the semantic information of the webpage DOM structure. Based on the fused visual and semantic information, the reason for the screenshot failure is determined.

6. The method according to claim 1, wherein inputting the target reason for the non-payment event and the obtained evidence into the non-payment defense model generated after multi-stage fine-tuning includes: Obtain evidence requirement configuration information, which is used to define the mapping relationship between the reasons for non-payment and the required set of evidence; Based on the mapping relationship between the reasons for non-payment and the evidence set in the evidence requirement configuration information, obtain the target evidence set corresponding to the target reason for non-payment; If the evidence obtained from the specified data source covers the target evidence set, the target reason for non-payment and the obtained evidence are input into the non-payment defense model generated after multi-stage fine-tuning.

7. The method according to claim 6, wherein the evidence includes necessary evidence and optional evidence, and the evidence requirement configuration information is further used to define the mapping relationship between each piece of evidence in the evidence set and the evidence source; the method further includes: If the evidence obtained from the specified data source does not cover the target evidence set, the initial scores of the necessary and optional evidence obtained from the specified data source are weighted and summed based on preset weights to obtain the evidence completeness score. If the completeness score of the evidence is lower than the preset score, the evidence is determined to be missing; Based on the mapping relationship between evidence and evidence source recorded in the evidence requirement configuration information, the missing evidence is obtained from the corresponding evidence source.

8. The method according to claim 1, wherein the evidence obtained includes multiple items; before inputting the target reason for non-payment and the obtained evidence into the non-payment defense model generated after multi-stage fine-tuning, the method further includes: Determine the type of evidence for each piece of evidence obtained; If multiple pieces of evidence of the same type exist, conflict detection is performed on the multiple pieces of evidence of the same type to determine whether there is a conflict between the multiple pieces of evidence of the same type. If so, determine the priority of the multiple pieces of evidence of the same type; Select the evidence with the highest priority from the multiple pieces of evidence of the same type.

9. The method according to claim 8, wherein determining the priority of the plurality of similar pieces of evidence includes: Determine the timeliness score, completeness score, and reliability score of the aforementioned multiple pieces of similar evidence; The timeliness score, completeness score, and reliability score of each piece of evidence of the same type are weighted and summed to obtain the comprehensive score of that piece of evidence of the same type. The priority of the multiple pieces of similar evidence is determined based on their combined scores.

10. The method of claim 1, further comprising, before detecting a chargeback event for the target order: If the current time reaches a preset time node, obtain the chargeback risk characteristics related to the target order; The preset time nodes include when the transaction is completed, when the goods are delivered, when the buyer initiates a customer service inquiry for the target order, and when abnormal operations are detected; the chargeback risk characteristics include logistics anomaly characteristics, service interaction quality assessment characteristics, industry periodic dynamic risk characteristics, and multi-platform shared risk characteristics; The chargeback risk characteristics are input into a pre-trained chargeback prediction model to obtain the chargeback probability output by the chargeback prediction model. If the chargeback probability is higher than a preset probability threshold, it is determined that the target order has a chargeback risk, and the evidence required for the chargeback defense is obtained and stored.

11. The method according to claim 1, wherein inputting the target reason for non-payment and the obtained evidence into a non-payment defense model generated after multi-stage fine-tuning, and obtaining the structured defense statement output by the non-payment defense model, comprises: Obtain a pre-established graph structure, which is used to establish the relationship between order characteristics, chargeback reasons, historical chargeback events, and chargeback defense results; the defense results are used to characterize whether the defense is successful or unsuccessful. Extract the chargeback reason for the chargeback event and the order characteristics of the target order; Retrieve from the graph structure reference order features that match the extracted order features and reference chargeback reasons that match the extracted chargeback reasons; Identify historical chargeback events that are associated with the reference order characteristics and the reference chargeback reason and for which a successful defense was won; The template for generating defense statements used when defending against the historical non-payment events, the target reason for non-payment in the non-payment events, and the evidence obtained are input into the non-payment defense model generated after multi-stage fine-tuning. The structured defense statement output by the non-payment defense model follows the format requirements of the template for generating defense statements.

12. An electronic device, comprising: processor; A memory for storing processor-executable instructions; wherein the processor implements the steps of the method as described in any one of claims 1-11 by executing the executable instructions.

13. A computer-readable storage medium having stored thereon computer instructions that, when executed by a processor, implement the steps of the method as claimed in any one of claims 1-11.

14. A computer program product comprising a computer program or instructions which, when executed by a processor, implement the steps of the method as claimed in any one of claims 1-11.

Images