Original channel refund method and system based on OTA data model and storage medium

Abstract

The invention provides an original channel refund method and system based on an OTA data model and a storage medium. The original channel refund method comprises the following steps: a power convergence information collection decision-making step; an original channel refund complex scene recognition step; an electric bus information collection step; an electric bus refund step; an offline substitute pad refund step; and a payment integration information step: receiving a corresponding request, encrypting sensitive information in the request, and initiating an external request for power transfer / power transfer refund to a payment platform. According to the method, self-service refund services of electricity bus refund and offline replacement advance are provided, so that the whole-process self-service operation of passengers is realized, the dependence on manual customer service is reduced, and the refund process is simplified; by implementing sensitive information level protection, the data security is improved.

Description

Technical Field

[0001] The present application belongs to the field of computer data processing technology, and in particular, relates to an original channel refund method, system and storage medium based on an OTA data model. Background Art

[0002] In recent years, with the vigorous development of the aviation industry, the passenger ticket purchasing experience has achieved a qualitative leap, and the ticket purchasing channels have been significantly diversified, covering official websites, OTA travel platforms and third-party agent platforms, providing passengers with a rich variety of choices. In the payment process, passengers can not only enjoy convenient and efficient payment services, but also flexibly choose from a variety of payment products according to their personal preferences. Some products support personalized combination configuration, which greatly improves the flexibility and satisfaction of payment. In the face of refund needs, in order to ensure that consumer rights are fully protected, the "Consumer Rights Protection Law of the People's Republic of China" and related regulations clarify the right to return goods within seven days without reason in online shopping, and extend this principle to the field of airline tickets, requiring merchants to respond quickly and efficiently after receiving refund applications to ensure that the money can be returned to passengers in a timely and safe manner. It is worth noting that although the law does not stipulate that refunds must be made through the original channel, in actual operation, "refunds through the original channel" has become a common practice in the industry and has established good practices in many business fields. This practice not only simplifies the refund process and improves efficiency, but also enhances consumers' trust and recognition of airline ticketing services.

[0003] The diversification of ticket purchase channels and payment methods, while bringing convenience, also increases the complexity and challenges of refunds through the original channels. Specifically, passengers may face problems such as the original payment method being deactivated, being unable to be recognized by the system, changes in bank account or payment account information, and temporary failures in the payment institution or bank system, which may hinder the refund process. In response to these problems, some domestic airlines still use manual judgment, filling out application forms, and work order circulation to solve them. With the increase in business volume, manual operation has the following limitations:

[0004] Cumbersome process: After a failed attempt to get a refund through the original payment channel, passengers need to fill out a paper or electronic refund application form through customer service. These forms contain a lot of information, such as order details, refund reason, identity proof, etc., and may require multiple confirmations and modifications. After submission, the refund application enters the manual processing process, involving the circulation and approval of multiple departments, which prolongs the refund processing time.

[0005] Poor quality of information transmission: When manually processing refunds, information may be lost or mis-transmitted at multiple stages. Due to the lack of a unified information management system, information sharing between different departments is not smooth, which increases the difficulty of refund processing. This may result in passengers receiving the wrong refund amount or the refund status being updated in a timely manner.

[0006] Weak security protection: When relying on manual operations, passengers' sensitive information (such as bank accounts, payment passwords, etc.) faces a high risk of leakage during transmission and storage. The manual processing process may lack effective security audit and monitoring mechanisms, making it difficult to detect and respond to potential security threats in a timely manner. Once information leakage occurs, it may lead to serious financial losses and reputation damage.

[0007] Manual 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 cash-out risks.

[0008] In summary, there are deficiencies in the original channel refund function of airlines under existing complex scenarios. After the ordinary original channel refund fails, passengers need to go through the counter and manual customer service to complete the subsequent refund process, which not only increases the airline's costs and complaint rate, but also brings inconvenience to customers during the refund process. Summary of the invention

[0009] In response to the deficiencies in the existing technology, this application provides a service for refunding the original channel in complex scenarios, supporting a variety of refund methods to choose from, including wire transfer refunds, offline advance payments, and cross-channel order refunds, covering refunds for tickets booked through direct sales channels (official websites, mobile apps, WeChat public accounts) and distribution channels (agents, third-party booking websites); supporting refunds for mixed payment orders (bank card + cash, card vouchers, coupons); supporting refunds for any tickets in the same order; supporting multi-dimensional configuration of refund strategies (matching refund process strategies based on refund reasons, refunder priority configuration strategies, and automatic splitting strategies for wire transfer amounts), and supporting data security and financial security. While reducing airline operating costs, it provides passengers with a simpler and more convenient refund experience, thereby achieving the goal of improving customer satisfaction.

[0010] The first aspect of the present application provides an original channel refund method based on an OTA data model, comprising the following steps:

[0011] The decision-making step for collecting wire transfer information is to determine the collection method with the highest priority according to the provided order and the strategy for collecting wire transfer information;

[0012] The steps for identifying complex refund scenarios in the original channel are as follows: use finite state automata to process different refund states, call the API interface to receive refund state update notification information, and pass the received notification information to the state machine receiver and converter to trigger state transfer;

[0013] The wire transfer information collection step receives and verifies the submitted wire transfer information through the wire transfer information collection interface. After the verification is passed, the wire transfer information is updated to the unified order data model and transferred to the subsequent refund process by sending an internal request;

[0014] Wire transfer refund step: the part of the amount that cannot be successfully withdrawn through the original refund channel will be refunded to the bank account designated by the passenger by wire transfer;

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

[0016] The payment integration information step receives the corresponding request, encrypts the sensitive information in the request, and then initiates an external request for wire transfer transmission / wire transfer refund to the payment platform.

[0017] Further, the following steps are included:

[0018] Security assurance steps include identity authentication for refunders, desensitization and encryption of passenger sensitive information, and preservation of complete operation history;

[0019] Security risk control steps, identifying and handling suspicious refunds through real-time risk control, accurate rating, delayed refunds and real-time update of risk control strategies;

[0020] In the message integration step, during the refund process, passengers receive wire transfer collection, refund reminders, and agent work order message notifications, determine the message type and target recipient, and automatically construct the message content according to the preset entry template to achieve accurate message push.

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

[0022] The scenarios that support the collection of wire transfer information include refund amount overrun, refund failure by payer, and refund failure by bank. For the refund amount overrun and refund failure scenarios, all methods of wire transfer information collection are supported, while for the bank refund failure scenario, only the payer and customer methods of wire transfer information collection are supported.

[0023] Get the supported collection methods based on the business scenario of the order data, analyze the order, and collect data by passenger if there is a passenger; collect data by payer if there is no passenger; collect data by contact if there is no passenger or payer;

[0024] If the order is a bank refund failure scenario, the decision-making starts with the payer;

[0025] If you are collecting wire transfer information again, you need to compare it with the last collection method in the order. If they are collection methods of the same priority, you need to downgrade it by one level.

[0026] Furthermore, the above steps for identifying complex refund scenarios in the original channel include:

[0027] The refund status update notification information is the status of review rejection, payment provider refund failure or bank refund failure;

[0028] Data processing action Act ion, retrieves all information related to a specific refund order, and updates the refund order data to the order data;

[0029] The decision-making mechanism is called to determine whether the refund should be made through the wire transfer information of the passenger, the payer, or the customer; at the same time, this order is added to the wire transfer collection and guarantee mechanism to ensure the progress of the wire transfer refund.

[0030] Furthermore, the above-mentioned wire transfer information collection steps include:

[0031] When a refund exception occurs and the passenger chooses to collect wire transfer information, the wire transfer information will be collected, verified and written into the unified order data model;

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

[0033] Compare the collection method in the request with the collection method returned by the wire transfer information collection decision mechanism to verify whether the wire transfer information collection and content are correct;

[0034] After the verification is passed, the wire transfer information will be encrypted through the security module and written into the unified order data model. If the refund amount exceeds the limit or the payment provider fails to refund, an internal wire transfer refund request will be initiated. If the bank refund fails, an internal wire transfer transmission request will be initiated for subsequent processing.

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

[0036] The external payment provider provided in the step of identifying the complex refund scenario of the original channel calls the API interface, and after receiving the refund status notification from the payment platform, calls the finite state automaton to obtain the decision result of the state machine, updates the status of the refund application form to the unified order data model, and sends a message notification to the passenger;

[0037] After receiving the prompt message that requires collecting wire transfer information, the passenger fills in the wire transfer information of the corresponding person in the prompt message on the order details page and submits it;

[0038] The wire transfer information collection step receives a wire transfer information collection request, encrypts the wire transfer information through the security step and writes it into a unified order data model, and initiates an internal request for wire transfer information according to different refund abnormal states;

[0039] After receiving the internal request for wire transfer refund, the wire transfer refund step analyzes the refund status and wire transfer information of the order, generates a wire transfer refund record according to 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 step and then initiates an external request for wire transfer transmission / wire transfer refund to the payment platform.

[0041] Furthermore, the above-mentioned offline advance refund steps include the following steps:

[0042] 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, and the status of the refund application form is updated to the order data structure;

[0043] When the traveler receives a message from the payment provider that a refund has failed, he or she chooses to apply for offline advance payment, initiates an internal request for offline advance payment to the payment integration module, updates the order refund status, and records the offline branch information selected by the traveler in the order data.

[0044] Furthermore, the above payment integration information step includes the following steps:

[0045] After receiving the request, the reflection mechanism is used to quickly locate and activate the corresponding processing logic entry; a wire transfer refund application queue, a wire transfer transmission queue, and an offline advance payment exception processing queue are established; once an exception is encountered when calling the payment platform API, the relevant request will be automatically added to the exception processing 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 the present application provides an original channel refund system based on an OTA data model, the system comprising:

[0047] The wire transfer information collection decision module determines the collection method with high priority according to the provided order and wire transfer information collection strategy;

[0048] Original channel refund complex scenario recognition module: Use finite state automata to handle different refund states, call the API interface through external payment providers, receive refund status update notification information, and pass the received notification information to the state machine receiver and converter to trigger state transfer;

[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 passed, the wire transfer information is updated to the unified order data model and transferred to the subsequent refund process by sending an internal request;

[0050] The wire transfer refund module will refund the part of the amount that cannot be successfully withdrawn through the original channel to the bank account designated by the passenger by wire transfer;

[0051] Offline advance refund module: passengers can choose a service outlet to complete the offline refund operation;

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

[0053] The third aspect of the present application provides a computer-readable storage medium storing one or more programs, which, when executed, can implement an original channel refund method based on an OTA data model.

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

[0055] First, by providing self-service refund services such as wire transfer refunds and offline advance payments, passengers can operate the entire process by themselves, reduce reliance on manual customer service, and simplify the refund process;

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

[0057] Furthermore, the service is flexible and optional, allowing passengers to choose the refund method, channel and recipient to meet different needs. In addition, information security is strengthened, sensitive information is protected at different levels, data security is ensured, and operation history is fully recorded.

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

[0059] Other features and advantages of the present application will be described in the following description, and partly become apparent from the description, or be understood by practicing the present application. The purpose and other advantages of the present application can be realized and obtained by the structures indicated in the description, claims and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0060] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

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

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

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

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

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

[0066] Figure 6 Shows a block diagram of the wire transfer information collection decision machine module;

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

[0068] Figure 8 A block diagram of the offline advance payment module is shown. DETAILED DESCRIPTION

[0069] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0070] In order to better understand the professional terms and abbreviations involved in this application, the professional terms and abbreviations involved in this application are explained as follows:

[0071] Collecting wire transfers: Collecting bank card numbers, cardholder names and other information from travelers to refund the refundable items to the bank account.

[0072] Payment center: It is a network transfer platform that aims to meet the various payment needs of users, interact with banks, payment providers, etc., and provide safe and convenient payment services.

[0073] Risk Control Center: Risk Control Center, full name is Risk Control Center. Its main responsibility is to manage and control business risks through various means and methods to reduce or avoid the occurrence of risk events and ensure the normal operation of business and asset security.

[0074] Agent: refers to a customer service representative operated by a real person who communicates with customers in real time to solve problems or provide support.

[0075] SPNR: XML data model built based on OTA's data model, used to store order data information.

[0076] The original channel refund method based on the OTA data model of this application is as follows Figure 1 As shown, the payment platform receives the refund status notification, the system identifies the original channel complex scenario, 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 the wire transfer information, and the other is when the passenger chooses an offline advance payment outlet. When the passenger submits the wire transfer information, first determine whether the wire transfer information is correct. If it is passed, update the wire transfer information to the order database, generate a wire transfer refund record, and update the wire transfer refund record to the order database to determine whether there is a security risk. If there is a security risk, initiate a wire transfer transmission / wire transfer refund request and send the request to the payment platform.

[0077] When a passenger selects an offline advance payment outlet, a refund record for the advance payment is generated, the refund record is updated to the order database, and an offline advance 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, the following steps are included:

[0079] The decision-making step for collecting wire transfer information is to determine the collection method with the highest priority according to the provided order and the strategy for collecting wire transfer information;

[0080] The steps for identifying complex refund scenarios in 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 notification information, and pass the received notification information to the state machine receiver and converter to trigger state transfer;

[0081] The wire transfer information collection step receives and verifies the submitted wire transfer information through the wire transfer information collection interface. After the verification is passed, the wire transfer information is updated to the unified order data model and transferred to the subsequent refund process by sending an internal request;

[0082] Wire transfer refund step: the part of the amount that cannot be successfully withdrawn through the original refund channel will be refunded to the bank account designated by the passenger by wire transfer;

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

[0084] The payment integration information step receives the corresponding request, encrypts the sensitive information in the request, and then initiates an external request for wire transfer transmission / wire transfer refund to the payment platform.

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

[0086] Among them, the ERC-Decision mechanism for collecting telegraphic remittance information (ERC-Decision mechanism) aims to derive a high-priority collection method based on the provided order and telegraphic remittance information collection strategy. It makes decisions based on the priorities of collecting by passengers, paying persons, and contact persons according to business needs and the collection methods supported by business scenarios, and provides a feasible and optimal telegraphic remittance information collection method. The collection methods include collecting by passengers (passenger), collecting by payers (payer), and collecting by contact persons (customer). The inherent priorities are: passengers are level 1, payers are level 2, and customers are level 3. Level 1 is the highest priority, followed by level 2, and level 3 is the lowest. The scenarios that support wire transfer collection include refund amount overrun, payer refund failure, and bank refund failure. According to business restrictions, in the scenarios of refund amount overrun and payer refund failure, all methods of wire transfer information collection are supported, while in the scenario of bank refund failure, only payer and customer methods of wire transfer information collection are supported. Under the above rules, the supported collection methods are obtained according to the business scenario of the order data, and the order is analyzed. If there are passengers, the information is collected by passengers; if there are no passengers but there are payers, the information is collected by payers; if there are neither passengers nor payers, the information is collected by contacts. If the order is a bank refund failure scenario, the decision is made starting from the payer. Finally, if the scenario of collecting wire transfer information again is to compare it with the last collection method in the order, and if it is a collection method of the same priority, it needs to be downgraded.

[0087] Complex scenario recognition module for original channel refund: Figure 4As shown in the figure, different refund states are processed by using a finite-state automaton (FSA). An external payment provider is provided with an API interface to receive refund status update notifications from the external system, such as audit rejection, payment provider refund failure, and bank refund failure. The received notification information is passed to the state machine receiver (Acceptors) and converter (Transducers) to trigger state transition (Transition). According to the decision result of the state machine, the refund order data is updated, and the abnormal audit rejection of the refund amount, the refund amount overrun, the payment provider refund failure, and the bank refund failure status are updated to the order data, and a message notification or work order for wire transfer collection or agency point selection is sent to the passenger or seat. At the same time, a wire transfer collection guarantee mechanism is provided, and the order is added to the guarantee mechanism to guarantee the progress of the wire transfer refund. The guarantee mechanism will not be exited until the wire transfer information is successfully collected.

[0088] Specifically, in the complex scenario identification module of the original channel refund, data processing actions are performed to retrieve all information related to a specific refund order, including order status, refund amount, etc. According to the decision result of the state machine, the refund order data is updated, and the abnormal refund amount, refund amount overrun, payment provider refund failure, bank refund failure status are updated to the order data, and the situation of review rejection due to abnormal refund amount is notified through the work order to re-review the refund to reflect the latest processing progress. The decision-making mechanism is called to determine whether the refund should be made through the wire transfer information of the passenger, the order payer, or the order contact person. If the refund is based on the passenger's wire transfer information, obtain the passenger involved in the refund in the current order, and inform the contact person that the wire transfer information of the passenger in the list needs to be collected; if the refund is based on the payer, obtain the payer of the current order, and inform the contact person that the wire transfer information of the payer needs to be collected. If there are multiple payers, let him choose one of them; if the refund is through the contact's wire transfer information, inform the contact person to provide a wire transfer information; obtain the contact information of the current order, call the message notification module, pass in the contact person's contact information, failure scenario, and the message to be notified (the contact person's processing method, and if the refund fails due to the payer, you can choose to refund by wire transfer, or choose the refund method of offline advance payment to process the refund at the offline outlet), and wait for the passenger to proceed to the next step. At the same time, add this order to the wire transfer collection guarantee mechanism to ensure the progress of the wire transfer refund. This mechanism uses a passenger wire transfer information collection queue for protection. The automatic process of executing this queue is set to be triggered every 8 hours. Each time it is triggered, it is necessary to determine whether the orders in the queue have collected wire transfer information within the configured time limit (dynamically obtain the real-time configuration time limit, generally 24 hours). If an order has not been collected beyond the time limit, the message notification integration module will be called to send a work order notification to the seat supervisor to send a list of orders that have not been collected due to the timeout. The seat will notify the passenger to collect it in time. The protection mechanism will not be exited until the wire transfer information is successfully collected.

[0089] The wire transfer information collection module receives the wire transfer information submitted by the passenger through a unified wire transfer information collection interface. Specifically, the interface receives a unified XML request based on the OTA data model. The request needs to construct the order number, the enumeration value of the business scenario to be wired, the refund information and the wire transfer information collection, etc. The wire transfer information includes the wire transfer information serial number, the serial number of the associated person, the bank card number, the account opening location, the account opening bank, the cardholder's name and other information. When a refund exception occurs and the passenger chooses to collect the wire transfer information, such as Figure 5As shown in the figure, this module collects and verifies the wire transfer information and writes it into the unified order data model. This module is responsible for collecting wire transfer information in three scenarios: refund amount overrun, payment provider refund failure, and bank refund failure; it verifies the wire transfer information based on the collection method, order data, and input; after verification, it updates the wire transfer information to the unified order data model and transfers it to the subsequent refund process by sending an internal request. The wire transfer information collection decision mechanism module is shown in the figure. Figure 6 As shown,

[0090] Wire transfer information collection module, such as Figure 6 As shown, the collection method in the wire transfer information request submitted by the order contact is compared with the collection method returned by the wire transfer information collection decision mechanism to verify whether the wire transfer information collection method is correct. In addition, it is necessary to verify whether the wire transfer information content is correct. After the verification is passed, the wire transfer information is encrypted and built into the database through the security module (written into the unified order data model) and the wire transfer information collection and protection mechanism is exited. If the refund amount is overspent and the payment provider fails to refund, an internal request for wire transfer refund is initiated. If the bank refund fails, an internal request for wire transfer transmission is initiated and transferred to the subsequent process. If the verification fails, a response is given to the passenger according to the verification content.

[0091] The wire transfer refund module is responsible for refunding the amount that cannot be successfully withdrawn through the original channel to the bank account designated by the passenger by wire transfer. Figure 7 As shown, first accept the order control transferred by the wire transfer information collection module, and obtain the corresponding unified order data model from the database, and obtain the information required in the wire transfer amount splitting process according to the unified order data model. Then identify the refund failure exception type from the unified order data model, and classify and split the amount that needs to be refunded by wire transfer according to the refund failure exception type. If the wire transfer amount needs to be split according to the passenger, it is also necessary to obtain the corresponding wire transfer automatic split amount strategy from the configuration file, and split the wire transfer refund amount according to the specified strategy. Then match the split wire transfer refund amount with the wire transfer information one by one, generate the corresponding wire transfer refund record and put it into the database. Finally, initiate a refund application to the payment module and transfer the order control.

[0092] The refund failure exception type is further refined into the following situations: 1. If the exception type is "refund amount overrun". It is necessary to obtain the refundable amount of the original payment record based on the exception error information, and then obtain the refundable amount of the order. The difference between the two is the wire transfer refund amount, and after matching it with the wire transfer information, a wire transfer refund record is generated and updated to the unified order data model. 2. If the exception type is "payer refund failed". First, it is necessary to determine whether the refundable amount can be split by passenger. If the amount cannot be split by passenger, all refundable amounts are matched with the wire transfer information, and a wire transfer refund record is generated and updated to the unified order data model. If the amount can be split by passenger, then in the products that have applied for refund, the refundable amount of the passenger who applied for refund is summed across products, so as to obtain the total refundable amount corresponding to each passenger, and establish a total refundable amount data set for each passenger. Then, the corresponding automatic split amount strategy of wire transfer is obtained from the configuration file, which can be specifically divided into: Strategy 1, fixed configuration priority strategy, that is, the refund priority of payment products of different payment providers in the configuration file shall prevail; Strategy 2, payment time priority strategy, that is, the payment time of the payment record is used as the refund priority according to the logic of first refund after payment; Strategy 3, weight priority strategy, that is, the numerical value of the payment amount of the payment record is used as the refund priority. Then, according to the refund priority, the high-priority payment products in the payment record are first split according to the proportion of the associated passengers in the payment record to obtain the refundable amount. If the refundable amount is less than the total amount to be refunded by the passenger, a wire transfer refund record is generated after matching the corresponding wire transfer information based on the split refundable amount, and the amount is deducted from the total amount to be refunded by the passenger; continue to repeat the above operation from the payment record of the next priority until the split refundable amount is greater than the remaining amount to be refunded by the passenger, then a wire transfer refund record is generated after matching the corresponding wire transfer information based on the remaining amount to be refunded by the passenger at this time. The wire transfer refund records generated in the whole process need to be updated to the unified order data model. Finally, an internal request for a refund application is initiated to the payment integration module to transfer control of the order.

[0093] Payment Integration Module: This module has designed a highly efficient internal interface system, which is specially used to receive requests from business modules such as wire transfer collection, wire transfer refund and offline advance payment. After receiving these requests, it uses the reflection mechanism to quickly locate and activate the corresponding processing logic entry. Specifically, it calls the interface provided by the payment platform through the HTTP protocol to realize the call between services.

[0094] Furthermore, this module specifically introduces the wire transfer refund application queue, wire transfer transmission queue, and offline advance payment exception processing queue. These queues use the 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 processing queue, triggering the built-in interface retry mechanism (RetryMechani sm). If it fails again, the time decay (Time Decay Mechani sm) strategy will intervene to improve the efficiency and stability of transaction processing.

[0095] Offline advance refund module, such as Figure 8 As shown in the figure, the refund of offline advance payment is that the system returns the refundable items to the designated outlets, and the passengers go to the outlets to collect them by themselves. It is a stable refund method that will definitely succeed in refunding. When the refund exception scenario occurs where the payment provider fails to refund, the passenger will receive a text message prompt from the message integration module, and can choose to collect wire transfers or apply for offline advance payment on the operation page. When the passenger chooses to apply for offline advance payment, he will jump to the application page to confirm the offline outlet information. The default outlet information is the user's geographic location data obtained through the client with the user's consent. If the user wants to modify it, he can choose the offline outlet himself. After selecting correctly, click the offline advance payment application button to request the offline advance payment refund interface. The module receives the request and verifies whether the order meets the conditions for offline advance payment refund. If it does, it will initiate an internal request for offline advance payment to the payment integration module. After the payment integration module responds successfully, it updates the order refund status to "waiting for offline advance payment", and records the offline outlet information selected by the passenger in the unified order data model, removes the wire transfer information collection guarantee mechanism from the current order, and responds and prompts the passenger to go to the corresponding outlet for offline refund. If verification or other abnormalities occur, the error message will be prompted to the user. At this time, the order is still in the wire transfer information collection and protection mechanism. The passenger can choose to collect the wire transfer information or submit an offline advance payment application again according to the prompt. This service innovatively allows passengers to choose the nearest service outlet to complete the offline refund operation, providing users with a more flexible and convenient refund solution.

[0096] Security Assurance Module: This module is designed mainly from three aspects: refund channel verification, refunder identity authentication, passenger sensitive information level protection, and data audit; 1. Refund channel verification: Ensure that all refund operations are only carried out through channels pre-configured and allowed by the system, so as to effectively prevent unauthorized refund channels. 2. Authentication of refunders (passengers, payers, contacts) 3. Desensitization and encryption protection of passenger sensitive information (name, contact information, identity information, bank card number) according to level protection requirements; 4. Save complete operation history, each operation can be traced back, and support security audit. Specifically, this module encrypts and transmits passenger ticket number, order number, passenger identity information, and wire transfer collection information through AES encryption algorithm. After the query interface receives the information, it extracts the relevant order to verify the passenger identity and channel, and verifies whether the order meets the conditions of wire transfer or advance payment. If it meets the conditions, it initiates subsequent processing, generates a unique operation log for each refund operation, records key information such as refunder information, refund amount, refund time, refund method, etc., and records it in the unified order data model, and uses AES encryption to store important information such as bank cards. When checking order details and order refund progress, the passenger's sensitive information will be desensitized and returned through a replacement algorithm.

[0097] Security risk control module: In actual operations, wire transfer refunds and offline advance payments are prone to cash-out risks. When applying for wire transfer refunds, the risk control center service is called to identify suspicious transactions. This module obtains policies or rules from the configuration module based on risk rating, updates the order risk control identification and delayed refund duration, and sets the refund application status to "delayed refund". The processing queue is polled every hour, and the refund operation continues after the expiration. This module mainly uses real-time risk control, accurate rating, delayed refund, real-time update of risk control strategies and other measures to effectively protect funds, reduce cash-out risks, improve risk control efficiency, and efficiently identify and handle suspicious refunds.

[0098] Message integration module: Airline managers enter the wire collection template in the message integration system. After the original channel refund complex scenario identification is completed, this module matches the corresponding template according to the incoming contact information, failure scenario, international language and the message to be notified, builds the message notification content, and calls the SMS and email system to send the wire collection notification to the corresponding contact. During the refund process, passengers are involved in message notifications such as wire collection, refund reminders, and seat work orders. The message integration module determines the message type (SMS, email and work order system message) and the target recipient (passenger, contact person, seat) according to the preset rules. The module will automatically build the message content according to the preset entry template, so as to achieve accurate message push. If the seat refund is reviewed, the work order will be sent to the work order system and an email notification will be sent to the corresponding seat staff. If the wire collection is abnormal, the "refund application number", "business channel" and "product type" will be transmitted to the abnormal work order system in the form of custom parameters, and the work order processing personnel will handle the abnormality.

[0099] According to the original channel refund method based on the OTA data model of this application, the following steps are included:

[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 recognition module, the finite-state automaton (FSA) is called to obtain the decision result of the state machine (the status of the refund application form), the status of the refund application form is updated to the unified order data model, and a message notification is sent to the passenger through the message integration module.

[0102] Step 2: After the passenger receives the prompt message that requires collecting wire transfer information, he / she shall fill in the wire transfer information of the corresponding person in the prompt message on the order details page and submit it.

[0103] Step 3: The wire transfer information collection module interface receives the wire transfer information collection request, encrypts the wire transfer information through the security module and writes it into the unified order data model, and removes the wire transfer information collection security mechanism. Then, an internal circulation request is initiated according to different refund abnormal statuses.

[0104] Step 4: After receiving the internal request for wire transfer refund, the wire transfer refund module analyzes the refund status and wire transfer information of the order, generates one or several wire transfer refund records according to the corresponding refund status scenario, updates them to the unified order data model, and then initiates an internal request for wire transfer refund to the payment integration module.

[0105] Step 5: Before initiating a wire transfer refund application to an external party, perform risk control on the wire transfer refund request through the security risk control module, identify suspicious transactions and delay the refund.

[0106] Step 6: After the payment integration module receives the internal request for wire transfer / wire transfer refund, it encrypts the sensitive information through the security module and then initiates the external request for wire transfer / wire transfer refund to the payment platform. The retry mechanism and time decay mechanism are used to protect the wire transfer / wire transfer refund request.

[0107] Offline advance payment steps:

[0108] 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 recognition module, the Finite-State Automaton (FSA) is called to obtain the decision result of the state machine (the status of the refund application form), and the status of the refund application form is updated to the order data structure, and a message notification is sent to the passenger. At the same time, this order is added to the wire transfer collection guarantee mechanism to guarantee the progress of the wire transfer refund. The guarantee mechanism will not be exited until the wire transfer information is successfully collected.

[0109] Step 2: After receiving the refund failure message from the payment provider, the passenger selects the offline advance payment application and requests the offline advance payment refund interface. The payment integration module initiates an internal request for offline advance payment, updates the order refund status to "waiting for offline advance payment", and records the offline outlet information selected by the passenger in the order data, removing the wire transfer information collection and protection mechanism from the current order.

[0110] Based on the phenomenon that passengers cannot get a refund through ordinary original channels or the refund through ordinary original channels fails, this application automatically identifies the specific reasons, matches the corresponding refund process, sends message notifications, provides self-selection services of wire transfer or offline advance payment, collects wire transfer information or obtains offline advance payment outlet selection results, records it in the order and updates the order status, automatically splits the amount through wire transfer refund, and then builds a refund request through payment integration, initiates a refund to the payment center, and realizes self-service refunds for passengers in complex scenarios. By realizing self-service refunds for passengers, passengers can have a more convenient refund experience, thereby achieving the purpose of improving passengers' user stickiness to airlines and promoting sales growth of airlines. At the same time, the flexible refund strategy configuration not only meets the refund needs of passengers for diversified payments, but also meets the operating requirements of airlines, reducing the manpower costs required by airlines to ensure passenger refunds.

[0111] Wire transfer refund steps:

[0112] Step 1: For various refund orders, after receiving the refund status notification, update the order and handle the refund abnormal status. After receiving the refund status notification from the payment platform through the external API interface provided by the original channel refund complex scenario recognition module, call the finite-state automaton (FSA) to obtain the decision result of the state machine (the status of the refund application form), and update the status of the refund application form to the order data structure. At present, the refund abnormal status is divided into abnormal review rejection of the refund amount, overspending of the refund amount, payment provider refund failure, and bank refund failure. According to these four refund abnormal status, it is handled by business. (I) For the abnormal review rejection status of the refund amount: send a work order to inform the seat to re-review the refund (roll back to the refund review, and then re-initiate the refund). (II) For the three statuses of refund amount overrun, refund failure by payment provider, and refund failure by bank: add the order to the wire transfer information collection guarantee mechanism, then obtain the wire transfer collection method by calling the decision mechanism of the wire transfer information collection decision mechanism module, and then find the information of the corresponding wire transfer information collector through the order data, and then initiate a message notification request to the message notification module. After 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 provider refund failure, the message notification sent not only prompts the wire transfer information collection information, but also prompts the passenger to choose the offline advance payment method for refund. The wire transfer information collection guarantee mechanism is triggered every 8 hours, and a work order is sent to the agent to prompt the order list for which the wire transfer information has not been collected due to timeout. The agent will notify the passenger again to collect the wire transfer information or initiate an offline advance payment.

[0113] Step 2: After receiving the prompt message from the message integration module that requires the collection of wire transfer information, the passenger fills in the wire transfer information of the corresponding person in the prompt message on the order details page and submits it. When the payment provider fails to refund, the passenger chooses the wire transfer refund method. Like the other two refund abnormal states, the wire transfer information of the corresponding person in the prompt is filled in on the order details page. After submission, the wire transfer information collection request is sent to the wire transfer information collection module for processing.

[0114] Step 3: Encrypt the wire transfer information and write it into the unified order data model. The wire transfer information collection module interface receives the wire transfer information collection request, verifies it, encrypts the wire transfer information through the security module and writes it into the unified order data model, and removes the wire transfer information collection security mechanism. For the two refund states of refund amount overrun and payment provider refund failure, after collecting the wire transfer information, join the wire transfer refund application queue, build a wire transfer refund internal request, and request the wire transfer refund module to process the wire transfer refund (step 4); for the bank refund failure refund state, after collecting the wire transfer information, join the wire transfer transmission queue, build a wire transfer transmission internal request, and request the payment integration module to process the wire transfer transmission (step 6).

[0115] Step 4: Generate corresponding wire transfer refund records based on wire transfer information and refund information. After receiving the internal request for wire transfer refund, the wire transfer refund module analyzes the refund status and wire transfer information of the order, and generates one or several wire transfer refund records through the corresponding refund status scenarios: (i) Refund exception due to overspending, obtain the difference between the refundable amount of the original payment record and the refundable amount of the order, match it with the wire transfer information, generate a wire transfer refund record, and update it to the unified order data model; (ii) Refund exception due to payment provider refund failure: 1. If the amount cannot be split by passenger, match all the refundable amounts with the wire transfer information, generate a wire transfer refund record, and update it to the unified order data model; 2. If the amount can be split by passenger, sum the refundable amounts of the passengers who apply for refund across products according to the refund product data, so as to obtain the total refundable amount corresponding to each passenger, establish a total refundable amount data set for each passenger, and then obtain the automatic splitting amount strategy for wire transfer from the configuration file, match the wire transfer information according to the refund priority order specified by the business, generate a wire transfer refund record, and update it to the order data. Then initiate an internal request for wire transfer refund to the payment integration module.

[0116] Step 5: Before initiating a wire transfer refund application to the outside, call the risk control center service through the security risk control module to identify suspicious transactions. According to the risk rating, obtain the policy or rule from the configuration module, update the order risk control identification and the delayed refund time, set the refund application status to "delayed refund", and add it to the delayed refund queue for 1 hour. The queue polls the processing queue every hour, and continues to execute the wire transfer refund application operation after the delay expires.

[0117] Step 6: Initiate an external request for wire transfer / wire refund to the payment platform. After receiving the internal request for wire transfer / wire refund, the payment integration module constructs an external wire transfer / wire refund request based on the request information, encrypts sensitive information through the security module, transmits the wire transfer information / wire refund request to the payment platform, obtains the wire transfer / wire refund application response result and updates it to the order data. After the wire transfer / wire refund is successfully initiated, remove the wire transfer queue / wire refund application queue. If the external interface is abnormal, the retry mechanism and time decay mechanism are used for protection.

[0118] Offline advance payment steps:

[0119] Step 1: After the passenger fails to refund through the original channel, the external payment provider notifies the original channel refund complex scenario identification module, updates the abnormal refund amount review rejection, refund amount overrun, payment provider refund failure, bank refund failure status to the unified order data model, and informs the agent through the work order to re-review the refund due to the abnormal refund amount. Call the decision mechanism to determine whether the refund should be made through the wire transfer information of the passenger, the order payer, or the order contact (customer). Get the contact information of the current order, call the message notification module, pass in the contact information of the contact, the failure scenario, and the message to be notified (contact processing method, and if the refund fails due to the payment provider, you can choose to refund through wire transfer, or choose the refund method of offline advance payment to process the refund at the offline outlet), and wait for the passenger to proceed to the next step. At the same time, add this order to the wire transfer collection guarantee mechanism to ensure the progress of the wire transfer refund. The guarantee mechanism will not be exited until the wire transfer information is successfully collected.

[0120] Step 2: After receiving the payment provider's refund failure message, the passenger chooses to apply for offline advance payment, and will be redirected to the application page to confirm the offline branch information. The default branch information is the user's geographic location data obtained through the client with the user's consent. If the user wants to modify it, he can select the offline branch himself. After selecting correctly, click the offline advance payment application button to request the offline advance payment refund interface. The module receives the request and verifies whether the order meets the offline advance payment refund conditions. If it does, it will initiate an offline advance payment internal request to the payment integration module. After the payment integration module successfully responds, it updates the order refund status to "waiting for offline advance payment", and records the offline branch information selected by the passenger in the unified order data model, removes the current order from the wire transfer information collection and protection mechanism, and responds and prompts the passenger to go to the corresponding branch for offline refund. If the verification or other abnormalities occur, the error message will be prompted to the user. At this time, the order is still in the wire transfer information collection and protection mechanism. The passenger can choose to collect the wire transfer information or submit the offline advance payment application again according to the prompt.

[0121] In order to expand the refund channels for wire transfer refunds, this application also includes a wire transfer information collection module, in which the bank card number, account opening location, account opening bank, and cardholder name information in the wire transfer information that needs to be collected can be replaced with personal bank card information, overseas electronic wallets, and virtual currency recipient wallet addresses. Through the above functions, this application can not only support the convenient refunds of current overseas tourists based on the refund needs of international travelers. As cryptocurrency gradually becomes one of the settlement methods, it can also be compatible with the convenient refunds of emerging currencies in the future.

[0122] The present application embodiment also provides a computer-readable storage medium, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the process of the embodiment of each method as described above. Among them, any reference to the memory, storage, database or other medium used in the embodiments provided in the present application can 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 memory, etc. Volatile memory may include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc.

[0123] This application proposes a method and implementation to support self-service refunds through the original channel in complex situations, so that passengers can easily perform self-service refunds in complex situations.

[0124] 1. This application provides ordinary passengers with a variety of refund options, which solves the problem that the refund through the regular original channels cannot meet the self-service refund needs. Passengers can choose the most convenient refund method through their own choice, aiming to shorten the refund process time and improve the passengers' self-service refund experience.

[0125] 2. When the refund through the original general channel cannot be carried out normally, the system obtains the reason and automatically matches the refund process. Through the message integration module, it sends a message notification to the passenger for wire transfer collection or agent outlet selection. After collecting the information provided by the passenger, it matches the corresponding process to complete the refund and designs a guarantee mechanism to ensure the final success of the refund.

[0126] 3. When solving the refund amount splitting problem, 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 according to the established splitting policy of the airline, 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 interests of the airline.

[0127] In addition to the above three core implementations, this application also uses advanced encryption and desensitization technology to ensure the safety of passengers' sensitive information; at the same time, it implements a real-time risk control mechanism to strictly protect funds and effectively prevent cash-out behavior. By continuously optimizing the passenger self-service refund experience, this application helps to improve user stickiness and thus promote the growth of airline profits.

[0128] Although the present application has been described in detail with reference to the aforementioned embodiments, a person of ordinary skill in the art should understand that it is still possible to modify the technical solutions described in the aforementioned embodiments, or to make equivalent replacements for some of the technical features therein; and these modifications or replacements 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 the present application.

Claims

1. A refund method for the original channel based on the OTA data model, comprising the following steps: The decision-making step for collecting wire transfer information is to determine the collection method with the highest priority according to the provided order and the strategy for collecting wire transfer information; The steps for identifying complex refund scenarios in 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 notification information, and pass the received notification information to the state machine receiver and converter to trigger state transfer; The wire transfer information collection step receives and verifies the submitted wire transfer information through the wire transfer information collection interface. After the verification is passed, the wire transfer information is updated to the unified order data model and transferred to the subsequent refund process by sending an internal request; Wire transfer refund step: the part of the amount that cannot be successfully withdrawn through the original refund channel will be refunded to the bank account designated by the passenger by wire transfer; For offline refund, passengers can choose a service outlet to complete the offline refund process. The payment integration information step receives the corresponding request, encrypts the sensitive information in the request, and then initiates an external request for wire transfer transmission / wire transfer refund to the payment platform.

2. The method according to claim 1, characterized in that Further comprising the steps of: Security assurance steps include identity authentication for refunders, desensitization and encryption of passenger sensitive information, and preservation of complete operation history; Security risk control steps, identifying and handling suspicious refunds through real-time risk control, accurate rating, delayed refunds and real-time update of risk control strategies; In the message integration step, during the refund process, passengers receive wire transfer collection, refund reminders, and agent work order message notifications, determine the message type and target recipient, and automatically construct the message content according to the preset entry template to achieve accurate message push.

3. The method according to claim 2, characterized in that The wire transfer information collection and decision-making step further includes: The scenarios that support the collection of wire transfer information include refund amount overrun, refund failure by payer, and refund failure by bank. For the refund amount overrun and refund failure scenarios, all methods of wire transfer information collection are supported, while for the bank refund failure scenario, only the payer and customer methods of wire transfer information collection are supported. Get the supported collection methods based on the business scenario of the order data, analyze the order, and collect data by passenger if there is a passenger; collect data by payer if there is no passenger; collect data by contact if there is no passenger or payer; If the order is a bank refund failure scenario, the decision-making starts with the payer; If you are collecting wire transfer information again, you need to compare it with the last collection method in the order. If they are collection methods of the same priority, you need to downgrade it by one level.

4. The method according to claim 3, characterized in that The step of identifying complex refund scenarios in the original channel further includes: The refund status update notification information is the status of review rejection, payment provider refund failure or bank refund failure; Data processing action Action, retrieves all information related to a specific refund order and updates the refund order data to the order data; The decision-making mechanism is called to determine whether the refund should be made through the wire transfer information of the passenger, the payer, or the customer; at the same time, this order is added to the wire transfer collection and guarantee mechanism to ensure the progress of the wire transfer refund.

5. The method according to claim 4, characterized in that The step of collecting wire transfer information further comprises: When a refund exception occurs and the passenger chooses to collect wire transfer information, the wire transfer information will be collected, verified and written into the unified order data model; Receive a unified XML request based on the OTA data model; Compare the collection method in the request with the collection method returned by the wire transfer information collection decision mechanism to verify whether the wire transfer information collection and content are correct; After the verification is passed, the wire transfer information will be encrypted through the security module and written into the unified order data model. If the refund amount exceeds the limit or the payment provider fails to refund, an internal wire transfer refund request will be initiated. If the bank refund fails, an internal wire transfer transmission request will be initiated for subsequent processing.

6. The method according to claim 5, characterized in that The wire transfer refund step further includes the following steps: By calling the API interface provided by the external payment provider in the step of identifying the complex refund scenarios of the original channel, 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 form is updated to the unified order data model, and a message notification is sent to the passenger; After receiving the prompt message that requires collecting wire transfer information, the passenger fills in the wire transfer information of the corresponding person in the prompt message on the order details page and submits it; The wire transfer information collection step receives a wire transfer information collection request, encrypts the wire transfer information through the security step and writes it into a unified order data model, and initiates an internal request for wire transfer information according to different refund abnormal states; After receiving the internal request for wire transfer refund, the wire transfer refund step analyzes the refund status and wire transfer information of the order, generates a wire transfer refund record according to 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; 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 step and then initiates an external request for wire transfer transmission / wire transfer refund to the payment platform.

7. The method according to claim 6, characterized in that The offline refund step further includes the following steps: 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, and the status of the refund application form is updated to the order data structure; When the traveler receives a message from the payment provider that a refund has failed, he or she chooses to apply for offline advance payment, initiates an internal request for offline advance payment to the payment integration module, updates the order refund status, and records the offline branch information selected by the traveler in the order data.

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

9. An original channel refund system based on an OTA data model, used to implement the method described in any one of claims 1 to 8, characterized in that: The system comprises: The wire transfer information collection decision module determines the collection method with high priority according to the provided order and wire transfer information collection strategy; Original channel refund complex scenario recognition module: Use finite state automata to handle different refund states, call the API interface through external payment providers, receive refund status update notification information, and pass the received notification information to the state machine receiver and converter to trigger state transfer; 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 passed, the wire transfer information is updated to the unified order data model and transferred to the subsequent refund process by sending an internal request; The wire transfer refund module refunds the portion of the amount that cannot be successfully withdrawn through the original channel to the bank account designated by the passenger by wire transfer; Offline advance refund module: passengers can choose a service outlet to complete the offline refund operation; The payment integration information module, after receiving the corresponding request, encrypts the sensitive information in the request and initiates an external request for wire transfer transmission / wire transfer refund to the payment platform.

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

Images