Fault scene transaction method and device, and program product

Abstract

The invention discloses a transaction method and device for a fault scene and a program product, and relates to the field of financial science and technology, and the method comprises the steps: obtaining the merchant information of a merchant when a business system receives a transaction request and detects that the business system has a fault; performing merchant access verification on the merchant according to the merchant information of the merchant; determining a transaction amount according to the transaction request under the condition that the commercial tenant passes the commercial tenant admission verification; and under the condition that the transaction amount is smaller than or equal to the single transaction limit of the merchant, credit granting information of the customer is acquired, and the transaction request is executed according to the credit granting information. According to the method and the device, the problem that the customer service is unavailable due to the fact that the service is interrupted for a long time by adopting emergency measures such as container equipment or main-standby switching, even disaster recovery switching and the like when the financial institution emergently processes the fault in the related technology is solved.

Description

Technical Field

[0001] The present application relates to the field of financial technology, and specifically, to a transaction method, device and program product for failure scenarios. Background Art

[0002] In recent years, under the trend of interest rate market and "financial disintermediation", the traditional business model of banks relying on the interest rate spread between deposits and loans has been adjusted. The aggregated payment acquiring business with QR code payment as the core and integrating various payment channels to achieve a universal code has begun to become an important direction for banks to achieve transformation and development and change their business models.

[0003] In the technical implementation of the aggregated payment acquiring business system, there are many factors that can affect the continuous service capability of the business system, including the network, infrastructure construction, business logic implementation, etc. During normal service, since the banking system needs to provide a variety of differentiated product requirements, there are inevitably complex business logic processing and cross-system processing, which leads to lengthy transaction links. The longer the transaction process processed by the business system, the greater the probability of failure, and the greater the impact on the continuous service capability. In the predetermined fault emergency plan, more emergency measures such as container equipment or master-slave switching, or even disaster recovery switching, are used. All of these measures have a certain length of emergency processing time, which causes unavailability of merchant services during the emergency processing period.

[0004] Currently, no effective solution has been proposed to the problem that when financial institutions deal with emergency failures in related technologies, they use emergency measures such as container devices or active-standby switching, or even disaster recovery switching, which causes service interruptions for a long time and leads to unavailability of customer service. Summary of the invention

[0005] The main purpose of this application is to provide a transaction method, device and program product for a fault scenario, so as to solve the problem in the related technology that when financial institutions deal with faults in an emergency, they use emergency measures such as container equipment or master-slave switching, or even disaster recovery switching, which causes service interruption for a long time and leads to unavailability of customer service.

[0006] In order to achieve the above-mentioned purpose, according to one aspect of the present application, a transaction method for a fault scenario is provided, the method comprising: when a business system receives a transaction request and detects that the business system has a fault, obtaining the merchant information of the merchant, wherein the merchant in the transaction request is the payee and the customer is the payee; performing a merchant access verification on the merchant based on the merchant information of the merchant; when the merchant passes the merchant access verification, determining the transaction amount based on the transaction request; when the transaction amount is less than or equal to the single transaction limit of the merchant, obtaining the credit information of the customer, and executing the transaction request based on the credit information.

[0007] Furthermore, the merchant information of the merchant includes at least target configuration information, which represents configuration information of whether the merchant agrees to execute a target transaction policy, and the target transaction policy represents a strategy of advancing the transaction amount through a financial institution and completing the transaction request in the event of a failure of the business system.

[0008] Furthermore, a merchant access verification is performed on the merchant based on the merchant information of the merchant, including: when the target configuration information indicates that the merchant agrees to execute the target transaction policy, a merchant access verification is performed on the merchant; when the target configuration information indicates that the merchant does not agree to execute the target transaction policy, the transaction request is executed through the business system; when the merchant fails the merchant access verification, a first prompt message is generated, the transaction request is terminated, and the first prompt message is sent to the customer.

[0009] Furthermore, before obtaining the merchant information of the merchant, the method also includes: obtaining the attribute information of the merchant, and registering in each of N third-party institutions according to the attribute information of the merchant, wherein N is a positive integer greater than 1; in case of successful registration, determining the merchant identification information of each third-party institution, and obtaining the merchant identification information of the merchant in the N third-party institutions respectively; obtaining the single transaction limit of the merchant after every preset time period, and storing the merchant identification information corresponding to the merchant and the single transaction limit of the merchant in a preset storage space.

[0010] Furthermore, after determining the transaction amount based on the transaction request, the method also includes: querying the merchant's current single transaction limit in the preset storage space based on the merchant information of the merchant; comparing the merchant's current single transaction limit with the transaction amount to obtain a comparison result; determining that the transaction amount is less than or equal to the single transaction limit based on the comparison result; or, determining that the transaction amount is greater than the single transaction limit based on the comparison result, refusing to execute the transaction request, and returning a third prompt message to the customer.

[0011] Furthermore, obtaining the customer's credit information includes: obtaining the customer information of the customer, and evaluating the customer's credit rating based on the customer information through a third-party organization to obtain an evaluation result; determining the customer's credit rating based on the evaluation result through the third-party organization, and determining the customer's credit information based on the customer's credit rating; and receiving the customer's credit information sent by the third-party organization.

[0012] Furthermore, executing the transaction request based on the credit information includes: when the credit information indicates that the customer's credit level belongs to the first category of customers, sending a second prompt message to the merchant, or executing a preset risk control strategy; when the credit information indicates that the customer's credit level belongs to the second category of customers, generating transaction details based on the transaction request, the transaction amount, the merchant information of the merchant and the customer information of the customer, wherein the risk level of the first category of customers is lower than the risk level of the second category of customers; performing payment operations on the merchant based on the transaction details, and storing the transaction details to complete the transaction request, and initiating a request for additional deduction to the customer at a preset time.

[0013] Furthermore, after obtaining the merchant information of the merchant, the method also includes: receiving a modification instruction triggered by the target object; modifying the target configuration information of the merchant according to the modification instruction to obtain the modified target configuration information; and performing merchant access verification on the merchant according to the modified target configuration information.

[0014] In order to achieve the above-mentioned purpose, according to another aspect of the present application, a transaction device for a fault scenario is provided, and the device includes: a first acquisition unit, used to obtain the merchant information of the merchant when the business system receives a transaction request and detects that the business system has a fault, wherein the merchant in the transaction request is the payee and the customer is the payee; a first verification unit, used to perform a merchant access verification on the merchant based on the merchant information of the merchant; a first determination unit, used to determine the transaction amount based on the transaction request when the merchant passes the merchant access verification; an execution unit, used to obtain the credit information of the customer when the transaction amount is less than or equal to the single transaction limit of the merchant, and execute the transaction request based on the credit information.

[0015] Furthermore, the merchant information of the merchant includes at least target configuration information, which represents configuration information of whether the merchant agrees to execute a target transaction policy, and the target transaction policy represents a strategy of advancing the transaction amount through a financial institution and completing the transaction request in the event of a failure of the business system.

[0016] Furthermore, the first verification unit includes: a verification subunit, used to perform merchant access verification on the merchant when the target configuration information indicates that the merchant agrees to execute the target transaction policy; a first execution subunit, used to execute the transaction request through the business system when the target configuration information indicates that the merchant does not agree to execute the target transaction policy; a first sending subunit, used to generate a first prompt message, end the transaction request, and send the first prompt message to the customer when the merchant fails the merchant access verification.

[0017] Furthermore, the device also includes: a second acquisition unit, used to acquire the attribute information of the merchant before acquiring the merchant information of the merchant, and register with each of N third-party institutions according to the attribute information of the merchant, wherein N is a positive integer greater than 1; a second determination unit, used to determine the merchant identification information of each third-party institution when the registration is successful, and obtain the merchant identification information of the merchant in the N third-party institutions respectively; a third acquisition unit, used to acquire the single transaction limit of the merchant every preset time period, and store the merchant identification information corresponding to the merchant and the single transaction limit of the merchant in a preset storage space.

[0018] Furthermore, the device also includes: a query unit, which is used to query the merchant's current single transaction limit in the preset storage space according to the merchant information of the merchant after determining the transaction amount according to the transaction request; a comparison unit, which is used to compare the merchant's current single transaction limit with the transaction amount to obtain a comparison result; a third determination unit, which is used to determine that the transaction amount is less than or equal to the single transaction limit according to the comparison result; or, a sending unit, which is used to determine that the transaction amount is greater than the single transaction limit according to the comparison result, and then refuse to execute the transaction request, and send a third prompt message to the customer.

[0019] Furthermore, the execution unit includes: an evaluation subunit, used to obtain the customer information of the customer, and evaluate the customer's credit rating based on the customer information through a third-party organization to obtain an evaluation result; a determination subunit, used to determine the customer's credit rating based on the evaluation result through the third-party organization, and determine the customer's credit information based on the customer's credit rating; and a sending subunit, used to receive the customer's credit information sent by the third-party organization.

[0020] Furthermore, the execution unit includes: a second sending sub-unit, used to send a second prompt information to the merchant, or execute a preset risk control strategy, when the credit information indicates that the customer's credit level belongs to the first category of customers; a generating sub-unit, used to generate transaction details based on the transaction request, the transaction amount, the merchant information of the merchant and the customer information of the customer, when the credit information indicates that the customer's credit level belongs to the second category of customers, wherein the risk level of the first category of customers is lower than the risk level of the second category of customers; a second execution sub-unit, used to perform payment operations on the merchant based on the transaction details, and store the transaction details to complete the transaction request and initiate a request for additional deduction to the customer at a preset time.

[0021] Furthermore, the device also includes: a receiving unit, used to receive a modification instruction triggered by a target object after obtaining the merchant information of the merchant; a modification unit, used to modify the target configuration information of the merchant according to the modification instruction to obtain the modified target configuration information; a second verification unit, used to perform merchant access verification on the merchant according to the modified target configuration information.

[0022] In order to achieve the above-mentioned purpose, according to one aspect of the present application, a computer program product is provided, including a computer program, which, when executed by a processor, implements the transaction method for any of the above-mentioned failure scenarios, and which, when executed by a processor, implements the steps of the transaction method for the failure scenarios described in each embodiment of the present application.

[0023] In order to achieve the above-mentioned purpose, according to one aspect of the present application, a computer-readable storage medium is provided, wherein the computer-readable storage medium includes stored computer instructions, wherein when the computer instructions are executed by a processor, a transaction method for any of the above-mentioned failure scenarios is implemented.

[0024] In order to achieve the above-mentioned purpose, according to one aspect of the present application, an electronic device is provided, including one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by one or more processors, the one or more processors implement a transaction method for any of the above-mentioned failure scenarios.

[0025] In an embodiment of the present application, when a transaction request is received in a business system and a fault is detected in the business system, the merchant information of the merchant is obtained, wherein the merchant in the transaction request is the payee and the customer is the payee; a merchant access verification is performed on the merchant based on the merchant information of the merchant; when the merchant passes the merchant access verification, the transaction amount is determined based on the transaction request; when the transaction amount is less than or equal to the single transaction limit of the merchant, the credit information of the customer is obtained, and the transaction request is executed based on the credit information, thereby solving the technical problem that when financial institutions handle emergency failures, they use container devices or active-standby switching, or even disaster recovery switching and other emergency measures, which causes service interruption for a long time and leads to unavailability of customer service.

[0026] By obtaining merchant information during a financial institution's business system failure, conducting merchant access verification, single transaction limit verification and credit information determination, streamlining the transaction process, and quickly completing merchant verification and customer credit assessment, the smooth progress of payment transactions is ensured, transaction interruptions or delays caused by system failures are avoided, and the stability and user experience of the aggregated payment acquiring business are improved. At the same time, the risk of financial institutions' advance payment is effectively reduced, and a balance is achieved between business continuity and risk control, so that financial institutions can quickly respond to transaction requests in emergency scenarios, thereby providing merchants and customers with safe and fast payment services, and further improving customer satisfaction and merchant satisfaction. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] The drawings constituting a part of the present application are used to provide a further understanding of the present application. The illustrative embodiments and descriptions of the present application are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0028] Figure 1It is a hardware structure block diagram of a computer terminal (or mobile device) for implementing a transaction method for a failure scenario provided in accordance with the first embodiment of the present application;

[0029] Figure 2 It is a flow chart of a transaction method for an optional fault scenario provided in Embodiment 1 of the present application;

[0030] Figure 3 It is a schematic diagram of the process of an optional transaction system provided according to the first embodiment of the present application;

[0031] Figure 4 is a schematic diagram of an optional third-party credit authorization system provided according to Embodiment 1 of the present application;

[0032] Figure 5 is a schematic diagram of an optional merchant information management system provided according to Embodiment 1 of the present application;

[0033] Figure 6 is a schematic diagram of an optional transaction processor system provided according to Embodiment 1 of the present application;

[0034] Figure 7 is a schematic diagram of an optional transaction switch system provided according to the first embodiment of the present application;

[0035] Figure 8 is a schematic diagram of an optional transaction batch deduction processing system provided according to the first embodiment of the present application;

[0036] Fig. 9 It is a schematic diagram of the process of an optional aggregated payment acquiring transaction method based on bank advance payment in an emergency scenario provided in Example 1 of the present application;

[0037] Fig.10 is a schematic diagram of a transaction device according to a fault scenario provided in Embodiment 2 of the present application;

[0038] Fig.11 It is a schematic diagram of a transaction electronic device according to a fault scenario provided in Example 5 of the present application. DETAILED DESCRIPTION

[0039] It should be noted that, in the absence of conflict, the embodiments and features in the embodiments of the present application can be combined with each other. The present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.

[0040] It should be noted that the methods and devices determined by the processing methods, devices, storage media and electronic devices of the present application documents can be used in the field of financial technology to improve the transaction reliability of financial institutions during business system failures, and can also be used in any field other than the field of financial technology. The application fields of the methods and devices determined by the processing methods, devices, storage media and electronic devices of the present application documents are not limited.

[0041] It should be noted that the collected information (including but not limited to user device information, user personal information, collected data, used data, generated data, processed data, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, collected information, used information, generated information, processed information, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of relevant data are in compliance with the relevant laws, regulations and standards of relevant countries and regions, necessary confidentiality measures are taken, and public order and good customs are not violated, and corresponding operation entrances are provided for users to choose to authorize or refuse. For example, an interface is set up between this system and relevant users or institutions to provide users with corresponding operation entrances for users to choose to agree or refuse the results of automated decision-making; if the user chooses to refuse, the expert decision-making process will be entered.

[0042] Example 1

[0043] According to an embodiment of the present application, a method embodiment of a transaction in a fault scenario is also provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0044] The method embodiment provided in the first embodiment of the present application can be executed in a mobile terminal, a computer terminal or a similar computing device. Figure 1 The hardware structure block diagram of a computer terminal (or mobile device) for implementing a transaction method for a failure scenario is shown. Figure 1As shown, the computer terminal 10 (or mobile device) may include one or more (102a, 102, ..., 102n are used to illustrate in the figure) processors 102 (the processor 102 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface (I / O interface), a universal serial bus (US) port (which may be included as one of the ports of the US bus), a network interface, a power supply and / or a camera. It can be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the above electronic device. Figure 1 More or fewer components as shown, or with Figure 1 Different configurations are shown.

[0045] It should be noted that the one or more processors 102 and / or other data processing circuits described above may generally be referred to herein as "data processing circuits". The data processing circuits may be embodied in whole or in part as software, hardware, firmware, or any other combination thereof. In addition, the data processing circuit may be a single independent processing module, or may be incorporated in whole or in part into any of the other components in the computer terminal 10 (or mobile device). As described in the embodiments of the present application, the data processing circuit acts as a processor control (e.g., selection of a variable resistor terminal path connected to an interface).

[0046] The memory 104 can be used to store software programs and modules of application software, such as program instructions / data storage devices corresponding to the transaction method of the fault scenario in the embodiment of the present application. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, that is, realizing the transaction method of the fault scenario mentioned above. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 104 may further include a memory remotely arranged relative to the processor 102, and these remote memories may be connected to the computer terminal 10 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0047] The transmission device 106 is used to receive or send data via a network. The specific example of the above network may include a wireless network provided by a communication provider of the computer terminal 10. In one example, the transmission device 106 includes a network adapter (Network Interface Controller, NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission device 106 can be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0048] The display may be, for example, a touch screen liquid crystal display (LCD) that enables a user to interact with a user interface of the computer terminal 10 (or mobile device).

[0049] Under the above operating environment, this application provides Figure 2 Trading method for the failure scenario shown. Figure 2 It is a flow chart of a transaction method according to the fault scenario of Example 1 of the present application.

[0050] Step S101, when the business system receives a transaction request and detects that the business system has a fault, the merchant information of the merchant is obtained, wherein the merchant in the transaction request is the payee and the customer is the payee.

[0051] In the first embodiment, when the aggregated payment acquiring business system of a financial institution receives a transaction request, if it detects that the current business system has a fault and cannot process the transaction through a conventional link, the emergency response mechanism will be immediately activated. Specifically, it is necessary to quickly obtain the merchant information involved in the transaction from a preset storage space (e.g., a database), including but not limited to key data such as merchant ID, name, account information, etc., so as to complete the transaction request based on the merchant information.

[0052] By obtaining merchant information, it is possible to determine whether the merchant supports the emergency transaction mode, thereby determining whether the transaction can be completed by bank advance payment. This emergency processing process is designed to ensure that even in the event of a system failure, aggregated payment transactions can still be carried out quickly and securely, ensuring that the payment experience of merchants and customers is not affected.

[0053] It is important to note that the merchant in the transaction request refers to the entity that wishes to receive payments through the aggregated payment system, while the customer is the user who pays the merchant.

[0054] Step S102: performing merchant access verification on the merchant according to the merchant information of the merchant.

[0055] In this first embodiment, in order to ensure the security of the transaction, it is necessary to perform merchant access verification based on the merchant information, for example, checking the merchant's registration status, credit rating, transaction limit and other key data. The merchant access verification process ensures that only qualified merchants can participate in the transaction, effectively preventing risky merchants or over-limit transactions, thereby ensuring the security and compliance of transactions.

[0056] Step S103: When the merchant passes the merchant access verification, the transaction amount is determined according to the transaction request.

[0057] In the first embodiment, after the merchant access verification is successful, it is necessary to automatically identify and determine the specific transaction amount based on the received transaction request. By determining the transaction amount, the smooth execution of subsequent transaction processing can be guaranteed, for example, whether the bank advance payment service is triggered, whether the merchant's single transaction limit is exceeded, and the final settlement and liquidation process.

[0058] Step S104: when the transaction amount is less than or equal to the merchant's single transaction limit, obtain the customer's credit information and execute the transaction request according to the credit information.

[0059] In the first embodiment, under the premise of ensuring that the transaction amount meets the merchant's single transaction limit, it is necessary to call the interface of the third-party payment platform to obtain the customer's credit information. This step determines whether the customer has the ability to pay the transaction amount by evaluating the customer's credit rating, so as to determine whether the financial institution adopts the advance payment method for the transaction.

[0060] For example, if a customer is assessed by a third party as low risk, that is, has a good loan repayment record, the transaction request will be executed based on his credit status, that is, the financial institution will advance the funds to ensure the continuity and timeliness of the merchant's payment, and then deduct the corresponding transaction amount from the customer in the end-of-day deduction processing.

[0061] The above steps not only optimize the transaction efficiency in emergency scenarios, but also effectively reduce the risk of financial institutions' advance payment, ensure the smooth progress of transactions and the security of funds, and achieve the effect of improving customer satisfaction.

[0062] Optionally, in the transaction method for the fault scenario provided in Example 1 of the present application, the merchant information of the merchant includes at least target configuration information, the target configuration information represents the configuration information of whether the merchant agrees to execute the target transaction strategy, and the target transaction strategy represents the strategy of advancing the transaction amount through a financial institution and completing the transaction request in the event of a business system failure.

[0063] In the first embodiment of the present invention, the target configuration information in the merchant information is used to indicate whether to execute the target transaction strategy (also referred to as the strategy of conducting transactions through a simple transaction link), and the target transaction strategy refers to the strategy of completing the transaction through advance payment by the financial institution when the aggregated payment acquiring business system of the financial institution encounters a failure, thereby ensuring the continuity of the transaction and the merchant's payment collection experience.

[0064] Specifically, the target configuration information includes the merchant's recognition and choice of the advance payment transaction model. When opening the aggregated payment acquiring business, the merchant must input or provide merchant information in the merchant management system (also known as obtaining the merchant's application data) to clarify whether the merchant is willing to have the financial institution advance payment of the transaction amount in emergency scenarios such as system failures so that the transaction can proceed smoothly.

[0065] When the business system detects business anomalies, such as system failures, network interruptions, etc., and the merchant's target configuration information indicates that it agrees to execute the target transaction strategy, it will automatically switch to the simple transaction link and complete the transaction request through the simple transaction link. In the simple transaction link, the financial institution will advance the transaction amount so that the transaction can be completed immediately, avoiding the merchant's collection delay or interruption due to system failure.

[0066] By determining the target configuration information, financial institutions can respond quickly to system failures without affecting the normal collection of merchants, and allow transactions to continue through financial institutions' advance payment, thereby improving emergency response capabilities and the continuity of service levels of transaction systems, thereby achieving the effect of simultaneously improving the satisfaction of financial institutions' merchants and customers.

[0067] Optionally, in the transaction method for the fault scenario provided in Example 1 of the present application, a merchant access verification is performed on the merchant based on the merchant information of the merchant, including: when the target configuration information indicates that the merchant agrees to execute the target transaction policy, a merchant access verification is performed on the merchant; when the target configuration information indicates that the merchant does not agree to execute the target transaction policy, the transaction request is executed through the business system; when the merchant fails the merchant access verification, a first prompt message is generated, the transaction request is terminated, and the first prompt message is sent to the customer.

[0068] In the first embodiment, the merchant's emergency transaction configuration, i.e., the target configuration information, determines how the transaction is handled when the financial institution's business system fails. When the target configuration information indicates that the merchant agrees to implement the target transaction strategy, it means that in an emergency, the merchant will enable the simple transaction link to ensure the continuity of the transaction. Then, the merchant is subject to merchant access verification, including checking whether it is a risky merchant, whether the transaction exceeds the limit, etc., to ensure transaction security. If the verification passes, the financial institution will advance the transaction amount to ensure that the transaction is completed immediately.

[0069] If the target configuration information indicates that the merchant does not agree to execute the target transaction strategy, then when the business system fails, the transaction request will be processed through the regular business system, that is, waiting for the business system failure to be repaired, and the transaction request will be executed through the repaired business system, but this method may cause transaction delays or interruptions.

[0070] In addition, if the merchant fails to pass the merchant access verification, a first prompt message will be generated, the transaction process will be terminated, and this message will be sent to the customer, informing the customer that the transaction is not completed and informing the customer of the reason for the failure of the merchant access verification, for example, the merchant's risk status is high.

[0071] Through the above steps, it is ensured that in emergency scenarios, the transaction processing method can be flexibly adjusted according to the merchant's wishes and the status of the business system, which not only provides a funding guarantee option, but also maintains the standardization and security of transactions. At the same time, through timely feedback, the response efficiency of financial institutions is improved, thereby achieving the effect of improving merchant satisfaction and customer satisfaction.

[0072] Optionally, in the transaction method for the fault scenario provided in Example 1 of the present application, before obtaining the merchant information of the merchant, the above method also includes: obtaining the attribute information of the merchant, and registering in each of N third-party institutions according to the attribute information of the merchant, where N is a positive integer greater than 1; in case of successful registration, determining the merchant identification information of each third-party institution, and obtaining the merchant identification information of the merchant in the N third-party institutions respectively; obtaining the single transaction limit of the merchant after a preset time period, and storing the merchant identification information corresponding to the merchant and the single transaction limit of the merchant in a preset storage space.

[0073] In the first embodiment of the present invention, in the aggregated payment acquiring business, the merchant's attribute information can be obtained, including but not limited to the merchant's name, industry type, transaction history, etc., and based on this information, registration is performed in N third-party payment institutions (N is a positive integer greater than 1, representing multiple payment channels such as application A payment, application B payment, UnionPay payment channel, etc.). After successful registration, the unique identification information assigned to the merchant by each third-party institution, i.e., the merchant ID, will be determined for identification and tracking of the merchant in subsequent transactions.

[0074] In order to reduce the transaction risk of financial institutions, the merchant's single transaction limit information can be obtained regularly (preset time, such as every 3 hours, 12 hours, etc., which is not specifically limited in this embodiment 1). The merchant's identification information and single transaction limit in N third-party institutions are stored in a preset storage space (for example, a database, cache, key-value database, etc.) for immediate call and verification during transactions, ensuring that each transaction is carried out within a safe limit, avoiding the risks that may be caused by excessive single transaction amounts.

[0075] Through the above steps, the accuracy and timeliness of merchant information are guaranteed, while also providing guarantees for the compliance and security of transactions, thereby achieving the effect of improving transaction security and further achieving the effect of improving the security of financial institutions.

[0076] Optionally, in the transaction method for the fault scenario provided in Example 1 of the present application, after determining the transaction amount based on the transaction request, the method further includes: querying the merchant's current single transaction limit in a preset storage space based on the merchant information of the merchant; comparing the merchant's current single transaction limit with the transaction amount to obtain a comparison result; determining that the transaction amount is less than or equal to the single transaction limit based on the comparison result; or, determining that the transaction amount is greater than the single transaction limit based on the comparison result, refusing to execute the transaction request, and returning a third prompt message to the customer.

[0077] In the first embodiment, the current single transaction limit set by the financial institution for the merchant can be retrieved from the preset storage space according to the unique identifier of the merchant. This limit is the maximum transaction amount for the merchant pre-set by the financial institution to control risks. Subsequently, the transaction amount of the current transaction request is compared with the retrieved single transaction limit to generate a comparison result.

[0078] If the comparison result shows that the transaction amount is less than or equal to the merchant's single transaction limit, it means that the transaction is within the merchant's risk control range and the transaction will be allowed to continue. However, if the transaction amount is greater than the merchant's single transaction limit, it means that the transaction request exceeds the risk tolerance of the financial institution and the transaction request will be automatically rejected to avoid possible losses or prevent the risk from expanding. At the same time, a third prompt message will be generated to clearly inform the customer that the reason for the transaction failure is that the merchant's transaction amount exceeds the maximum limit, providing clear transaction feedback information.

[0079] By obtaining real-time limits and comparing the transaction amount with the merchant's real-time single transaction limit, the security and compliance of the transaction are ensured, transaction risks are effectively controlled, and the effect of improving transaction security is achieved, which further improves the security of financial institutions.

[0080] Optionally, in the transaction method for the fault scenario provided in Example 1 of the present application, obtaining the customer's credit information includes: obtaining the customer's information, and evaluating the customer's credit rating based on the customer information through a third-party organization to obtain an evaluation result; determining the customer's credit rating based on the evaluation result through a third-party organization, and determining the customer's credit information based on the customer's credit rating; and receiving the customer's credit information sent by the third-party organization.

[0081] In the first embodiment, after the merchant passes the merchant access verification and the single limit data verification, the merchant can obtain the basic information of the customer, including transaction history, asset status, etc., and then submit this information to the third-party agency in a preset manner (for example, a QR code, etc.). The third-party agency uses its internal credit assessment model to quantitatively assess the customer's credit rating and generate an assessment result.

[0082] Based on the evaluation results, the third-party institution will determine the customer's credit rating. The customer's credit rating reflects the customer's credit level and repayment ability in the third-party institution. Low-risk customers will be granted a higher credit rating, indicating that the risk of financial institutions providing advance funding for them in emergency scenarios is lower; while high-risk customers may receive a lower credit rating, indicating that the risk of financial institutions providing advance funding for them in emergency scenarios is higher, and financial institutions need to consider carefully when providing advance funding.

[0083] Financial institutions confirm the customer's credit information based on the customer's credit rating sent by a third-party institution, that is, whether the financial institution can use the advance payment model to complete the transaction for the customer, as well as the amount and conditions of the advance payment, etc. Receiving credit information enables banks to quickly determine whether to adopt an advance payment transaction strategy in emergency scenarios, ensuring the smooth progress of transactions and the safety of funds.

[0084] By obtaining credit assessment results for customers from third-party institutions, financial institutions can determine the risks of advance funding to customers, ensuring the rationality and controllability of financial institutions' advance funding behavior, while also providing customers with a more flexible and secure payment method.

[0085] Optionally, in the transaction method for the fault scenario provided in Example 1 of the present application, executing the transaction request based on the credit information includes: when the credit information indicates that the customer's credit level belongs to the first category of customers, sending a second prompt message to the merchant, or executing a preset risk control strategy; when the credit information indicates that the customer's credit level belongs to the second category of customers, generating transaction details based on the transaction request, the transaction amount, the merchant's merchant information and the customer's customer information, wherein the risk level of the first category of customers is lower than the risk level of the second category of customers; performing payment operations on the merchant based on the transaction details, and storing the transaction details to complete the transaction request, and initiating a request for additional deductions to the customer at a preset time.

[0086] In the first embodiment, after receiving the credit information of the customer, the transaction processing method will be determined according to the credit rating of the customer. If the credit rating of the customer belongs to the first category of customers with higher risk, the system will send a second prompt message to the merchant to warn the merchant that the customer has a high credit risk, or directly implement the preset risk control strategy, such as restricting transactions, adding additional verification, etc., to reduce the potential risks brought by bank advances.

[0087] If the customer's credit rating belongs to the second category of customers with lower risks, the transaction details will be generated based on the transaction request, transaction amount, merchant information and customer information, that is, the customer's credit is good and the bank's advance payment risk is low. Subsequently, based on the transaction details, the merchant is immediately paid, that is, the financial institution advances the transaction amount to the merchant first, and stores the transaction details to ensure the traceability of the transaction. After the transaction is completed, at the end of the day or at a preset time (for example, 0:00 every day, etc., no specific restrictions are made in this embodiment 1), a request for additional deduction is automatically initiated to the customer, and the transaction amount advanced by the bank is deducted from the customer's account.

[0088] By dynamically adjusting the transaction processing flow through the above steps, the merchant's payment efficiency is guaranteed, the risk of bank advance payment is controlled, and a balance is achieved between transaction security and user experience.

[0089] Optionally, in the transaction method for the fault scenario provided in Example 1 of the present application, after obtaining the merchant information of the merchant, the above method also includes: receiving a modification instruction triggered by the target object; modifying the target configuration information of the merchant according to the modification instruction to obtain the modified target configuration information; and performing merchant access verification on the merchant based on the modified target configuration information.

[0090] In the first embodiment, the target configuration information is used to indicate whether the merchant can enable the bank advance payment transaction strategy in an emergency scenario, and the target configuration information can be adjusted by the business personnel or operation and maintenance personnel of the financial institution (i.e., the target object mentioned above). When the business system of the financial institution receives a modification instruction triggered by the target object, it means that the transaction strategy configuration of a specific merchant needs to be adjusted.

[0091] Then, according to the received modification instructions, the merchant's target configuration information is updated, such as whether to agree to adopt the advance payment transaction mode when the system fails, so as to obtain the modified target configuration information. This modification process reflects the flexibility and customizability of the system configuration, allowing financial institutions to adjust transaction strategies in a timely manner according to the business system situation and merchant information.

[0092] Subsequently, the merchant is re-checked for access based on the modified target configuration information and other transaction steps are executed, including checking whether the merchant is in a risky state, whether the transaction amount exceeds the limit, etc., to ensure that the merchant still meets the transaction security and compliance requirements under the new transaction strategy.

[0093] By updating and verifying configuration information in real time, financial institutions can provide more flexible trading strategies while maintaining the stability and security of transactions.

[0094] Optionally, in the first embodiment, the process of the transaction system in the fault scenario in the present solution can be as follows: Figure 3As shown, it includes third-party credit 301, merchant information management 302, transaction processor 303, transaction controller 304, and transaction batch deduction processing 305. Third-party credit 301 refers to the third party conducting a credit assessment based on the customer's qualifications, mainly assessing the risk of the customer making additional deductions after the bank advances funds. Customers with low risks are more likely to make additional deductions successfully, and advance payments in the advance mode can be supported. Among them, whether to support financial institutions to make advances is not only determined by the risk level assessed by the financial institution on the customer, but also based on the credit information of the customer's third-party institution (for example, the credit score of the third party); customers with high risks may fail to make additional deductions, and the advance mode will not be supported. Merchant information management 302 is used for merchant basic data management before transactions. Transaction processor 303 refers to the process used to complete the processing of aggregated payment acquisition transactions of simple links. Transaction switch 304 is used to realize whether the aggregated payment acquisition transaction executes simple transaction link processing by realizing hot loading of the switch. Transaction batch deduction processing 305 is used to process merchant accounts and customer accounts in batch processing after the aggregated payment acquisition transaction is completed.

[0095] Optionally, in the first embodiment, the third-party credit authorization system in this solution can be as follows: Figure 4 As shown, it includes customer credit assessment 401, payment customer credit 402, and customer credit inquiry 403. Customer credit assessment 401 is used by a third party to conduct credit assessment based on the transaction status and asset status of the payment customer. For example, it is determined based on the information of the customer's repayment of the loan product, mainly the overdue rate and loan repayment status, and auxiliary assessment can also be performed based on the customer's transaction amount and asset information. Payment customer credit 402 refers to the third-party institution granting credit to the payment customer based on the evaluation results, and distinguishing them into high-risk users and low-risk users. Customer credit inquiry 403 refers to the third-party institution returning the customer's credit level based on the customer payment code sent by the bank.

[0096] Optionally, in the first embodiment, the merchant information management system in the present solution can be as follows: Figure 5As shown, it includes: a merchant application module 501, a merchant submission module 502, and a limit management module 503. The merchant application module 501 is used to maintain information on the merchant management system before the merchant opens the aggregated payment acquiring business, so as to generate key information related to the merchant, which is used for use in the transaction process and to identify the uniqueness of the merchant. Among them, the financial institution business system uses a code to implement transactions using multiple payment methods, and aggregation means that multiple payment methods and multiple payment tools of different sellers are included in one QR code. The key information related to the merchant includes the merchant's customer number a in the financial institution, and the customer number b1 corresponding to the merchant in the third-party institution b, the customer number c1 corresponding to the third-party institution c, the customer number d1 corresponding to the third-party institution d, etc. The third-party institution can be any institution that can be used for collection. The merchant submission module 502 is used to submit the merchant information to the third-party institution after completing the merchant application to form the local system merchant data, and complete the registration of the corresponding merchant on the third-party institution side, so as to realize the subsequent transaction process and ensure the consistency of merchants in the financial institution and the third-party institution. The limit management module 503 is used to maintain the single limit data of merchant transactions in the local system to achieve limit control during the transaction process and avoid the risk of single over-limit. Among them, the single limit data of the customer is determined by the risk control management system of the financial institution, and unlimited advance payment is not supported for the customer. If the transaction amount of a single transaction of the customer exceeds the single limit data, no advance payment will be made for the customer.

[0097] Optionally, in the first embodiment, the transaction processor system of the present solution may be as follows: Figure 6 As shown, it includes a merchant information loading module 601, a merchant transaction access module 602, a transaction information registration module 603, and obtaining customer credit information 604. The merchant information loading module 601 is used to load and identify data according to the set merchant parameters, which indicates that the system can further simplify the transaction link processing when hitting this part of the merchants. The merchant transaction access module 602 is used to identify the merchant entry data (indicating the merchant information of the merchant obtained in the financial institution, including the merchant's customer identification, etc.) through the transaction merchant, and to verify whether the merchant has specific conditions for continuing the transaction by judging the merchant attributes set by it, such as whether it is a risk-disabled merchant or whether the merchant has been disabled. At the same time, it includes checking the single transaction limit set for the merchant. If the transaction exceeds the set limit, the transaction is rejected, otherwise it can be released for access. The transaction information registration module 603 is used to register the transaction information in the database to indicate the uniqueness and anti-repudiation of the transaction, and to update the transaction status according to the transaction processing result. Obtaining customer credit information 604 is used to obtain the credit information of the paying customer from a third-party institution. The information is obtained before the transaction to obtain the customer's credit information.

[0098] Optionally, in the first embodiment, the transaction switch system of the present solution can be as follows: Figure 7 As shown, it includes a transaction link switching module 701 and a switching merchant identification module 702. The transaction link switching module 701 is used to standardize the switching parameter definition, and realizes the "switch" type parameter switching by setting the Boolean value format. At the same time, it has a hot loading mechanism, so that the switching operation can take effect in real time. The switching merchant identification module 702 is used to standardize the merchant parameter format that supports simple transaction links, and realizes the merchant identification capability by supporting the setting of merchant, region and other dimensional parameters. At the same time, it has a hot loading mechanism, so that the switching operation can take effect in real time. The transaction switcher system includes two parameters, one parameter identifies the merchant from multiple information dimensions, and the other parameter indicates whether the merchant supports transaction link switching.

[0099] Optionally, in the first embodiment, the transaction batch deduction processing system of the present solution can be as follows: Figure 8 As shown, it includes a merchant settlement module 801 and a customer batch deduction module 802. The merchant settlement module 801 is used to refer to the financial institution summarizing the transaction amount based on the aggregated payment acquisition transaction details (which may include the transaction information, payment information, and user information of the transaction, such as the user amount, transaction time, buyer and seller, and money details) and then entering the transaction amount into the merchant's account. The customer batch deduction module 802 is used to refer to the bank forming a customer-dimensional deduction file based on the aggregated payment acquisition transaction details and sending it to a third-party institution for additional deduction processing.

[0100] Optionally, in the first embodiment, the process of the aggregated payment acquiring transaction method based on bank advance payment in an emergency scenario can be as follows: Fig. 9As shown, the following steps are included: a link switching switch with a hot loading mechanism is used for production and operation and maintenance personnel to actively intervene in emergency situations, that is, to actively set transaction switching parameters and start the processing of simple transaction links. By reading the switching switch and loading the merchant data set, the merchant data is matched after the transaction is entered. If the transaction merchant does not support the simple transaction link, the existing transaction link processing is executed and the business system is repaired; if the simple transaction link is supported, the merchant information of the incoming merchant is obtained according to the transaction merchant, and the merchant is subjected to access verification. If access fails, the access failure prompt message is responded to and the transaction processing result is returned to the front end; if the access verification passes, the transaction order amount is used to verify whether the transaction exceeds the single transaction limit of the merchant. If the transaction order amount exceeds the single transaction limit set by the merchant, the transaction will be responded to with a failed transaction limit prompt message, and the transaction processing result will be returned to the front end; if the transaction amount does not exceed the limit, a third-party institution will be requested to obtain the customer's credit information. If the customer is a high-risk customer, the risk customer information will be responded to, and the transaction processing result will be returned to the front end; if the customer is a low-risk customer, the transaction information will be registered in the database, and the transaction completion status will be registered, and the transaction processing result will be returned to the front end. Among them, the response to the risk customer information can be operated as follows. If it is detected that the customer is a high-risk customer, a risk warning message will be sent to the merchant to remind the merchant that there is a certain risk in the transaction. At the same time, the customer can be processed according to the risk handling strategy preset by the financial institution. The transaction amount generated by the batch summary at the end of the day, and the corresponding funds will be transferred to the merchant account. The customer transaction bill generated by the batch determination at the end of the day is transmitted to the third-party institution for the customer to make up the deduction.

[0101] It should be noted that the steps shown in the flowcharts of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and that, although a logical order is shown in the flowcharts, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0102] To summarize, the transaction method for fault scenarios provided in the embodiments of the present application obtains the merchant information of the merchant when the business system receives a transaction request and detects that the business system has a fault, wherein the merchant is the payee and the customer is the payee in the transaction request; performs merchant access verification on the merchant based on the merchant information of the merchant; when the merchant passes the merchant access verification, determines the transaction amount based on the transaction request; when the transaction amount is less than or equal to the merchant's single transaction limit, obtains the customer's credit information, and executes the transaction request based on the credit information, which solves the problem in the related technology that when financial institutions handle faults in an emergency, they use container equipment or active-standby switching, or even disaster recovery switching and other emergency measures, which causes service interruption for a long time and leads to unavailability of customer service.

[0103] By obtaining merchant information during a financial institution's business system failure, conducting merchant access verification, single transaction limit verification and credit information determination, streamlining the transaction process, and quickly completing merchant verification and customer credit assessment, the smooth progress of payment transactions is ensured, transaction interruptions or delays caused by system failures are avoided, and the stability and user experience of the aggregated payment acquiring business are improved. At the same time, the risk of financial institutions' advance payment is effectively reduced, and a balance is achieved between business continuity and risk control, so that financial institutions can quickly respond to transaction requests in emergency scenarios, thereby providing merchants and customers with safe and fast payment services, and further improving customer satisfaction and merchant satisfaction.

[0104] Example 2

[0105] The embodiment of the present application also provides a transaction device for a fault scenario. It should be noted that the transaction device for a fault scenario in the embodiment of the present application can be used to execute the transaction method for a fault scenario provided in the embodiment of the present application. The transaction device for a fault scenario provided in the embodiment of the present application is introduced below.

[0106] According to an embodiment of the present application, a device for implementing the transaction method in the above-mentioned fault scenario is also provided, such as Fig.10 As shown, the device comprises:

[0107] Specifically, the first acquisition unit 1001 is used to acquire the merchant information of the merchant when the business system receives a transaction request and detects that the business system has a fault, wherein the merchant in the transaction request is the payee and the customer is the payee.

[0108] The first verification unit 1002 is used to perform merchant access verification on the merchant according to the merchant information of the merchant.

[0109] The first determining unit 1003 is configured to determine the transaction amount according to the transaction request when the merchant passes the merchant access verification.

[0110] The execution unit 1004 is used to obtain the customer's credit information and execute the transaction request according to the credit information when the transaction amount is less than or equal to the merchant's single transaction limit.

[0111] The transaction device for the fault scenario provided in the embodiment of the present application, when the business system receives a transaction request and detects a fault in the business system through the first acquisition unit 1001, obtains the merchant information of the merchant, wherein the merchant is the payee and the customer is the payee in the transaction request; the first verification unit 1002 performs merchant access verification on the merchant based on the merchant information of the merchant; the first determination unit 1003 determines the transaction amount based on the transaction request when the merchant passes the merchant access verification; the execution unit 1004 obtains the customer's credit information when the transaction amount is less than or equal to the merchant's single transaction limit, and executes the transaction request based on the credit information, thereby solving the problem in the related art that when financial institutions handle faults in an emergency, they use container equipment or active-standby switching, or even emergency measures such as disaster recovery switching, which causes service interruption for a long time and leads to unavailability of customer service.

[0112] By obtaining merchant information during a financial institution's business system failure, conducting merchant access verification, single transaction limit verification and credit information determination, streamlining the transaction process, and quickly completing merchant verification and customer credit assessment, the smooth progress of payment transactions is ensured, transaction interruptions or delays caused by system failures are avoided, and the stability and user experience of the aggregated payment acquiring business are improved. At the same time, the risk of financial institutions' advance payment is effectively reduced, and a balance is achieved between business continuity and risk control, so that financial institutions can quickly respond to transaction requests in emergency scenarios, thereby providing merchants and customers with safe and fast payment services, and further improving customer satisfaction and merchant satisfaction.

[0113] Optionally, in the transaction device for the fault scenario provided in Example 2 of the present application, the merchant information of the above-mentioned merchant includes at least target configuration information, the target configuration information represents the configuration information of whether the merchant agrees to execute the target transaction strategy, and the target transaction strategy represents the strategy of advancing the transaction amount through a financial institution and completing the transaction request in the event of a business system failure.

[0114] Optionally, in the transaction device for the fault scenario provided in Example 2 of the present application, the above-mentioned first verification unit 1002 includes: a verification subunit, used to perform merchant access verification on the merchant when the target configuration information indicates that the merchant agrees to execute the target transaction policy; a first execution subunit, used to execute the transaction request through the business system when the target configuration information indicates that the merchant does not agree to execute the target transaction policy; a first sending subunit, used to generate a first prompt message, end the transaction request, and send the first prompt message to the customer when the merchant fails the merchant access verification.

[0115] Optionally, in the transaction device for the fault scenario provided in Example 2 of the present application, the above-mentioned device also includes: a second acquisition unit, used to obtain the attribute information of the merchant before obtaining the merchant information of the merchant, and register with each of N third-party institutions according to the attribute information of the merchant, where N is a positive integer greater than 1; a second determination unit, used to determine the merchant identification information of each third-party institution when the registration is successful, and obtain the merchant identification information of the merchant in the N third-party institutions respectively; a third acquisition unit, used to obtain the single transaction limit of the merchant after a preset time period, and store the merchant identification information corresponding to the merchant and the single transaction limit of the merchant in a preset storage space.

[0116] Optionally, in the transaction device for the fault scenario provided in Example 2 of the present application, the above-mentioned device also includes: a query unit, which is used to query the merchant's current single transaction limit in a preset storage space based on the merchant information of the merchant after determining the transaction amount based on the transaction request; a comparison unit, which is used to compare the merchant's current single transaction limit with the transaction amount to obtain a comparison result; a third determination unit, which is used to determine that the transaction amount is less than or equal to the single transaction limit based on the comparison result; or, a sending unit, which is used to determine that the transaction amount is greater than the single transaction limit based on the comparison result, then refuse to execute the transaction request and send a third prompt message to the customer.

[0117] Optionally, in the transaction device of the fault scenario provided in Example 2 of the present application, the above-mentioned execution unit 1004 includes: an evaluation subunit, used to obtain customer information of the customer, and evaluate the customer's credit rating based on the customer information through a third-party organization to obtain an evaluation result; a determination subunit, used to determine the customer's credit rating based on the evaluation result through a third-party organization, and determine the customer's credit information based on the customer's credit rating; and a sending subunit, used to receive the customer's credit information sent by the third-party organization.

[0118] Optionally, in the transaction device of the fault scenario provided in Example 2 of the present application, the above-mentioned execution unit 1004 includes: a second sending sub-unit, used to send a second prompt message to the merchant, or execute a preset risk control strategy when the credit information indicates that the customer's credit level belongs to the first category of customers; a generating sub-unit, used to generate transaction details based on the transaction request, transaction amount, merchant information of the merchant and customer information of the customer when the credit information indicates that the customer's credit level belongs to the second category of customers, wherein the risk level of the first category of customers is lower than the risk level of the second category of customers; a second execution sub-unit, used to perform payment operations on the merchant based on the transaction details, and store the transaction details to complete the transaction request, and initiate a request for additional deduction to the customer at a preset time.

[0119] Optionally, in the transaction device for the fault scenario provided in Example 2 of the present application, the above-mentioned device also includes: a receiving unit, used to receive a modification instruction triggered by the target object after obtaining the merchant information of the merchant; a modification unit, used to modify the target configuration information of the merchant according to the modification instruction to obtain the modified target configuration information; a second verification unit, used to perform merchant access verification on the merchant based on the modified target configuration information.

[0120] It should be noted here that the above-mentioned first acquisition unit 1001, first verification unit 1002, first determination unit 1003 and execution unit 1004 correspond to steps S201 to S204 in Example 1, and the two modules and the corresponding steps implement the same examples and application scenarios, but are not limited to the contents disclosed in the above-mentioned Example 1. It should be noted that the above-mentioned modules or units can be hardware components or software components stored in a memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102 failure scenario transactions, ..., 102n), and the above-mentioned modules can also be run in the computer terminal 10 provided in Example 1 as part of the device.

[0121] Example 3

[0122] An embodiment of the present application may provide an electronic device, Fig.11 is a structural block diagram of an electronic device according to an embodiment of the present application. Fig.11 As shown, the electronic device may include: one or more ( Fig.11 (only one is shown) processor 1102, memory 1104, storage controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module and display.

[0123] Among them, the memory can be used to store software programs and modules, such as program instructions / modules corresponding to the methods and devices in the embodiments of the present application, and the processor executes various functional applications and data processing by running the software programs and modules stored in the memory, that is, realizing the above-mentioned method. The memory may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include a memory remotely arranged relative to the processor, and these remote memories may be connected to the terminal via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0124] The processor can call the information and application stored in the memory through the transmission device to perform the following steps: when the business system receives a transaction request and detects that the business system has a fault, obtain the merchant information of the merchant, wherein the merchant is the payee and the customer is the payee in the transaction request; perform a merchant access verification on the merchant based on the merchant information of the merchant; when the merchant passes the merchant access verification, determine the transaction amount based on the transaction request; when the transaction amount is less than or equal to the merchant's single transaction limit, obtain the customer's credit information and execute the transaction request based on the credit information.

[0125] The processor can call the information and application stored in the memory through the transmission device to perform the following steps: the merchant information of the merchant includes at least target configuration information, the target configuration information represents whether the merchant agrees to execute the configuration information of the target transaction strategy, and the target transaction strategy represents the strategy of advancing the transaction amount through a financial institution and completing the transaction request in the event of a business system failure.

[0126] The processor can call the information and application stored in the memory through the transmission device to execute the following steps: perform a merchant access verification on the merchant based on the merchant information of the merchant, including: when the target configuration information indicates that the merchant agrees to execute the target transaction strategy, perform a merchant access verification on the merchant; when the target configuration information indicates that the merchant does not agree to execute the target transaction strategy, execute the transaction request through the business system; when the merchant fails the merchant access verification, generate a first prompt message, end the transaction request, and send the first prompt message to the customer.

[0127] The processor can call the information and application stored in the memory through the transmission device to perform the following steps: before obtaining the merchant information of the merchant, the above method also includes: obtaining the attribute information of the merchant, and registering in each of N third-party institutions according to the attribute information of the merchant, where N is a positive integer greater than 1; if the registration is successful, determining the merchant identification information of each third-party institution, and obtaining the merchant identification information of the merchant in the N third-party institutions respectively; obtaining the single transaction limit of the merchant after a preset time period, and storing the merchant identification information corresponding to the merchant and the single transaction limit of the merchant in the preset storage space.

[0128] The processor can call the information and application stored in the memory through the transmission device to perform the following steps: After determining the transaction amount based on the transaction request, the above method also includes: querying the merchant's current single transaction limit in a preset storage space based on the merchant's merchant information; comparing the merchant's current single transaction limit with the transaction amount to obtain a comparison result; determining that the transaction amount is less than or equal to the single transaction limit based on the comparison result; or, determining that the transaction amount is greater than the single transaction limit based on the comparison result, refusing to execute the transaction request and returning a third prompt message to the customer.

[0129] The processor can call the information and application programs stored in the memory through the transmission device to perform the following steps: obtain the customer's credit information, including: obtain the customer's customer information, and evaluate the customer's credit rating based on the customer information through a third-party agency to obtain an evaluation result; determine the customer's credit rating based on the evaluation result through a third-party agency, and determine the customer's credit information based on the customer's credit rating; receive the customer's credit information sent by the third-party agency.

[0130] The processor can call the information and application stored in the memory through the transmission device to perform the following steps: execute the transaction request based on the credit information, including: when the credit information indicates that the customer's credit level belongs to the first category of customers, send a second prompt information to the merchant, or execute a preset risk control strategy; when the credit information indicates that the customer's credit level belongs to the second category of customers, generate transaction details based on the transaction request, transaction amount, merchant information of the merchant and customer information of the customer, wherein the risk level of the first category of customers is lower than the risk level of the second category of customers; perform payment operations on the merchant based on the transaction details, and store the transaction details to complete the transaction request, and initiate a request for additional deduction to the customer at a preset time.

[0131] The processor can call the information and application stored in the memory through the transmission device to perform the following steps: After obtaining the merchant information of the merchant, the above method also includes: receiving a modification instruction triggered by the target object; modifying the merchant's target configuration information according to the modification instruction to obtain the modified target configuration information; and performing merchant access verification on the merchant according to the modified target configuration information.

[0132] By adopting the embodiment of the present application, a transaction method for a fault scenario is provided. When a transaction request is received in the business system and a fault is detected in the business system, the merchant information of the merchant is obtained, wherein the merchant is the payee and the customer is the payee in the transaction request; the merchant access verification is performed on the merchant according to the merchant information of the merchant; when the merchant passes the merchant access verification, the transaction amount is determined according to the transaction request; when the transaction amount is less than or equal to the single transaction limit of the merchant, the customer's credit information is obtained, and the transaction request is executed according to the credit information, thereby solving the technical problem that when financial institutions handle faults in an emergency, they use container equipment or master-slave switching, or even disaster recovery switching and other emergency measures, which causes service interruption for a long time and leads to unavailability of customer service.

[0133] By obtaining merchant information during a financial institution's business system failure, conducting merchant access verification, single transaction limit verification and credit information determination, streamlining the transaction process, and quickly completing merchant verification and customer credit assessment, the smooth progress of payment transactions is ensured, transaction interruptions or delays caused by system failures are avoided, and the stability and user experience of the aggregated payment acquiring business are improved. At the same time, the risk of financial institutions' advance payment is effectively reduced, and a balance is achieved between business continuity and risk control, so that financial institutions can quickly respond to transaction requests in emergency scenarios, thereby providing merchants and customers with safe and fast payment services, and further improving customer satisfaction and merchant satisfaction.

[0134] It can be understood by those skilled in the art that Fig.11 The structure shown is for illustration only, and the electronic device may also be a smart phone (such as an Android phone, an iOS phone, etc.), a tablet computer, a PDA, a mobile Internet device (Mobile Internet Devices, MID), a PAD, and other terminal devices. Fig.11 The structure of the electronic device is not limited. Fig.11 More or fewer components (such as network interfaces, display devices, etc.) shown in, or having Fig.11 Different configurations are shown.

[0135] A person of ordinary skill in the art can understand that all or part of the steps in the various methods of the above embodiments can be completed by instructing the hardware related to the terminal device through a program, and the program can be stored in a computer-readable storage medium, and the storage medium may include: a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, etc.

[0136] Example 4

[0137] The embodiment of the present application further provides a storage medium. Optionally, in this embodiment, the storage medium can be used to store the program code executed by the transaction method for the fault scenario provided in the first embodiment.

[0138] Optionally, in this embodiment, the above storage medium may be located in any computer terminal in a computer terminal group in a computer network, or in any mobile terminal in a mobile terminal group.

[0139] The present application also provides a computer program product, which, when executed on a data processing device, is suitable for executing the program of the transaction method steps of the failure scenario.

[0140] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0141] In the above embodiments of the present application, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0142] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

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

[0144] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0145] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), mobile hard disk, disk or optical disk and other media that can store program codes.

[0146] The above is only a preferred implementation of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A transaction method for a failure scenario, characterized in that: include: When a business system receives a transaction request and detects that the business system has a fault, obtaining merchant information of the merchant, wherein the merchant in the transaction request is the payee and the customer is the payee; Performing merchant access verification on the merchant according to the merchant information of the merchant; If the merchant passes the merchant access verification, determining the transaction amount according to the transaction request; When the transaction amount is less than or equal to the single transaction limit of the merchant, the credit information of the customer is obtained, and the transaction request is executed according to the credit information.

2. The method according to claim 1, characterized in that The merchant information of the merchant includes at least target configuration information, which represents configuration information of whether the merchant agrees to execute a target transaction strategy, and the target transaction strategy represents a strategy of advancing the transaction amount through a financial institution and completing the transaction request in the event of a failure of the business system.

3. The method according to claim 2, characterized in that Performing merchant access verification on the merchant according to the merchant information of the merchant, including: When the target configuration information indicates that the merchant agrees to execute the target transaction policy, performing merchant access verification on the merchant; When the target configuration information indicates that the merchant does not agree to execute the target transaction policy, executing the transaction request through the business system; In the case that the merchant fails to pass the merchant access verification, a first prompt message is generated, the transaction request is terminated, and the first prompt message is sent to the customer.

4. The method according to claim 1, characterized in that: Before obtaining the merchant information of the merchant, the method further includes: Acquire the attribute information of the merchant, and register with each of N third-party institutions according to the attribute information of the merchant, where N is a positive integer greater than 1; In the case of successful registration, the merchant identification information of each third-party institution is determined, and the merchant identification information of the merchant in the N third-party institutions is obtained; The single transaction limit of the merchant is obtained every preset time period, and the merchant identification information corresponding to the merchant and the single transaction limit of the merchant are stored in a preset storage space.

5. The method according to claim 4, characterized in that After determining the transaction amount according to the transaction request, the method further includes: querying the current single transaction limit of the merchant in the preset storage space according to the merchant information of the merchant; Compare the merchant's current single transaction limit with the transaction amount to obtain a comparison result; Determining, based on the comparison result, that the transaction amount is less than or equal to the single transaction limit; or, If it is determined according to the comparison result that the transaction amount is greater than the single transaction limit, the transaction request is rejected and a third prompt message is returned to the customer.

6. The method according to claim 1, characterized in that Obtain the customer's credit information, including: Acquire the customer information of the customer, and evaluate the credit rating of the customer based on the customer information through a third-party organization to obtain an evaluation result; Determine the credit rating of the customer based on the evaluation result through the third-party institution, and determine the credit information of the customer based on the credit rating of the customer; Receive the customer's credit information sent by the third-party institution.

7. The method according to claim 1, characterized in that Executing the transaction request according to the credit information includes: When the credit information indicates that the customer's credit rating belongs to the first category of customers, sending a second prompt message to the merchant, or executing a preset risk control strategy; If the credit information indicates that the customer's credit rating belongs to the second category of customers, generating transaction details according to the transaction request, the transaction amount, the merchant information of the merchant and the customer information of the customer, wherein the risk level of the first category of customers is lower than the risk level of the second category of customers; Perform payment operations on the merchant based on the transaction details, store the transaction details to complete the transaction request, and initiate a request for additional deduction to the customer at a preset time.

8. The method according to claim 1, characterized in that After acquiring the merchant information of the merchant, the method further includes: Receive modification instructions triggered by the target object; Modifying the target configuration information of the merchant according to the modification instruction to obtain modified target configuration information; The merchant is subjected to merchant access verification according to the modified target configuration information.

9. A transaction device for a fault scenario, characterized in that: include: A first acquisition unit is used to acquire merchant information of a merchant when a business system receives a transaction request and detects that the business system has a fault, wherein the merchant in the transaction request is a payee and the customer is a payee; A first verification unit, configured to perform merchant access verification on the merchant according to the merchant information of the merchant; A first determining unit, configured to determine a transaction amount according to the transaction request when the merchant passes the merchant access verification; The execution unit is used to obtain the customer's credit information when the transaction amount is less than or equal to the single transaction limit of the merchant, and execute the transaction request according to the credit information.

10. A computer program product comprising computer instructions, characterized in that When the computer instructions are executed by a processor, the steps of the method according to any one of claims 1 to 8 are implemented.

Images