A method, system, and storage medium for refunds from original channels based on OTA data models.

Abstract

This application provides a method, system, and storage medium for original channel refunds based on an OTA data model, including the following steps: a wire transfer information collection and decision-making step; a complex scenario identification step for original channel refunds; a wire transfer information collection step; a wire transfer refund step; an offline advance payment refund step; and a payment integration information step, receiving a corresponding request, encrypting sensitive information in the request, and then initiating an external request for wire transfer transmission / wire transfer refund to the payment platform. This application enables passengers to operate the entire process independently by providing self-service refunds for wire transfers and offline advance payments, reducing reliance on manual customer service and simplifying the refund process; and improves data security by implementing sensitive information level protection.

Description

Technical Field

[0001] This application belongs to the field of computer data processing technology, and in particular relates to a method, system and storage medium for refunds from the original channel based on the OTA data model. Background Technology

[0002] In recent years, with the booming development of the aviation industry, the passenger ticketing experience has achieved a qualitative leap. Ticketing channels have become significantly more diversified, encompassing official websites, online travel agencies (OTAs), and third-party agent platforms, providing passengers with a wide range of choices. In the payment process, passengers not only enjoy convenient and efficient payment services but can also flexibly choose from a variety of payment products according to their personal preferences. Some products even support personalized combinations, greatly enhancing payment flexibility and satisfaction. Regarding refund requests, to ensure that consumer rights are fully protected, the "Consumer Rights Protection Law of the People's Republic of China" and related regulations clearly define the right to a seven-day no-reason return policy in online shopping and extend this principle to the air ticketing sector. Merchants are required to respond quickly and process refund requests efficiently to ensure that payments are returned to passengers promptly and safely. It is worth noting that although the law does not mandate that refunds must be processed through the original channel, in practice, "refund through the original channel" has become the industry standard and has established a good practice in many business sectors. This practice not only simplifies the refund process and improves efficiency but also enhances consumer trust and recognition of air ticketing services.

[0003] The diversification of ticketing channels and payment methods, while bringing convenience, also increases the complexity and challenge of refunds through the original channels. Specifically, passengers may face issues such as the original payment method being discontinued, unable to be recognized by the system, changes to bank or payment account information, and temporary system failures at payment institutions or banks, all of which can hinder the refund process. To address these issues, some domestic airlines still rely on manual judgment, application form completion, and work order processing. However, with increasing business volume, this manual approach has the following limitations:

[0004] The process is cumbersome: After failing to obtain a refund through the original payment channel, passengers must fill out a paper or electronic refund application form through customer service. These forms contain a large amount of information, such as order details, reason for refund, and proof of identity, and may require multiple confirmations and modifications. After submission, the refund application enters the manual processing flow, involving approval from multiple departments, which prolongs the refund processing time.

[0005] Poor information transmission quality: When processing refunds manually, information may be lost or mistransmitted at multiple stages. The lack of a unified information management system and poor information sharing between different departments increases the difficulty of refund processing. This may result in passengers receiving incorrect refund amounts or delayed updates to refund status.

[0006] Weak security protections: When relying on manual operations, passengers' sensitive information (such as bank account details and payment passwords) faces a high risk of leakage during transmission and storage. Manual processing may lack effective security auditing and monitoring mechanisms, making it difficult to detect and respond to potential security threats in a timely manner. Once an information breach occurs, it can lead to serious financial losses and reputational damage.

[0007] Human subjective identification of anomalies has limitations: for some uncommon payment methods or complex refund scenarios, it may be difficult for humans to accurately determine whether the refund conditions are met, making it difficult to avoid the risk of cash-out.

[0008] In summary, the current refund function provided by airlines in complex scenarios has shortcomings. After a refund fails through the original channel, passengers need to go through the counter and human customer service to complete the subsequent refund process, which increases the airline's costs and complaint rate, and also causes inconvenience to customers during the refund process. Summary of the Invention

[0009] This application addresses the shortcomings of existing technologies by providing a service for refunds made through original channels in complex scenarios. It supports multiple refund methods, including wire transfer refunds, offline advance payments, and cross-channel order refunds, covering refunds for tickets booked through direct sales channels (official website, mobile app, WeChat official account) and distribution channels (agents, third-party booking websites). It supports refunds for mixed payment orders (bank card + cash, vouchers, coupons); refunds for any ticket in the same order; and multi-dimensional configuration of refund strategies (matching refund process strategies based on refund reason, prioritizing refund recipients, and automatically splitting wire transfer amounts). It also ensures data and fund security. While reducing airline operating costs, it provides passengers with a simpler and more convenient refund experience, thereby improving customer satisfaction.

[0010] The first aspect of this application provides a method for refunding funds through the original channel based on an OTA data model, comprising the following steps:

[0011] The decision-making process for collecting wire transfer information involves determining the highest priority collection method based on the provided orders and the wire transfer information collection strategy.

[0012] The steps for identifying complex scenarios of refunds through the original channel are as follows: Use a finite state automaton to handle different refund states, call the API to receive refund status update notifications, and pass the received notifications to the state machine receiver and converter to trigger state transitions;

[0013] The wire transfer information collection step involves receiving and verifying the submitted wire transfer information through the wire transfer information collection interface. Once the verification is successful, the wire transfer information is updated in the unified order data model and then transferred to the subsequent refund process by sending an internal request.

[0014] The wire transfer refund process will refund the portion of the amount that could not be successfully withdrawn through the original channel to the passenger's designated bank account via wire transfer.

[0015] For offline refund processing, passengers can choose a service point to complete the offline refund process.

[0016] The payment integration information step involves receiving a corresponding request, encrypting the sensitive information in the request, and then initiating an external request for wire transfer / wire transfer refund to the payment platform.

[0017] Furthermore, this includes the following steps:

[0018] Security measures include verifying the identity of the person requesting a refund, desensitizing and encrypting sensitive passenger information, and preserving a complete transaction history.

[0019] The security risk control steps include real-time risk control, accurate rating, delayed refunds, and real-time updates to risk control strategies to identify and process suspicious refunds.

[0020] In the message integration process, during the refund process, passengers receive notifications of wire transfer collection, refund reminders, and agent work orders. The system determines the message type and target recipient, and automatically constructs message content according to a preset input template to achieve accurate message delivery.

[0021] Furthermore, the aforementioned wire transfer information collection and decision-making steps include:

[0022] The scenarios that support the collection of wire transfer information are three: refund amount exceeding the limit, payment merchant refund failure, and bank refund failure. In the scenarios of refund amount exceeding the limit and payment merchant refund failure, all methods are supported for collecting wire transfer information, while in the scenario of bank refund failure, only the methods of payer and customer are supported for collecting wire transfer information.

[0023] Based on the business scenario of the order data, determine the supported collection methods, analyze the orders, and collect data according to the passenger if there is a passenger; if there is no passenger but there is a payer, collect data according to the payer; if there is neither a passenger nor a payer, collect data according to the contact person.

[0024] If the order involves a failed bank refund, the decision-making process begins with the payer.

[0025] If it is a scenario where wire transfer information is collected again, it needs to be compared with the previous collection method in the order. If it is a collection method with the same priority, it needs to be downgraded by one level.

[0026] Furthermore, the steps for identifying complex scenarios involving refunds from the original channels mentioned above include:

[0027] The refund status update notification information indicates whether the review was rejected, the payment provider's refund failed, or the bank's refund failed.

[0028] The data processing action retrieves all information related to a specific refund order and updates the order data with the refund order data.

[0029] The decision-making mechanism is invoked to determine whether a refund should be issued based on the wire transfer information of the passenger, the payer, or the customer; at the same time, the order is added to the wire transfer collection guarantee mechanism to ensure the progress of the wire transfer refund.

[0030] Furthermore, the aforementioned wire transfer information collection steps include:

[0031] When a refund anomaly occurs and the passenger chooses to have their wire transfer information collected, the wire transfer information is collected, verified, and written into the unified order data model.

[0032] Receive unified XML requests based on the OTA data model;

[0033] By comparing the collection method in the request with the collection method returned by the telegraphic transfer information collection decision mechanism, the correctness of the telegraphic transfer information collection and content can be verified.

[0034] After verification, the wire transfer information is encrypted and written into the unified order data model through the security module. In the case of refund overspending or payment merchant refund failure, an internal wire transfer refund request is initiated. In the case of bank refund failure, an internal wire transfer transmission request is initiated for subsequent processing.

[0035] Furthermore, the above-mentioned wire transfer refund process includes the following steps:

[0036] By calling the API interface of the external payment merchant provided in the original channel refund complex scenario identification step, after receiving the refund status notification from the payment platform, the finite state automaton is called to obtain the decision result of the state machine, the status of the refund application is updated to the unified order data model, and a message notification is sent to the passenger.

[0037] After receiving a notification message that wire transfer information needs to be collected, passengers fill in the corresponding wire transfer information on the order details page and submit it.

[0038] Upon receiving a wire transfer information collection request, the wire transfer information is encrypted and written into a unified order data model through the security protection step. An internal wire transfer information request is initiated based on different refund abnormal statuses.

[0039] After receiving the internal request for wire transfer refund, the wire transfer refund step analyzes the order's refund status and wire transfer information, generates a wire transfer refund record based on the corresponding refund status scenario, updates it to the unified order data model, and initiates an internal request for wire transfer refund to the payment integration step.

[0040] After receiving the internal request for wire transfer information or the internal request for wire transfer refund, the payment integration information step encrypts the sensitive information through the security protection step and then initiates an external request for wire transfer / wire transfer refund to the payment platform.

[0041] Furthermore, the aforementioned offline advance refund process includes the following steps:

[0042] After receiving the refund status notification from the payment platform, the finite state automaton is invoked to obtain the decision result of the state machine, and the status of the refund application is updated in the order data structure;

[0043] When a passenger receives a refund failure message from the payment provider, they can choose to apply for offline advance payment. This will initiate an internal request for offline advance payment to the payment integration module, update the order refund status, and record the offline branch information selected by the passenger into the order data.

[0044] Furthermore, the above-mentioned payment integration information steps include the following steps:

[0045] Upon receiving a request, the system uses reflection to quickly locate and activate the corresponding processing logic entry point; it establishes a wire transfer refund application queue, a wire transfer transmission queue, and an offline advance payment exception handling queue; once an exception is encountered when calling the payment platform API, the relevant request will be automatically added to the exception handling queue, triggering the built-in interface retry mechanism Retry Mechanism; if it fails again, the Time Decay strategy will intervene.

[0046] The second aspect of this application provides a refund system for original channels based on an OTA data model, the system comprising:

[0047] The wire transfer information collection decision module determines the highest priority collection method based on the provided orders and wire transfer information collection strategies.

[0048] The original channel refund complex scenario recognition module uses a finite state automaton to handle different refund statuses. It receives refund status update notifications by calling the API interface of an external payment provider and passes the received notifications to the state machine receiver and converter to trigger state transitions.

[0049] The wire transfer information collection module receives and verifies the submitted wire transfer information through the wire transfer information collection interface. After the verification is successful, the wire transfer information is updated into the unified order data model and then transferred to the subsequent refund process by sending an internal request.

[0050] The wire transfer refund module will refund the portion of the amount that could not be successfully withdrawn through the original channel to the passenger's designated bank account via wire transfer.

[0051] The offline refund module allows passengers to choose a service point and complete the offline refund process.

[0052] After receiving the corresponding request, the payment integration information module encrypts the sensitive information in the request and then initiates an external request for wire transfer / wire transfer refund to the payment platform.

[0053] A third aspect of this application provides a computer-readable storage medium storing one or more programs that, when executed, enable a refund method based on an OTA data model for refunds made through the original channel.

[0054] Compared with the prior art, this application has the following advantages:

[0055] First, by providing self-service refunds such as wire transfer refunds and offline advance payments, passengers can operate the entire refund process independently, reducing reliance on human customer service and simplifying the refund process.

[0056] Secondly, an automated refund review system was introduced to automatically review and generate refund instructions according to established rules, reducing manual intervention and improving the passenger experience;

[0057] Furthermore, the service offers flexible options, allowing travelers to choose their own refund method, channel, and recipient to meet different needs; in addition, information security is strengthened by implementing sensitive information level protection to ensure data security and complete recording of operation history.

[0058] Finally, strengthen security and risk control, establish a risk control rule base, monitor refund transactions in real time, effectively prevent fraudulent activities, and ensure the safety of funds.

[0059] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures pointed out in the description, claims and drawings. Attached Figure Description

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

[0061] Figure 1 A flowchart illustrating the original channel refund method based on the OTA data model is shown.

[0062] Figure 2 A flowchart illustrating the original channel refund method based on the OTA data model is shown;

[0063] Figure 3 A schematic block diagram of the original channel refund system based on the OTA data model is shown;

[0064] Figure 4 The block diagram of the complex scenario recognition module for refunds from the original channel is shown;

[0065] Figure 5 A block diagram of the wire transfer information collection module is shown;

[0066] Figure 6 A block diagram of the telegraphic transfer information collection and decision-making machine module is shown;

[0067] Figure 7 A block diagram of the wire transfer refund module is shown;

[0068] Figure 8 The diagram shows the block diagram of the offline advance payment module. Detailed Implementation

[0069] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0070] To better understand the technical terms and abbreviations used in this application, they are explained as follows:

[0071] Collecting wire transfer information: Collecting information such as bank card number and cardholder's name from passengers in order to transfer the refund to the bank account.

[0072] Payment Center: A network transit platform designed to meet users' various payment needs, interact with banks, payment providers, etc., and provide secure and convenient payment services.

[0073] Risk Control Center: The Risk Control Center, also known as the Risk Management Center, is primarily responsible for managing and controlling business risks through various means and methods to reduce or avoid risk events, ensuring normal business operations and asset security.

[0074] Customer service representatives: These are live agents who communicate with customers in real time to resolve issues or provide support.

[0075] SPNR: An XML data model built on the OTA data model, used to store order data information.

[0076] The original channel refund method based on the OTA data model in this application is as follows: Figure 1 As shown, the payment platform receives a notification of the refund status. The system performs complex scenario identification of the original channel, updates the refund status to the order database, and sends a message notification to the passenger. There are two types of message notifications: one is when the passenger submits wire transfer information, and the other is when the passenger selects an offline prepayment point. When the passenger submits wire transfer information, the system first checks whether the wire transfer information is correct. If it is, the wire transfer information is updated to the order database, a wire transfer refund record is generated, and the wire transfer refund record is updated to the order database. The system then checks for security risks. If a security risk is found, a wire transfer / wire transfer refund request is initiated and sent to the payment platform.

[0077] When a passenger selects an offline payment outlet, a refund record for the advance payment is generated, the refund record is updated in the order database, and an offline payment request is initiated and sent to the payment platform.

[0078] The process of the original channel refund method based on the OTA data model in this application is as follows: Figure 2 As shown, it includes the following steps:

[0079] The decision-making process for collecting wire transfer information involves determining the highest priority collection method based on the provided orders and the wire transfer information collection strategy.

[0080] The steps for identifying complex scenarios of refunds through the original channel are as follows: Use a finite state automaton to handle different refund states, call the API interface to receive refund status update notifications, and pass the received notifications to the state machine receiver and converter to trigger state transitions;

[0081] The wire transfer information collection step involves receiving and verifying the submitted wire transfer information through the wire transfer information collection interface. Once the verification is successful, the wire transfer information is updated in the unified order data model and then transferred to the subsequent refund process by sending an internal request.

[0082] The wire transfer refund process will refund the portion of the amount that could not be successfully withdrawn through the original channel to the passenger's designated bank account via wire transfer.

[0083] For offline refund processing, passengers can choose a service point to complete the offline refund process.

[0084] The payment integration information step involves receiving a corresponding request, encrypting the sensitive information in the request, and then initiating an external request for wire transfer / wire transfer refund to the payment platform.

[0085] The original channel refund self-service system constructed according to this application, such as Figure 3 As shown, this system mainly includes: a wire transfer information collection and decision-making mechanism module, a complex scenario identification module for refunds from original channels, a wire transfer information collection module, a wire transfer refund module, an offline advance payment refund module, a security module, a security risk control module, a payment integration module, and a message integration module.

[0086] The ERC-Decision mechanism module for electronic remittance information collection aims to determine the highest priority collection method based on the provided order and electronic remittance information collection strategy. It considers the priorities of collection by passenger, payer, and contact person, along with the collection methods supported by the business scenario, to provide a feasible and optimal electronic remittance information collection method. Collection methods include collection by passenger, collection by payer, and collection by contact person, with inherent priorities: passenger is level one, payer is level two, and customer is level three, with level one being the highest priority, level two the next highest, and level three the lowest. The scenarios supporting wire transfer collection include three types: refund amount exceeding the limit, payment merchant refund failure, and bank refund failure. Due to business limitations, for refund amount exceeding the limit and payment merchant refund failure scenarios, all methods are supported for collecting wire transfer information. However, for bank refund failure scenarios, only the payer and customer methods are supported for collecting wire transfer information. Under these rules, the supported collection methods are determined based on the business scenario of the order data. The order is analyzed: if there is a passenger, data is collected based on the passenger; if there is no passenger but a payer, data is collected based on the payer; if neither a passenger nor a payer exists, data is collected based on the contact person. If the order is a bank refund failure scenario, the decision-making process starts from the payer. Finally, if it's a scenario requiring re-collection of wire transfer information, it needs to be compared with the previous collection method in the order. If the collection methods are of the same priority, the method should be downgraded to the next lower priority.

[0087] Original channel refund complex scenario identification module: such as Figure 4As shown, different refund states are handled using a Finite-State Automaton (FSA). An API interface is provided for external payment providers to receive refund status updates from external systems, such as approval rejection, payment provider refund failure, and bank refund failure. The received notifications are then passed to the state machine's acceptors and transducers, triggering state transitions. Based on the state machine's decision, the refund order data is updated, including rejections for abnormal refund amounts, refund overruns, payment provider refund failures, and bank refund failures. A notification or work order is then sent to the passenger or agent regarding wire transfer collection or agent selection. A wire transfer collection guarantee mechanism is also provided, adding the order to the guarantee mechanism to ensure the progress of wire transfer refunds until the wire transfer information is successfully collected, at which point the guarantee mechanism is exited.

[0088] Specifically, the data processing action (Action) is performed in the original channel refund complex scenario identification module. This retrieves all information related to a specific refund order, including order status and refund amount. Based on the state machine's decision results, the refund order data is updated. Statuses such as rejected refund requests due to abnormal amounts, refunds exceeding budget limits, failed payment merchant refunds, and failed bank refunds are updated to reflect the latest processing progress. For cases where the refund request was rejected due to abnormal amounts, a work order is sent to the agent to inform them to re-review the refund, reflecting the latest processing progress. The decision-making mechanism is invoked to determine whether the refund should be processed via wire transfer information from the passenger, the payer, or the customer. If the refund is based on the passenger's wire transfer information, retrieve the passengers involved in the refund for the current order and inform the contact person that wire transfer information for all passengers in the list needs to be collected. If the refund is based on the payer, retrieve the payer for the current order and inform the contact person that wire transfer information for the payer needs to be collected; if there are multiple payers, allow the contact person to choose one. If the refund is based on the contact person's wire transfer information, instruct the contact person to provide a copy of the wire transfer information. Retrieve the contact person information for the current order, call the message notification module, and pass in the contact person's contact information, the failure scenario, and the message to be notified (the contact person's handling method; if the refund failed due to the payer, they can choose to receive a refund via wire transfer or choose an offline prepayment refund method to process the refund at a physical branch). Wait for the passenger to proceed with the next step. Simultaneously, add this order to the wire transfer collection guarantee mechanism to ensure the progress of the wire transfer refund. This mechanism utilizes a passenger wire transfer information collection queue for support. The queue's automatic process is triggered every 8 hours. Each trigger checks whether wire transfer information for orders within the queue has been collected within the configured time limit (dynamically obtained in real-time, typically 24 hours). If any orders have exceeded the time limit and have not been collected, the message notification integration module sends a work order to the agent supervisor, notifying them of the list of orders that have not been collected within the time limit. The agent then notifies the passenger to collect the information promptly. The mechanism continues until the wire transfer information is successfully collected.

[0089] The wire transfer information collection module receives wire transfer information submitted by passengers through a unified wire transfer information collection interface. Specifically, this interface receives a unified XML request built based on the OTA data model. This request needs to include the order number, the enumeration value of the wire transfer transaction scenario, refund information, and a set of wire transfer information, including the wire transfer information sequence number, the sequence number of the associated person, the bank card number, the account opening location, the account opening bank, and the cardholder's name. In the event of a refund anomaly and the passenger selects wire transfer information collection, such as... Figure 5As shown, this module collects, verifies, and writes wire transfer information into the unified order data model. This module is responsible for collecting wire transfer information in three scenarios: refund amount overrun, payment merchant refund failure, and bank refund failure. It verifies the information based on the collection method, order data, and input wire transfer information. Upon successful verification, the module updates the wire transfer information into the unified order data model and forwards it to the subsequent refund process via an internal request. The wire transfer information collection decision mechanism module is as follows: Figure 6 As shown,

[0090] Wire transfer information collection module, such as Figure 6 As shown, the system compares the collection method submitted by the order contact person in the wire transfer information request with the collection method returned by the wire transfer information collection decision mechanism to verify the correctness of the wire transfer information collection method. Additionally, the accuracy of the wire transfer information content must also be verified. Once verification is successful, the wire transfer information is encrypted and stored in the database (written into the unified order data model) through the security module, and the wire transfer information collection security mechanism is exited. In cases of refund overdraft or payment merchant refund failure, an internal wire transfer refund request is initiated; in cases of bank refund failure, an internal wire transfer transmission request is initiated, and the process proceeds to the next step. If verification fails, the passenger is responded to according to the verification content.

[0091] The wire transfer refund module is responsible for refunding the portion of the amount that could not be successfully withdrawn through the original refund channel, transferring it via wire transfer to the bank account designated by the passenger. For example... Figure 7 As shown, the system first accepts order control from the wire transfer information collection module and retrieves the corresponding unified order data model from the database. Based on this model, it obtains the information needed for the wire transfer amount splitting process. Then, it identifies refund failure exception types from the unified order data model and splits the amount requiring wire transfer refund according to these types. If splitting the wire transfer amount by passenger is required, it also retrieves the corresponding automatic wire transfer amount splitting strategy from the configuration file and splits the wire transfer refund amount according to the specified strategy. Next, it matches the split wire transfer refund amount with the wire transfer information one by one, generates corresponding wire transfer refund records, and stores them in the database. Finally, it initiates a refund request to the payment module and transfers order control.

[0092] The refund failure exception types are further refined into the following scenarios: 1. If the exception type is "Refund Amount Exceeded". It is necessary to obtain the refundable amount from the original payment record based on the error information, and then obtain the order's refundable amount. The difference between these two is the wire transfer refund amount. After matching it with the wire transfer information, a wire transfer refund record is generated and updated in the unified order data model. 2. If the exception type is "Payer Refund Failure". First, it is necessary to determine whether the refundable amount can be split by passenger. If it cannot be split by passenger, then the entire refundable amount is matched with the wire transfer information to generate a wire transfer refund record and update it in the unified order data model. If it can be split by passenger, then in the products where refunds have been applied for, the refundable amount for each passenger is summed across products to obtain the total refundable amount for each passenger, establishing a dataset of the total refundable amount for each passenger. The corresponding automatic wire transfer refund strategy is then retrieved from the configuration file, which can be further subdivided into: Strategy 1, fixed configuration priority strategy, which prioritizes refunds based on the refund priority of different payment products from different payment providers as specified in the configuration file; Strategy 2, payment time priority strategy, which prioritizes refunds based on the payment time of the payment record, following a "last payment, first refund" logic; and Strategy 3, weighted priority strategy, which prioritizes refunds based on the numerical value of the payment amount in the payment record. Based on the refund priority, the highest priority payment products in the payment record are first split into refundable amounts according to the proportion of the associated passenger in that payment record. If the refundable amount is less than the passenger's total refundable amount, a wire transfer refund record is generated after matching the corresponding wire transfer information with the split refundable amount, and this amount is deducted from the passenger's total refundable amount. This process is repeated for the next priority payment record until the split refundable amount is greater than the passenger's remaining refundable amount. At this point, a wire transfer refund record is generated after matching the corresponding wire transfer information with the passenger's remaining refundable amount. All wire transfer refund records generated throughout this process need to be updated in the unified order data model. Finally, an internal request for a refund is sent to the payment integration module, transferring order control.

[0093] Payment Integration Module: This module features a highly efficient internal interface system specifically designed to receive requests from business modules such as wire transfer collection, wire transfer refund, and offline advance payment. Upon receiving these requests, it utilizes reflection to quickly locate and activate the corresponding processing logic entry point. Specifically, it uses the HTTP protocol to call the interfaces provided by the payment platform to achieve inter-service communication.

[0094] Furthermore, this module specifically introduces a wire transfer refund application queue, a wire transfer transmission queue, and an offline advance payment exception handling queue. These queues adopt a first-in, first-out (FIFO) principle to ensure fair and orderly processing of requests. If an exception occurs when calling the API interface, the relevant request will be automatically added to the exception handling queue, triggering the built-in interface retry mechanism. If it fails again, a time decay mechanism will intervene to improve the efficiency and stability of transaction processing.

[0095] Offline refund advance module, such as Figure 8 As shown, offline advance payment refunds involve the system transferring the refund amount to a designated branch for the traveler to collect themselves. This is a reliable refund method that guarantees a successful refund. In cases of refund failure due to payment failure, the traveler will receive an SMS notification from the message integration module, allowing them to choose between wire transfer collection or offline advance payment application on the operation page. If the traveler chooses offline advance payment application, they will be redirected to an application page to confirm the offline branch information. The default branch information is obtained through the client, assuming the user's consent. If the user wants to modify this, they can select a new offline branch. After confirming the selection, clicking the "Offline Advance Payment Application" button requests the offline advance payment refund interface. This module receives the request and verifies whether the order meets the offline advance payment refund conditions. If it does, it initiates an internal offline advance payment request to the payment integration module. Upon successful response, the payment integration module updates the order refund status to "Waiting for Offline Advance Payment," records the traveler's selected offline branch information in the unified order data model, removes the current order from the wire transfer information collection guarantee mechanism, and prompts the traveler to go to the corresponding branch for offline refund. If verification or other anomalies occur, an error message will be displayed to the user. At this point, the order is still under the wire transfer information collection and protection mechanism. The traveler can choose to collect the wire transfer information or resubmit the offline advance payment application according to the prompts. This service innovatively allows travelers to choose the nearest service point to complete the offline refund process, providing users with a more flexible and convenient refund solution.

[0096] Security Assurance Module: This module is designed from three aspects: refund channel verification, refund recipient identity authentication, passenger sensitive information level protection, and data auditing. 1. Refund Channel Verification: Ensures all refund operations are only conducted through channels pre-configured and permitted by the system, effectively preventing unauthorized refund channels. 2. Identity Authentication for Refund Recipients (Passengers, Payers, Contacts) 3. De-identification and Encryption Protection of Passenger Sensitive Information (Name, Contact Information, Identity Information, Bank Card Number) according to Level Protection Requirements; 4. Preservation of Complete Operation History, Ensuring Traceability of Every Operation and Supporting Security Auditing. Specifically, this module encrypts and transmits passenger ticket numbers, order numbers, passenger identity information, and wire transfer collection information using the AES encryption algorithm. After receiving the information, the query interface extracts relevant orders to verify passenger identity and channel, and checks whether the order meets the conditions for wire transfer or advance payment. If it does, subsequent processing is initiated. A unique operation log is generated for each refund operation, recording key information such as refund recipient information, refund amount, refund time, and refund method, and recorded in a unified order data model. Important information such as bank card details is stored using AES encryption. When checking order details and refund progress, sensitive passenger information will be returned de-identified using a replacement algorithm.

[0097] Security Risk Control Module: In practice, wire transfer refunds and offline advance payments are prone to cash-out risks. When a wire transfer refund application is submitted, the risk control center service is invoked to identify suspicious transactions. This module retrieves strategies or rules from the configuration module based on risk ratings, updates the order risk control flag and the delayed refund duration, and sets the refund application status to "delayed refund." The processing queue is polled hourly, and the refund operation continues after the expiration date. This module primarily utilizes real-time risk control, accurate rating, delayed refunds, and real-time updates to risk control strategies to effectively ensure fund security, reduce cash-out risks, improve risk control efficiency, and efficiently identify and process suspicious refunds.

[0098] Message Integration Module: Airline managers enter wire transfer collection templates into the message integration system. After identifying complex refund scenarios from the original channels, this module matches the corresponding template based on the input contact information, failure scenario, international language, and the message to be notified, constructs the message notification content, and calls the SMS and email systems to send the wire transfer collection notification to the corresponding contact person. During the refund process, passengers may encounter message notifications related to wire transfer collection, refund reminders, and agent work orders. The message integration module determines the message type (SMS, email, and work order system message) and target recipient (passenger, contact person, agent) according to preset rules. The module will automatically construct the message content according to the preset input template, thereby achieving accurate message delivery. If the agent approves the refund, a work order is sent to the work order system, and an email notification is sent to the corresponding agent. If the wire transfer collection is abnormal, the "refund application number," "business channel," and "product type" are transmitted to the abnormal work order system with custom parameters, and the work order processing personnel handle the abnormality.

[0099] According to the original channel refund method based on the OTA data model in this application, the steps include:

[0100] Wire transfer refund steps:

[0101] Step 1: After receiving the refund status notification from the payment platform through the external API interface provided by the original channel refund complex scenario identification module, call the Finite-State Automaton (FSA) to obtain the decision result of the state machine (the status of the refund application form), update the status of the refund application form to the unified order data model, and send a message notification to the passenger through the message integration module.

[0102] Step 2: After receiving the notification message that wire transfer information needs to be collected, the passenger fills in the corresponding person's wire transfer information on the order details page and submits it.

[0103] Step 3: Upon receiving the wire transfer information collection request, the wire transfer information is encrypted by the security module and written into the unified order data model. The wire transfer information collection security mechanism is then removed. Finally, an internal transfer request is initiated based on the different refund exception statuses.

[0104] Step 4: After receiving the internal wire transfer refund request, the wire transfer refund module analyzes the order's refund status and wire transfer information, generates one or more wire transfer refund records based on the corresponding refund status scenario, updates them to the unified order data model, and then sends an internal wire transfer refund request to the payment integration module.

[0105] Step 5: Before initiating a wire transfer refund request to an external party, the security risk control module is used to control the risk of the wire transfer refund request, and suspicious transactions are identified and refunds are delayed.

[0106] Step Six: After receiving the internal request for wire transfer / refund, the payment integration module encrypts the sensitive information through the security module and then initiates an external request for wire transfer / refund to the payment platform. A retry mechanism and a time decay mechanism are used to ensure the security of the wire transfer / refund request.

[0107] Offline advance payment steps:

[0108] Step 1: After receiving the refund status notification from the payment platform via the external API interface provided by the original channel refund complex scenario recognition module, the system calls a Finite-State Automaton (FSA) to obtain the decision result of the state machine (the status of the refund application form), updates the status of the refund application form in the order data structure, and sends a message notification to the passenger. Simultaneously, this order is added to the wire transfer collection guarantee mechanism to ensure the progress of the wire transfer refund. The guarantee mechanism will only be exited after the wire transfer information is successfully collected.

[0109] Step Two: Upon receiving a failed refund message from the payment provider, the passenger selects an offline advance payment application and requests a refund from the offline advance payment interface. An internal offline advance payment request is initiated to the payment integration module, updating the order refund status to "awaiting offline advance payment," recording the passenger's selected offline branch information in the order data, and removing the current order from the wire transfer information collection and protection mechanism.

[0110] This application automatically identifies the specific reasons why passengers are unable to obtain refunds through the original payment channels or where refunds through the original channels fail. It then matches the appropriate refund process, sends notification messages, and provides a self-service option for wire transfer or offline advance payment. It collects wire transfer information or obtains the offline advance payment location selection results, records them in the order, updates the order status, automatically splits the refund amount for wire transfer refunds, and then uses payment integration to construct a refund request and initiate the refund to the payment center. This enables passengers to self-refund in complex scenarios. By enabling self-refunds, it provides passengers with a more convenient refund experience, thereby increasing passenger loyalty to the airline and promoting airline sales growth. Simultaneously, the flexible refund strategy configuration adapts to the diverse refund needs of passengers and meets the operational requirements of the airline, reducing the manpower costs that the airline needs to invest in ensuring passenger refunds.

[0111] Wire transfer refund steps:

[0112] Step 1: For various refund requests, upon receiving the refund status notification, update the order and handle any abnormal refund statuses. Using the external API interface provided by the original channel's complex refund scenario identification module, after receiving the refund status notification from the payment platform, call the Finite-State Automaton (FSA) to obtain the state machine's decision result (the status of the refund request), and update the refund request status in the order data structure. Currently, abnormal refund statuses are categorized into four types: abnormal refund amount (application rejected), refund amount exceeding the limit, payment merchant refund failure, and bank refund failure. These four abnormal refund statuses are handled according to different business processes. (I) Handling the abnormal refund amount (application rejected): Send a work order to the agent to re-approve the refund (revert to the original refund review process and then re-initiate the refund). (II) Handling of three refund statuses: overspending, payment merchant refund failure, and bank refund failure: The order is added to the wire transfer information collection guarantee mechanism. The decision-making mechanism of the wire transfer information collection decision-making module is then invoked to obtain the wire transfer collection method. The order data is then used to locate the corresponding wire transfer information collector's information, and a message notification request is sent to the message notification module. Upon receiving the request, the message notification module matches the SMS / email template and sends a wire transfer information collection reminder message to the passenger. In the case of payment merchant refund failure, the message notification, in addition to reminding the passenger of the wire transfer information collection information, also suggests that the passenger can choose offline advance payment for the refund. The wire transfer information collection guarantee mechanism is triggered every 8 hours, sending a work order to the agent indicating the list of orders for which wire transfer information has not been collected within the time limit. The agent then notifies the passenger again to collect the wire transfer information or initiate offline advance payment.

[0113] Step Two: After receiving the notification message from the message integration module requesting the collection of wire transfer information, the passenger fills in the corresponding wire transfer information on the order details page and submits it. If the payment merchant refund fails, and the passenger chooses a wire transfer refund, the process is the same as the other two refund exception states: the passenger fills in the corresponding wire transfer information on the order details page and submits it. Then, a wire transfer information collection request is sent to the wire transfer information collection module for processing.

[0114] Step 3: Encrypt and write the wire transfer information into the unified order data model. Upon receiving the wire transfer information collection request, the wire transfer information collection module interface verifies its accuracy and then, through the security module, encrypts the wire transfer information and writes it into the unified order data model, removing the wire transfer information collection security mechanism. For refund statuses such as overspending or failed refunds from payment providers, after collecting the wire transfer information, it is added to the wire transfer refund application queue, and an internal wire transfer refund request is constructed and sent to the wire transfer refund module for processing (Step 4). For bank refund failure statuses, after collecting the wire transfer information, it is added to the wire transfer transmission queue, and an internal wire transfer transmission request is constructed and sent to the payment integration module for wire transfer transmission processing (Step 6).

[0115] Step 4: Generate corresponding wire transfer refund records based on wire transfer information and refund information. After receiving the internal wire transfer refund request, the wire transfer refund module analyzes the order's refund status and wire transfer information, and generates one or more wire transfer refund records according to the corresponding refund status scenario: (I) Refund amount overspending refund exception: Obtain the difference between the refundable amount of the original payment record and the order's refundable amount, match it with the wire transfer information, generate a wire transfer refund record, and update it in the unified order data model; (II) Payment merchant refund failure refund exception: 1. If the amount cannot be split by passenger, match all refundable amounts with the wire transfer information, generate a wire transfer refund record, and update it in the unified order data model; 2. If the amount can be split by passenger, sum the refundable amount of the passenger applying for refund across products according to the refund product data, thereby obtaining the total refundable amount corresponding to each passenger, establishing a dataset of the total refundable amount for each passenger, then obtaining the automatic wire transfer splitting amount strategy from the configuration file, matching the wire transfer information to generate a wire transfer refund record according to the refund priority order stipulated by the business, and updating it in the order data. Then, an internal request for wire transfer refund is sent to the payment integration module.

[0116] Step 5: Before initiating a wire transfer refund request externally, the security risk control module calls the risk control center service to identify suspicious transactions. Based on the risk rating, the system retrieves policies or rules from the configuration module, updates the order risk control flag and the delayed refund duration, sets the refund request status to "delayed refund," and adds it to the 1-hour delayed refund queue. This queue polls and processes the queue hourly, and the wire transfer refund request operation continues after the delay expires.

[0117] Step Six: Initiate an external request for wire transfer / refund to the payment platform. After receiving the internal request for wire transfer / refund, the payment integration module constructs an external wire transfer / refund request based on the request information. Sensitive information is encrypted by the security module before being transmitted to the payment platform. The module obtains the response to the wire transfer / refund request and updates it to the order data. Upon successful initiation of the wire transfer / refund, it is removed from the wire transfer queue / refund request queue. If the external interface malfunctions, a retry mechanism and a time decay mechanism are used for protection.

[0118] Offline advance payment steps:

[0119] Step 1: After a passenger fails to obtain a refund through the original channel, the external payment provider notifies the complex scenario identification module for refunds through the original channel. This module updates the unified order data model with information such as rejected refund requests due to abnormal amounts, refunds exceeding budget limits, failed payment requests, and failed bank refunds. It also notifies the agent via a work order to re-apply for a refund if the application was rejected due to abnormal refund amounts. The decision-making mechanism is invoked to determine whether the refund should be processed via wire transfer information from the passenger, the payer, or the customer. The contact information for the current order is retrieved, and the message notification module is invoked, providing the contact's contact information, the failure scenario, and the notification message (the contact's processing method; if the refund failed due to a payment request, the contact can choose wire transfer or offline prepayment for processing at a branch). The system awaits the passenger's next steps. Simultaneously, the order is added to the wire transfer collection guarantee mechanism to ensure the progress of the wire transfer refund. The guarantee mechanism will only be exited after successful collection of wire transfer information.

[0120] Step Two: Upon receiving a refund failure message from the payment provider, the passenger selects an offline advance payment application. They will be redirected to an application page to confirm offline branch information. The default branch information is obtained through the client, assuming the user's consent. If the user wants to modify this, they can choose their own offline branch. After confirming the selection is correct, they click the "Offline Advance Payment Application" button, requesting an offline advance payment refund from the interface. This module receives the request and verifies whether the order meets the offline advance payment refund conditions. If it does, it initiates an internal offline advance payment request to the payment integration module. After a successful response, the payment integration module updates the order refund status to "Waiting for Offline Advance Payment," records the passenger's selected offline branch information in the unified order data model, removes the current order from the wire transfer information collection guarantee mechanism, and prompts the passenger to go to the corresponding branch for an offline refund. If verification fails or other anomalies occur, an error message is displayed to the user. At this point, the order is still under the wire transfer information collection guarantee mechanism. The passenger can choose to collect wire transfer information or resubmit the offline advance payment application as prompted.

[0121] To expand refund channels for wire transfers, this application also includes a wire transfer information collection module. The bank card number, account opening location, bank name, and cardholder's name information to be collected can be replaced with personal bank card information, overseas e-wallets, or the recipient's wallet address for virtual currencies. Through these functions, this application not only supports convenient refunds for international travelers, addressing their current needs, but also, as cryptocurrencies gradually become a settlement method, can accommodate convenient refunds for emerging currencies in the future.

[0122] This application also provides a computer-readable storage medium in which a computer program can be stored. When executed, the computer program may include the processes described in the embodiments of the methods above. Any references to memory, storage, databases, or other media used in the embodiments provided in this application may include at least one of non-volatile and volatile memory. Non-volatile memory may include read-only memory (ROM), magnetic tape, floppy disk, flash memory, or optical storage, etc. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM may take many forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc.

[0123] This application proposes a method and its implementation for supporting self-service refunds through the original channel in complex situations, enabling travelers to easily conduct self-service refunds in complex circumstances.

[0124] 1. This application provides ordinary passengers with a variety of refund options, addressing the issue of unavailability of self-service refunds through conventional channels. It allows passengers to choose the most convenient refund method, aiming to shorten the refund process time and improve the passenger self-service refund experience.

[0125] 2. If the original refund channel cannot be processed normally, the system will obtain the reason and automatically match the refund process. The system will send a message notification to the passenger through the message integration module to collect wire transfer information or select the agent outlet. After collecting the information provided by the passenger, the system will match the corresponding process to complete the refund and design a guarantee mechanism to ensure the final refund is successful.

[0126] 3. To address the issue of resolving refund amount splitting, this application also provides an automatic refund amount splitting function. By analyzing the payment and refund information stored in the order, combined with the refund request submitted by the passenger, and in accordance with the airline's established splitting policy, the refund amount is automatically split. This not only optimizes the passenger's self-service refund experience but also ensures the smooth implementation of the airline's refund policy and safeguards the airline's interests.

[0127] In addition to the three core implementations mentioned above, this application also employs advanced encryption and de-identification technologies to ensure the security of passengers' sensitive information; simultaneously, it implements a real-time risk control mechanism to strictly protect funds and effectively prevent cash-out activities. By continuously optimizing the passenger self-service refund experience, this application helps to increase user stickiness, thereby driving airline profit growth.

[0128] Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for refunding payments through the original channel based on an OTA data model, comprising the following steps: The decision-making process for collecting wire transfer information involves determining the highest priority collection method based on the provided orders and the wire transfer information collection strategy. The steps for identifying complex scenarios of refunds through the original channel are as follows: Use a finite state automaton to process different refund states, call the API interface to receive refund status update notifications, and pass the received notifications to the finite state automaton receiver and converter to trigger state transitions, send a message notification to the passenger, and allow the passenger to choose a refund method; If the passenger chooses wire transfer refund, the wire transfer information collection step will be carried out. The wire transfer information submitted by the passenger will be received and verified through the wire transfer information collection interface. After the verification is successful, the wire transfer information will be updated into the unified order data model. The process will be transferred to the subsequent refund process by sending an internal request to carry out the wire transfer refund step. The portion of the amount that could not be refunded through the original channel will be refunded to the bank account designated by the passenger via wire transfer. If the passenger chooses to make the payment offline, the offline refund process will be carried out. The passenger can choose a service point to complete the offline refund. The payment integration information step involves receiving a corresponding request, encrypting the sensitive information in the request, and then initiating an external request for wire transfer / wire transfer refund to the payment platform.

2. The method according to claim 1, characterized in that, Further steps include: Security measures include verifying the identity of the person requesting a refund, desensitizing and encrypting sensitive passenger information, and preserving a complete transaction history. The security risk control steps include real-time risk control, accurate rating, delayed refunds, and real-time updates to risk control strategies to identify and process suspicious refunds. In the message integration process, during the refund process, passengers receive notifications of wire transfer collection, refund reminders, and agent work orders. The system determines the message type and target recipient, and automatically constructs message content according to a preset input template to achieve accurate message delivery.

3. The method according to claim 2, characterized in that, The wire transfer information collection and decision-making steps further include: The scenarios that support the collection of wire transfer information are three: refund amount exceeding the limit, payment merchant refund failure, and bank refund failure. In the scenarios of refund amount exceeding the limit and payment merchant refund failure, all methods are supported for collecting wire transfer information, while in the scenario of bank refund failure, only the methods of payer and customer are supported for collecting wire transfer information. Based on the business scenario of the order data, determine the supported collection methods, analyze the orders, and collect data according to the passenger if there is a passenger; if there is no passenger but there is a payer, collect data according to the payer; if there is neither a passenger nor a payer, collect data according to the contact person. If the order involves a failed bank refund, the decision-making process begins with the payer. If it is a scenario where wire transfer information is collected again, it needs to be compared with the previous collection method in the order. If it is a collection method with the same priority, it needs to be downgraded by one level.

4. The method according to claim 3, characterized in that, The steps for identifying complex scenarios of refunds from the original channel further include: The refund status update notification information indicates whether the review was rejected, the payment provider's refund failed, or the bank's refund failed. The data processing action retrieves all information related to a specific refund order and updates the order data with the refund order data. The decision-making mechanism is invoked to determine whether a refund should be issued based on the wire transfer information of the passenger, the payer, or the customer; at the same time, the order is added to the wire transfer collection guarantee mechanism to ensure the progress of the wire transfer refund.

5. The method according to claim 4, characterized in that, The wire transfer information collection step further includes: When a refund anomaly occurs and the passenger chooses to have their wire transfer information collected, the wire transfer information is collected, verified, and written into the unified order data model. Receive unified XML requests based on the OTA data model; By comparing the collection method in the request with the collection method returned by the telegraphic transfer information collection decision mechanism, the correctness of the telegraphic transfer information collection and content can be verified. After verification, the wire transfer information is encrypted and written into the unified order data model through the security module. In the case of refund overspending or payment merchant refund failure, an internal wire transfer refund request is initiated. In the case of bank refund failure, an internal wire transfer transmission request is initiated for subsequent processing.

6. The method according to claim 5, characterized in that, The wire transfer refund process further includes the following steps: By calling the API interface of the external payment provider provided in the original channel refund complex scenario identification step, after receiving the refund status notification from the payment platform, the finite state automaton is called to obtain the decision result of the state machine, the status of the refund application is updated to the unified order data model, and a message notification is sent to the passenger. After receiving a notification message that wire transfer information needs to be collected, passengers fill in the corresponding wire transfer information on the order details page and submit it. Upon receiving a wire transfer information collection request, the wire transfer information is encrypted and written into a unified order data model through the security measures. Internal wire transfer information requests are then initiated based on different refund anomaly statuses. After receiving the internal request for wire transfer refund, the wire transfer refund step analyzes the order's refund status and wire transfer information, generates a wire transfer refund record based on the corresponding refund status scenario, updates it to the unified order data model, and initiates an internal request for wire transfer refund to the payment integration information step. After receiving the internal request for wire transfer information or the internal request for wire transfer refund, the payment integration information step encrypts the sensitive information through the security protection step and then initiates an external request for wire transfer / wire transfer refund to the payment platform.

7. The method according to claim 6, characterized in that, The offline advance refund process further includes the following steps: After receiving the refund status notification from the payment platform, the finite state automaton is invoked to obtain the decision result of the state machine, and the status of the refund application is updated in the order data structure; When a passenger receives a refund failure message from the payment provider, they can choose to apply for offline advance payment. This will initiate an internal request for offline advance payment to the payment integration module, update the order refund status, and record the offline branch information selected by the passenger into the order data.

8. The method according to claim 7, characterized in that, The payment integration information step further includes the following steps: Upon receiving a request, the system uses reflection to quickly locate and activate the corresponding processing logic entry point; it establishes a wire transfer refund application queue, a wire transfer transmission queue, and an offline advance payment exception handling queue; once an exception is encountered when calling the payment platform API, the relevant request will be automatically added to the exception handling queue, triggering the built-in interface retry mechanism Retry Mechanism; if it fails again, the Time Decay strategy will intervene.

9. A refund system based on an OTA data model for original channel transactions, used to implement the method according to any one of claims 1 to 8, characterized in that, The system includes: The wire transfer information collection decision module determines the highest priority collection method based on the provided orders and wire transfer information collection strategies. The original channel refund complex scenario recognition module uses a finite state automaton to handle different refund statuses. It receives refund status update notifications by calling the API interface of an external payment provider and passes the received notifications to the state machine receiver and converter to trigger state transitions. The wire transfer information collection module receives and verifies the submitted wire transfer information through the wire transfer information collection interface. After the verification is successful, the wire transfer information is updated into the unified order data model and then transferred to the subsequent refund process by sending an internal request. The wire transfer refund module will refund the portion of the amount that could not be successfully withdrawn through the original channel to the passenger's designated bank account via wire transfer. The offline refund module allows passengers to choose a service point and complete the offline refund process. After receiving the corresponding request, the payment integration information module encrypts the sensitive information in the request and then initiates an external request for wire transfer / wire transfer refund to the payment platform.

10. A computer-readable storage medium storing one or more programs, characterized in that, When one or more of these programs are executed, the original channel refund method based on the OTA data model as described in any one of claims 1-8 can be implemented.

Images