Transaction methods, devices, and program products for fault scenarios

Abstract

This application discloses a transaction method, apparatus, and program product for fault scenarios, relating to the field of fintech. The method includes: when the business system receives a transaction request and simultaneously detects a fault in the business system, obtaining the merchant's information; performing merchant access verification on the merchant based on the merchant information; if the merchant passes the merchant access verification, determining the transaction amount based on the transaction request; if the transaction amount is less than or equal to the merchant's single transaction limit, obtaining the customer's credit information, and executing the transaction request based on the credit information. This application solves the problem in related technologies where financial institutions, when handling emergency faults, employ emergency measures such as container devices, primary / backup switching, or even disaster recovery switching, experience prolonged service interruptions, leading to customer service unavailability.

Description

Technical Field

[0001] This application relates to the field of financial technology, and more specifically, to a trading method, device, and program product for a fault scenario. Background Technology

[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. Aggregated payment acquiring business, which integrates various payment channels with QR code payment as the core and realizes a one-code universal payment, has become an important direction for banks to achieve transformation and development and change their business model.

[0003] In the technical implementation of aggregated payment acquiring systems, multiple factors influence the continuity of service, including network infrastructure, basic resource construction, and business logic implementation. During normal service, the banking system needs to provide various differentiated product requirements, inevitably leading to complex business logic processing and cross-system processing. This results in lengthy transaction chains, and the longer the transaction process processed by the business system, the greater the probability of failure and the greater the impact on continuity of service. Contingency plans often employ containerized devices, primary / backup switching, or even disaster recovery switching. However, all of these measures have a certain processing time, during which merchants experience service unavailability.

[0004] There is currently no effective solution to the problem that financial institutions use emergency measures such as container devices, primary / backup switching, or even disaster recovery switching to handle faults in related technologies, resulting in long-term service interruptions and 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 fault scenarios, in order to solve the problem that when financial institutions handle emergency faults, they use emergency measures such as container devices, primary / backup switching, or even disaster recovery switching, resulting in long-term service interruptions and unavailability of customer service.

[0006] To achieve the above objectives, according to one aspect of this application, a transaction method for fault scenarios is provided. The method includes: when a business system receives a transaction request and simultaneously detects a fault in the business system, obtaining merchant information of a merchant, wherein the merchant in the transaction request is the payee and the customer is the payer; performing merchant access verification on the merchant based on the merchant information; if the merchant passes the merchant access verification, determining the transaction amount based on the transaction request; if the transaction amount is less than or equal to the merchant's single transaction limit, obtaining the customer's credit information, and executing the transaction request based on the credit information.

[0007] Furthermore, the merchant information includes at least target configuration information, which indicates whether the merchant agrees to execute a target transaction strategy. The target transaction strategy indicates a strategy to complete the transaction request by having a financial institution advance the transaction amount in the event of a business system failure.

[0008] Further, the merchant access verification is performed on the merchant based on the merchant information, including: when the target configuration information indicates that the merchant agrees to execute the target transaction strategy, the 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 strategy, 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's information, the method further includes: obtaining the merchant's attribute information; registering the merchant with each of the N third-party institutions based on the merchant's attribute information, where N is a positive integer greater than 1; determining the merchant identification information of each third-party institution upon successful registration, thereby obtaining the merchant identification information of the merchant in the N third-party institutions; obtaining the merchant's single transaction limit after a preset time interval, and storing the merchant identification information corresponding to the merchant and the merchant's single transaction limit in a preset storage space.

[0010] Furthermore, after determining the transaction amount based on the transaction request, the method further includes: querying the merchant's current single transaction limit in the 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, if the transaction amount is determined to be greater than the single transaction limit based on the comparison result, then the transaction request is rejected, and a third prompt message is returned to the customer.

[0011] Further, obtaining the customer's credit information includes: obtaining the customer's customer information, and having a third-party institution assess the customer's credit rating based on the customer information to obtain an assessment result; having the third-party institution determine the customer's credit rating based on the assessment result, 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 institution.

[0012] Further, executing the transaction request based on the credit information includes: if the credit information indicates that the customer's credit rating belongs to the first category of customers, sending a second notification 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 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 a payment operation on the merchant based on the transaction details, and storing the transaction details to complete the transaction request; and initiating a supplementary deduction request to the customer at a preset time.

[0013] Furthermore, after obtaining the merchant's information, the method further 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.

[0014] To achieve the above objectives, according to another aspect of this application, a transaction device for fault scenarios is provided. The device includes: a first acquisition unit, configured to acquire merchant information of a merchant when the business system receives a transaction request and simultaneously detects a fault in the business system, wherein the merchant in the transaction request is the payee and the customer is the payer; a first verification unit, configured to perform merchant access verification on the merchant based on the merchant information; a first determination unit, configured to determine the transaction amount based on the transaction request if the merchant passes the merchant access verification; and an execution unit, configured to acquire the customer's credit information and execute the transaction request based on the credit information if the transaction amount is less than or equal to the merchant's single transaction limit.

[0015] Furthermore, the merchant information includes at least target configuration information, which indicates whether the merchant agrees to execute a target transaction strategy. The target transaction strategy indicates a strategy to complete the transaction request by having a financial institution advance the transaction amount in the event of a business system failure.

[0016] Further, the first verification unit includes: a verification subunit, configured to perform merchant access verification on the merchant when the target configuration information indicates that the merchant agrees to execute the target transaction strategy; a first execution subunit, configured 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 strategy; and a first sending subunit, configured to generate a first prompt message, terminate the transaction request, and send the first prompt message to the customer when the merchant fails the merchant access verification.

[0017] Furthermore, the device further includes: a second acquisition unit, configured to acquire the merchant's attribute information before acquiring the merchant's merchant information, and register the merchant with each of the N third-party institutions based on the merchant's attribute information, where N is a positive integer greater than 1; a second determination unit, configured to determine the merchant identification information of each third-party institution upon successful registration, thereby obtaining the merchant identification information of the merchant in the N third-party institutions; and a third acquisition unit, configured to acquire the merchant's single transaction limit after a preset time interval, and store the merchant identification information corresponding to the merchant and the merchant's single transaction limit in a preset storage space.

[0018] Furthermore, the device further includes: a query unit, configured to query the merchant's current single transaction limit in the preset storage space based on the merchant information after determining the transaction amount according to the transaction request; a comparison unit, configured to compare the merchant's current single transaction limit with the transaction amount to obtain a comparison result; a third determination unit, configured 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, configured to refuse to execute the transaction request and send a third prompt message to the customer if the transaction amount is determined to be greater than the single transaction limit based on the comparison result.

[0019] Furthermore, the execution unit includes: an evaluation subunit, used to acquire the customer's customer information and evaluate the customer's credit rating based on the customer information through a third-party institution 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 institution 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 institution.

[0020] Further, the execution unit includes: a second sending subunit, configured 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 type of customer; a generation subunit, configured to generate transaction details based on the transaction request, the transaction amount, the merchant's merchant information, and the customer's customer information when the credit information indicates that the customer's credit level belongs to the second type of customer, wherein the risk level of the first type of customer is lower than the risk level of the second type of customer; and a second execution subunit, configured to perform a payment operation on the merchant based on the transaction details, store the transaction details to complete the transaction request, and initiate a supplementary deduction request to the customer at a preset time.

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

[0022] To achieve the above objectives, according to one aspect of this application, a computer program product is provided, comprising a computer program that, when executed by a processor, implements a transaction method for any of the aforementioned fault scenarios, and when executed by a processor, implements the steps of the transaction method for the fault scenarios described in various embodiments of this application.

[0023] To achieve the above objectives, according to one aspect of this application, a computer-readable storage medium is provided, the computer-readable storage medium including stored computer instructions, wherein, when the computer instructions are executed by a processor, the transaction method for any of the above-described fault scenarios is implemented.

[0024] To achieve the above objectives, according to one aspect of this 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 the one or more processors, the one or more processors cause the one or more processors to implement the transaction method for any of the fault scenarios described above.

[0025] In this embodiment, when a business system receives a transaction request and simultaneously detects a fault in the business system, it obtains the merchant's information, wherein the merchant in the transaction request is the payee and the customer is the payer. Based on the merchant's information, it performs merchant access verification on the merchant. If the merchant passes the merchant access verification, it determines the transaction amount based on the transaction request. If the transaction amount is less than or equal to the merchant's single transaction limit, it obtains the customer's credit information and executes the transaction request based on the credit information. This solves the technical problem that when financial institutions handle emergency faults, the use of container devices, primary / backup switching, or even disaster recovery switching can lead to prolonged service interruptions and unavailability of customer service.

[0026] By acquiring merchant information during system failures of financial institutions, and conducting onboarding verification, single-transaction limit verification, and credit information determination for merchants, the system streamlines transaction processes, quickly completes merchant verification and customer credit assessment, ensuring smooth payment transactions and avoiding transaction interruptions or delays caused by system failures. This improves the stability and user experience of aggregated payment acquiring services, while also effectively reducing the risk of financial institutions having to advance funds. It achieves a balance between business continuity and risk control, enabling financial institutions to respond quickly to transaction requests in emergency scenarios. Ultimately, it provides secure and fast payment services to merchants and customers, further improving customer and merchant satisfaction. Attached Figure Description

[0027] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings:

[0028] Figure 1This is a hardware structure block diagram of a computer terminal (or mobile device) for implementing a transaction method in a fault scenario, according to Embodiment 1 of this application.

[0029] Figure 2 This is a flowchart of a transaction method for an optional fault scenario provided in Embodiment 1 of this application;

[0030] Figure 3 This is a schematic diagram of the process of an optional transaction system provided according to Embodiment 1 of this application;

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

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

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

[0034] Figure 7 This is a schematic diagram of an optional transaction switcher system provided according to Embodiment 1 of this application;

[0035] Figure 8 This is a schematic diagram of an optional transaction batch deduction processing system provided according to Embodiment 1 of this application;

[0036] Figure 9 This is a schematic diagram of the process of an optional aggregated payment acquiring transaction method based on bank advance funding in an emergency scenario, provided according to Embodiment 1 of this application;

[0037] Figure 10 This is a schematic diagram of a transaction device for a fault scenario provided in Embodiment 2 of this application;

[0038] Figure 11 This is a schematic diagram of a transaction electronic device for a fault scenario provided in Embodiment 5 of this application. Detailed Implementation

[0039] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

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

[0041] It should be noted that the information collected in this application (including but not limited to user device information, user personal information, collected data, used data, generated data, processed data, etc.) and the data (including but not limited to data used for analysis, stored data, displayed data, collected information, used information, generated information, processed information, etc.) are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of related data all comply with the relevant laws, regulations, and standards of the relevant countries and regions, and necessary confidentiality measures have been taken. These measures do not violate public order and good morals, and corresponding operation entry points are provided for users to choose to authorize or refuse. For example, this system has interfaces with relevant users or organizations, providing users with corresponding operation entry points for users to choose to agree to or refuse automated decision results; if the user chooses to refuse, the process proceeds to the expert decision-making stage.

[0042] Example 1

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

[0044] The method embodiment provided in Embodiment 1 of this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 1 A hardware block diagram of a computer terminal (or mobile device) for implementing a transaction method in a fault scenario is shown. Figure 1As shown, the computer terminal 10 (or mobile device) may include one or more processors 102 (shown as 102a, 102fault scenario transactions, ..., 102n in the figure) (processor 102 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.), 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 fault scenario transaction) port (which may be included as one of the ports of the US bus in the fault scenario transaction), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0045] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or mobile device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0046] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the transaction method for fault scenarios in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby realizing the aforementioned transaction method for fault scenarios. The memory 104 may include high-speed random access memory, and may also include 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 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0047] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

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

[0049] Under the aforementioned operating environment, this application provides the following: Figure 2 The trading method for the fault scenario shown. Figure 2 This is a flowchart of a transaction method for a fault scenario according to Embodiment 1 of this application.

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

[0051] In this first embodiment, when a financial institution's aggregated payment acquiring system receives a transaction request, if it detects a system malfunction that prevents the transaction from being processed via the normal process, it will immediately activate an emergency response mechanism. Specifically, it will quickly retrieve the merchant information involved in the transaction from a pre-set storage space (e.g., a database), including but not limited to key data such as merchant ID, name, and account information, and then complete the transaction request based on the merchant information.

[0052] By obtaining merchant information, it can be determined whether the merchant supports the emergency transaction mode, thereby deciding whether to use bank bridging to complete the transaction. This emergency handling process aims to ensure that even in the event of system failure, aggregated payment transactions can still be carried out quickly and securely, protecting the payment experience of merchants and customers.

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

[0054] Step S102: Verify merchant access based on the merchant's information.

[0055] In this first embodiment, to ensure transaction security, merchant access verification is performed based on merchant information. This includes checking key data such as the merchant's registration status, credit rating, and transaction limits. The merchant access verification process ensures that only qualified merchants can participate in transactions, effectively preventing risky merchants or transactions exceeding limits, thereby guaranteeing transaction security and compliance.

[0056] Step S103: If the merchant passes the merchant access verification, determine the transaction amount based on the transaction request.

[0057] In this first embodiment, after successful merchant access verification, the specific transaction amount needs to be automatically identified and determined based on the received transaction request. Determining the transaction amount ensures the smooth execution of subsequent transaction processing, such as whether bank bridging services are triggered, whether the merchant's single transaction limit is exceeded, and the final settlement and clearing process.

[0058] Step S104: If 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.

[0059] In this first embodiment, provided that the transaction amount complies with 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 assesses the customer's credit rating to determine whether they have the ability to pay the transaction amount, thereby deciding whether the financial institution should provide advance payment for the transaction.

[0060] For example, if a customer is assessed as low-risk by a third party, i.e. has a good loan repayment record, the transaction request will be executed based on their creditworthiness. That is, the financial institution will advance the funds to ensure the continuity and timeliness of the merchant's receipt of payments, and then deduct the corresponding transaction amount from the customer in the end-of-day batch deduction process.

[0061] The above steps not only optimize transaction efficiency in emergency scenarios, but also effectively reduce the risk of financial institutions providing advance payments, ensuring the smooth progress of transactions and the safety of funds, thereby improving customer satisfaction.

[0062] Optionally, in the transaction method for fault scenarios provided in Embodiment 1 of this application, the merchant information 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. The target transaction strategy represents the strategy of having a financial institution advance the transaction amount and complete the transaction request in the event of a business system failure.

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

[0064] Specifically, the target configuration information includes the merchant's acceptance and choice of the advance payment transaction model. When opening the aggregated payment acquiring business, the merchant needs to enter 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 the transaction amount in case of emergency scenarios such as system failure, so that the transaction can proceed smoothly.

[0065] When the business system detects an anomaly, such as a system failure or network interruption, and the merchant's target configuration information indicates that they agree to execute the target transaction strategy, it will automatically switch to the simplified transaction link to complete the transaction request. In the simplified transaction link, the financial institution will advance the transaction amount, enabling the transaction to be completed immediately and avoiding payment delays or interruptions suffered by the merchant due to system failures.

[0066] By defining target configuration information, financial institutions can quickly respond to system failures without affecting merchants' normal payment collection. By providing advance funding from financial institutions, transactions can continue, improving emergency response capabilities and the continuity of service of the transaction system. This achieves the effect of simultaneously improving the satisfaction of financial institutions, merchants, and customers.

[0067] Optionally, in the transaction method for fault scenarios provided in Embodiment 1 of this application, merchant access verification is performed on the merchant based on the merchant's merchant information, including: performing merchant access verification on the merchant when the target configuration information indicates that the merchant agrees to execute the target transaction strategy; executing a transaction request through the business system when the target configuration information indicates that the merchant does not agree to execute the target transaction strategy; and generating a first prompt message, ending the transaction request, and sending the first prompt message to the customer when the merchant fails the merchant access verification.

[0068] In this first embodiment, the merchant's emergency transaction configuration, i.e., the target configuration information, determines how transactions are handled in the event of a failure in the financial institution's business system. When the target configuration information indicates that the merchant agrees to execute the target transaction strategy, it means that in an emergency, the merchant will activate a simplified transaction link to ensure transaction continuity. Then, merchant access verification is performed, including checking whether the merchant is a high-risk merchant and whether the transaction exceeds the limit, to ensure transaction security. If the verification passes, the financial institution advances the transaction amount to ensure the transaction is completed immediately.

[0069] If the target configuration information indicates that the merchant does not agree to execute the target transaction policy, the transaction request will be processed through the regular business system in the event of a business system failure. That is, the business system failure will be repaired, and the transaction request will be executed through the repaired business system. However, this method may cause transaction delays or interruptions.

[0070] In addition, if a merchant fails the merchant access verification, a first prompt message will be generated to terminate the transaction process. This message will be sent to the customer, informing them that the transaction has not been completed and explaining the reason for the merchant access verification failure, such as the merchant's high risk status.

[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. This not only provides the option of advance payment guarantee, but also maintains the standardization and security of transactions. At the same time, timely feedback improves the response efficiency of financial institutions, thereby achieving the effect of improving merchant and customer satisfaction.

[0072] Optionally, in the transaction method for fault scenarios provided in Embodiment 1 of this application, before obtaining the merchant information, the method further includes: obtaining the merchant's attribute information, registering the merchant with each of the N third-party institutions based on the merchant's attribute information, where N is a positive integer greater than 1; if the registration is successful, determining the merchant identification information of each third-party institution to obtain the merchant identification information of the merchant in the N third-party institutions; obtaining the merchant's single transaction limit after a preset time interval, and storing the merchant identification information and the merchant's single transaction limit in a preset storage space.

[0073] In this first embodiment, during the aggregated payment acquiring business, merchant attribute information can be obtained, including but not limited to the merchant's name, industry type, and transaction history. Based on this information, registration is performed with N third-party payment institutions (N is a positive integer greater than 1, representing multiple payment channels such as PaymentA, PaymentB, UnionPay, etc.). After successful registration, a unique identifier, namely the merchant identifier, will be assigned to each third-party institution for the merchant, which is used for merchant identification and tracking in subsequent transactions.

[0074] To reduce transaction risks for financial institutions, the merchant's single transaction limit information can be retrieved periodically (for a preset duration, such as every 3 hours, 12 hours, etc., which is not specifically limited in this embodiment). The merchant's identification information and single transaction limit in N third-party institutions are stored in a preset storage space (e.g., a database, cache, key-value database, etc.) for immediate retrieval and verification during transactions, ensuring that each transaction is conducted within a safe limit and avoiding potential risks caused by excessively large single transaction amounts.

[0075] The above steps ensure the accuracy and timeliness of merchant information, while also guaranteeing the compliance and security of transactions, thereby improving transaction security and further enhancing the security of financial institutions.

[0076] Optionally, in the transaction method for fault scenarios provided in Embodiment 1 of this 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'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, if the transaction amount is determined to be greater than the single transaction limit based on the comparison result, then the transaction request is rejected and a third prompt message is returned to the customer.

[0077] In this first embodiment, the current single transaction limit set by the financial institution for the merchant can be retrieved from a preset storage space based on the merchant's unique identifier. This limit is the maximum transaction amount preset by the financial institution for the merchant to control risk. 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 results show that the transaction amount is less than or equal to the merchant's single transaction limit, it indicates that the transaction is within the merchant's risk control range and will be allowed to proceed. However, if the transaction amount exceeds the merchant's set single transaction limit, it means that the transaction request exceeds the financial institution's risk tolerance and will be automatically rejected to avoid potential losses or prevent risk escalation. Simultaneously, a third notification will be generated, clearly informing the customer that the transaction failed because the merchant's transaction amount exceeded the maximum limit, providing clear transaction feedback.

[0079] By obtaining real-time limits and comparing transaction amounts with merchants' real-time single transaction limits, the security and compliance of transactions are ensured, transaction risks are effectively controlled, and transaction security is improved, thereby further enhancing the security of financial institutions.

[0080] Optionally, in the transaction method for a fault scenario provided in Embodiment 1 of this application, obtaining customer credit information includes: obtaining customer information and assessing the customer's credit rating based on the customer information through a third-party institution to obtain an assessment result; determining the customer's credit rating based on the assessment result through a third-party institution, 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 institution.

[0081] In this first embodiment, after the merchant passes the merchant access verification and single transaction limit data verification, basic customer information, including transaction history and asset status, can be obtained. This information is then submitted to a third-party institution via a preset method (e.g., QR code). The third-party institution uses its internal credit assessment model to quantitatively assess the customer's credit rating and generate an assessment result.

[0082] Based on the assessment results, the third-party institution will determine the customer's credit rating. The customer's credit rating reflects their creditworthiness and repayment ability within the third-party institution. Low-risk customers will be granted a higher credit rating, indicating that the financial institution faces less risk in providing advance payments for them in emergency situations; while high-risk customers may receive a lower credit rating, indicating that the financial institution faces greater risk in providing advance payments for them in emergency situations, and the financial institution must carefully consider this before providing such advance payments.

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

[0084] By obtaining credit assessment results from third-party institutions, financial institutions can identify the risks of providing advance payments to customers, ensuring the rationality and controllability of their advance payment activities. At the same time, it also provides customers with a more flexible and secure payment method.

[0085] Optionally, in the transaction method for fault scenarios provided in Embodiment 1 of this application, executing a transaction request based on credit information includes: if the credit information indicates that the customer's credit rating belongs to the first type of customer, 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 type of customer, generating transaction details based on the transaction request, transaction amount, merchant information, and customer information, wherein the risk level of the first type of customer is lower than that of the second type of customer; performing a payment operation on the merchant based on the transaction details, storing the transaction details to complete the transaction request, and initiating a supplementary deduction request to the customer at a preset time.

[0086] In this first embodiment, after receiving the customer's credit information, the system determines the transaction processing method based on the customer's credit rating. If the customer's credit rating belongs to the first category of high-risk customers, the system will send a second alert to the merchant, warning the merchant that the customer has a high credit risk, or directly implement preset risk control strategies, such as restricting transactions or adding additional verification, to reduce the potential risks brought by bank advances.

[0087] If a customer's credit rating falls under the lower-risk Category II category, a transaction detail will be generated based on the transaction request, transaction amount, merchant information, and customer information. This indicates that the customer has good credit and the bank's risk of providing advance payment is low. Subsequently, based on the transaction detail, the payment operation will be immediately performed to the merchant, meaning the financial institution advances the transaction amount to the merchant and stores the transaction detail to ensure transaction traceability. After the transaction is completed, at the end of the day or at a preset time (e.g., 00:00 each day, etc., no specific limitation is made in this embodiment), a supplementary deduction request will be automatically initiated to the customer, deducting the transaction amount advanced by the bank from the customer's account.

[0088] By dynamically adjusting the transaction processing flow through the above steps, the efficiency of merchants' payment collection is ensured, while the risk of bank advance payment is controlled, thus achieving a balance between transaction security and user experience.

[0089] Optionally, in the transaction method for fault scenarios provided in Embodiment 1 of this application, after obtaining the merchant information, the method further 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.

[0090] In this first embodiment, the target configuration information is crucial in indicating whether a merchant can activate the bank-funded transaction strategy in an emergency scenario. This target configuration information can be adjusted by the financial institution's business personnel or operations personnel (i.e., the aforementioned target object). When the financial institution's business system receives a modification instruction triggered by the target object, it means that the transaction strategy configuration for that specific merchant needs to be adjusted.

[0091] Then, based on the received modification instructions, the merchant's target configuration information is updated, such as adjusting whether they agree to use the advance payment transaction model in the event of system failure, thus obtaining the modified target configuration information. This modification process demonstrates the flexibility and customizability of the system configuration, enabling financial institutions to adjust their transaction strategies in a timely manner according to the business system situation and merchant information.

[0092] Subsequently, based on the revised target configuration information, the merchant's access verification is re-performed, and other transaction steps are executed. This includes 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 requirements of transaction security and compliance 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 this first embodiment, the transaction system process for the fault scenario in this solution can be as follows: Figure 3As shown, the system includes third-party credit granting (301), merchant information management (302), transaction processor (303), transaction controller (304), and batch transaction deduction processing (305). Third-party credit granting (301) refers to a third party's credit assessment based on the customer's qualifications. It primarily assesses the risk of the customer needing to make up the difference after the bank has provided advance payment. Customers with low risk are more likely to have their payments successfully deducted, supporting advance payment models. Whether or not financial institutions can provide advance payment depends not only on the risk level assessed by the financial institution but also on the customer's credit information from third-party institutions (e.g., credit score). Customers with high risk may fail to have their payments deducted, and therefore, advance payment models will not be supported. Merchant information management (302) is used for managing basic merchant data before the transaction. Transaction processor (303) refers to the process used to complete the simplified payment collection transaction processing. Transaction switcher (304) is used to control whether the simplified transaction processing is executed for the aggregated payment collection transaction by implementing a hot-loading switch. Batch transaction deduction processing (305) is used to process merchant and customer accounts in batches after the aggregated payment collection transaction is completed.

[0095] Optionally, in this embodiment one, the third-party credit system in this solution can be as follows: Figure 4 As shown, this includes Customer Credit Assessment 401, Payment Customer Credit Assessment 402, and Customer Credit Inquiry 403. Customer Credit Assessment 401 is used by a third party to conduct a credit assessment based on the payment customer's transaction history and asset situation. For example, it is determined based on the customer's loan repayment information, primarily the delinquency rate and loan repayment status, and can also be supplemented by the customer's transaction amount and asset information. Payment Customer Credit Assessment 402 refers to the third-party institution granting credit to payment customers based on the assessment results, classifying them as high-risk or low-risk users. Customer Credit Inquiry 403 refers to the third-party institution returning the customer's credit rating based on the customer's payment code sent by the bank.

[0096] Optionally, in this first embodiment, the merchant information management system in this solution can be as follows: Figure 5As shown, the system includes: a merchant onboarding module 501, a merchant reporting module 502, and a limit management module 503. The merchant onboarding module 501 is used to maintain information on the merchant management system before a merchant activates the aggregated payment acquiring business. This information generates key merchant-related information for use in transactions and to identify the merchant's uniqueness. The financial institution's business system uses a single code to enable transactions using multiple payment methods. Aggregation means including multiple payment methods and payment tools from different sellers within a single QR code. The key merchant-related information includes the merchant's customer ID 'a' at the financial institution, and the corresponding customer IDs 'b1', 'c1', 'd1', etc., at third-party institutions 'b', 'c1', 'd1', etc. These third-party institutions can be any institution that can be used for payment collection. The merchant reporting module 502, after completing the merchant onboarding and generating merchant data in the local system, reports the merchant information to the third-party institutions. The third-party institutions then complete the corresponding merchant registration to facilitate subsequent transaction processes and ensure consistency between the merchants in the financial institution and the third-party institutions. The transaction limit management module 503 is used to maintain the single transaction limit data of merchants in the local system, so as to realize limit control during the transaction process and avoid the risk of exceeding the limit in a single transaction. Among them, the single transaction limit data of customers is determined by the risk control management system of financial institutions. Unlimited advance payment for customers is not supported. If the transaction amount of a customer's single transaction exceeds the single transaction limit data, no further advance payment will be made for the customer.

[0097] Optionally, in this first embodiment, the transaction processor system of this solution can be as follows: Figure 6 As shown, the system includes a merchant information loading module 601, a merchant transaction access module 602, a transaction information registration module 603, and a customer credit information acquisition module 604. The merchant information loading module 601 loads and identifies data based on set merchant parameters, indicating that the system can further simplify the transaction process when it identifies a merchant. The merchant transaction access module 602 identifies merchant application data (representing merchant information obtained from financial institutions, including the merchant's customer identifier, etc.) by judging the merchant's set attributes to verify whether the merchant meets the conditions for continuing transactions, such as whether it is a risk-prone deactivated merchant or whether the merchant has already been deactivated. It also verifies the single transaction limit set for the merchant; if the transaction exceeds the set limit, the transaction is rejected; otherwise, access is granted. The transaction information registration module 603 registers transaction information in the database, indicating the uniqueness and non-repudiation of the transaction, and updates the transaction status based on the transaction processing results. The "Get Customer Credit Information" 604 error is used to obtain information about the creditworthiness of a paying customer from a third-party institution. This information is retrieved before the transaction.

[0098] Optionally, in this embodiment one, the transaction switcher system of this solution can be as follows: Figure 7 As shown, the system includes a transaction link switching module 701 and a merchant identification module 702. The transaction link switching module 701 standardizes the definition of switching parameters, implementing a "switch"-like parameter switching through Boolean value settings. It also features a hot-loading mechanism, ensuring the switching operation takes effect in real time. The merchant identification module 702 standardizes the merchant parameter format that supports simplified transaction links. It supports setting parameters based on merchant, region, and other dimensions, enabling merchant identification. It also features a hot-loading mechanism, ensuring the switching operation takes 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 this first embodiment, the transaction deduction processing system of this solution can be as follows: Figure 8 As shown, the system includes a merchant settlement module 801 and a customer batch deduction module 802. The merchant settlement module 801 is used by financial institutions to process transactions by summarizing the transaction amount based on aggregated payment acquiring transaction details (which may include transaction information, payment information, and user information such as user amount, transaction time, buyer and seller, and payment details) and then crediting the funds to the merchant. The customer batch deduction module 802 is used by banks to generate customer-level deduction files based on aggregated payment acquiring transaction details and send them to third-party institutions for supplementary deductions.

[0100] Optionally, in this first embodiment, the process of the aggregated payment acquiring transaction method based on bank advance funding in emergency scenarios can be as follows: Figure 9As shown, the process includes the following steps: A link switching switch with a hot-loading mechanism allows production and maintenance personnel to proactively intervene in emergency situations, i.e., actively set transaction switching parameters and initiate simplified transaction link processing. Merchant data matching is performed after a transaction enters by reading the switching switch and the loaded merchant data. If the merchant does not support the simplified transaction link, the existing transaction link processing is executed, awaiting business system repair; if the simplified transaction link is supported, the incoming merchant information is obtained based on the merchant, and access verification is performed on the merchant. If access fails, an access failure message is responded to, and the transaction processing result is returned to the front end; if access verification passes, the transaction order amount is used to verify whether the transaction exceeds the merchant's single transaction limit. If the transaction order amount exceeds the merchant's pre-set single transaction limit, a transaction failure message indicating that the limit has been exceeded will be displayed, 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, a risk customer information message will be displayed, 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, the transaction completion status will be recorded, and the transaction processing result will be returned to the front end. The response to risk customer information can be as follows: if a high-risk customer is detected, a risk warning message will be sent to the merchant to inform them that the transaction carries a certain risk, and the customer can be dealt with according to the financial institution's preset risk handling strategy. At the end of the day, the generated transaction amounts will be batch-summarized, and the corresponding funds will be transferred to the merchant's account. At the end of the day, customer transaction bills will be batch-determined and transmitted to a third-party institution for supplementary deductions from the customer's account.

[0101] It should be noted that the steps shown in the flowchart in 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 may be executed in a different order than that shown here.

[0102] In summary, the transaction method for fault scenarios provided in this application, when the business system receives a transaction request and simultaneously detects a fault in the business system, obtains the merchant's information, where the merchant is the payee and the customer is the payer in the transaction request; performs merchant access verification on the merchant based on the merchant's information; if the merchant passes the merchant access verification, determines the transaction amount based on the transaction request; if 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. This solves the problem in related technologies where financial institutions use emergency measures such as container devices, primary / backup switching, or even disaster recovery switching when handling faults, resulting in prolonged service interruptions and unavailability of customer service.

[0103] By acquiring merchant information during system failures of financial institutions, and conducting onboarding verification, single-transaction limit verification, and credit information determination for merchants, the system streamlines transaction processes, quickly completes merchant verification and customer credit assessment, ensuring smooth payment transactions and avoiding transaction interruptions or delays caused by system failures. This improves the stability and user experience of aggregated payment acquiring services, while also effectively reducing the risk of financial institutions having to advance funds. It achieves a balance between business continuity and risk control, enabling financial institutions to respond quickly to transaction requests in emergency scenarios. Ultimately, it provides secure and fast payment services to merchants and customers, further improving customer and merchant satisfaction.

[0104] Example 2

[0105] This application also provides a trading device for fault scenarios. It should be noted that the trading device for fault scenarios in this application can be used to execute the trading method for fault scenarios provided in this application. The following describes the trading device for fault scenarios provided in this application.

[0106] According to embodiments of this application, an apparatus for implementing the transaction method in the above-described fault scenario is also provided, such as... Figure 10 As shown, the device includes:

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

[0108] The first verification unit 1002 is used to verify merchant access based on the merchant's merchant information.

[0109] The first determining unit 1003 is used to determine the transaction amount based on 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 based on the credit information when the transaction amount is less than or equal to the merchant's single transaction limit.

[0111] The transaction device for fault scenarios provided in this application embodiment, through the first acquisition unit 1001, obtains merchant information when the business system receives a transaction request and detects a fault in the business system. In the transaction request, the merchant is the payee and the customer is the payer. The first verification unit 1002 performs merchant access verification on the merchant based on the merchant information. If the merchant passes the merchant access verification, the first determination unit 1003 determines the transaction amount based on the transaction request. If the transaction amount is less than or equal to the merchant's single transaction limit, the execution unit 1004 obtains the customer's credit information and executes the transaction request based on the credit information. This solves the problem in related technologies where financial institutions use emergency measures such as container devices, primary / backup switching, or even disaster recovery switching when handling faults, resulting in long-term service interruptions and unavailability of customer service.

[0112] By acquiring merchant information during system failures of financial institutions, and conducting onboarding verification, single-transaction limit verification, and credit information determination for merchants, the system streamlines transaction processes, quickly completes merchant verification and customer credit assessment, ensuring smooth payment transactions and avoiding transaction interruptions or delays caused by system failures. This improves the stability and user experience of aggregated payment acquiring services, while also effectively reducing the risk of financial institutions having to advance funds. It achieves a balance between business continuity and risk control, enabling financial institutions to respond quickly to transaction requests in emergency scenarios. Ultimately, it provides secure and fast payment services to merchants and customers, further improving customer and merchant satisfaction.

[0113] Optionally, in the transaction device for the fault scenario provided in Embodiment 2 of this application, the merchant information of the aforementioned 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. The target transaction strategy represents the strategy of having a financial institution advance the transaction amount and complete the transaction request in the event of a business system failure.

[0114] Optionally, in the transaction device for the fault scenario provided in Embodiment 2 of this application, the 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 strategy; 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 strategy; and 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 fault scenarios provided in Embodiment 2 of this application, the device further includes: a second acquisition unit, configured to acquire the merchant's attribute information before acquiring the merchant's merchant information, and register the merchant with each of the N third-party institutions based on the merchant's attribute information, where N is a positive integer greater than 1; a second determination unit, configured to determine the merchant identification information of each third-party institution when the registration is successful, thereby obtaining the merchant identification information of the merchant in the N third-party institutions; and a third acquisition unit, configured to acquire the merchant's single transaction limit after a preset time interval, and store the merchant identification information corresponding to the merchant and the merchant's single transaction limit in a preset storage space.

[0116] Optionally, in the transaction device for fault scenarios provided in Embodiment 2 of this application, the device further includes: a query unit, used to query the merchant's current single transaction limit in a preset storage space based on the merchant's merchant information after determining the transaction amount according to the transaction request; a comparison unit, used to compare the merchant's current single transaction limit with the transaction amount to obtain a comparison result; a third determination unit, 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, used to refuse to execute the transaction request and send a third prompt message to the customer if the transaction amount is determined to be greater than the single transaction limit based on the comparison result.

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

[0118] Optionally, in the transaction device for fault scenarios provided in Embodiment 2 of this application, the execution unit 1004 includes: a second sending subunit, 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 type of customer; a generation subunit, used to generate transaction details based on the transaction request, transaction amount, merchant information, and customer information when the credit information indicates that the customer's credit level belongs to the second type of customer, wherein the risk level of the first type of customer is lower than that of the second type of customer; and a second execution subunit, 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 supplementary deduction request to the customer at a preset time.

[0119] Optionally, in the transaction device for fault scenarios provided in Embodiment 2 of this application, the device further 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; and a second verification unit, used to perform merchant access verification on the merchant according to the modified target configuration information.

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

[0121] Example 3

[0122] Embodiments of this application may provide an electronic device. Figure 11 This is a structural block diagram of an electronic device according to an embodiment of this application. Figure 11 As shown, the electronic device may include: one or more ( Figure 11 Only one of the following is shown: processor 1102, memory 1104, memory controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module, and display.

[0123] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the methods and apparatus in the embodiments of this application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby implementing the above-described methods. The memory may include high-speed random access memory, and may also include 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 memory remotely located relative to the processor, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0124] The processor can access information and applications stored in memory via a transmission device to perform the following steps: When the business system receives a transaction request and simultaneously detects a fault in the business system, it obtains the merchant's information, where the merchant is the payee and the customer is the payer in the transaction request; it performs merchant access verification on the merchant based on the merchant's information; if the merchant passes the merchant access verification, it determines the transaction amount based on the transaction request; if the transaction amount is less than or equal to the merchant's single transaction limit, it obtains the customer's credit information and executes 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 includes at least the target configuration information, which represents whether the merchant agrees to execute the target transaction strategy, and the target transaction strategy represents the strategy of having a financial institution advance the transaction amount and complete the transaction request in the event of a business system failure.

[0126] The processor can access the information and application stored in the memory through the transmission device to perform the following steps: perform merchant access verification based on the merchant's merchant information, including: performing merchant access verification if the target configuration information indicates that the merchant agrees to execute the target transaction strategy; executing a transaction request through the business system if the target configuration information indicates that the merchant does not agree to execute the target transaction strategy; and generating a first prompt message, ending the transaction request, and sending the first prompt message to the customer if the merchant fails the merchant access verification.

[0127] The processor can invoke information and applications stored in the memory via a transmission device to execute the following steps: Before obtaining the merchant's information, the above method further includes: obtaining the merchant's attribute information, registering the merchant with each of the N third-party institutions based on the merchant's attribute information, where N is a positive integer greater than 1; if the registration is successful, determining the merchant identification information of each third-party institution to obtain the merchant identification information of the merchant in the N third-party institutions; obtaining the merchant's single transaction limit after a preset time interval, and storing the merchant's corresponding merchant identification information and the merchant's single transaction limit in a preset storage space.

[0128] The processor can access the information and application programs stored in the memory via the transmission device to perform the following steps: After determining the transaction amount based on the transaction request, the above method further includes: querying the merchant's current single transaction limit in the preset storage space based on the merchant's 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, if the transaction amount is determined to be greater than the single transaction limit based on the comparison result, then rejecting the transaction request and returning a third prompt message to the customer.

[0129] The processor can access information and applications stored in the memory via a transmission device to perform the following steps: obtaining customer credit information, including: obtaining customer information and assessing the customer's credit rating based on the customer information through a third-party institution to obtain an assessment result; determining the customer's credit rating based on the assessment result through a third-party institution, 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 institution.

[0130] The processor can access information and applications stored in the memory via a transmission device to perform the following steps: Execute a transaction request based on credit information, including: if the credit information indicates that the customer's credit rating is a Class 1 customer, send a second notification message to the merchant, or execute a preset risk control strategy; if the credit information indicates that the customer's credit rating is a Class 2 customer, generate transaction details based on the transaction request, transaction amount, merchant information, and customer information, wherein the risk level of Class 1 customers is lower than that of Class 2 customers; perform a payment operation on the merchant based on the transaction details, store the transaction details to complete the transaction request, and initiate a supplementary deduction request to the customer at a preset time.

[0131] The processor can access the information and application stored in the memory via the transmission device to perform the following steps: After obtaining the merchant's information, the above method further 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] This application provides a transaction method for handling fault scenarios. When a business system receives a transaction request and simultaneously detects a fault in the business system, it obtains the merchant's information, where the merchant is the payee and the customer is the payer in the transaction request. Based on the merchant's information, it performs merchant access verification. If the merchant passes the verification, it determines the transaction amount based on the transaction request. If the transaction amount is less than or equal to the merchant's single transaction limit, it obtains the customer's credit information and executes the transaction request based on the credit information. This solves the technical problem that when financial institutions use emergency measures such as container devices, primary / backup switching, or even disaster recovery switching to handle faults, service interruptions can be prolonged, leading to customer service unavailability.

[0133] By acquiring merchant information during system failures of financial institutions, and conducting onboarding verification, single-transaction limit verification, and credit information determination for merchants, the system streamlines transaction processes, quickly completes merchant verification and customer credit assessment, ensuring smooth payment transactions and avoiding transaction interruptions or delays caused by system failures. This improves the stability and user experience of aggregated payment acquiring services, while also effectively reducing the risk of financial institutions having to advance funds. It achieves a balance between business continuity and risk control, enabling financial institutions to respond quickly to transaction requests in emergency scenarios. Ultimately, it provides secure and fast payment services to merchants and customers, further improving customer and merchant satisfaction.

[0134] Those skilled in the art will understand that Figure 11 The structure shown is for illustrative purposes only. Electronic devices can also be smartphones (such as Android phones, iOS phones, etc.), tablets, PDAs, mobile Internet devices (MIDs), PADs, and other terminal devices. Figure 11 This does not limit the structure of the aforementioned electronic device. For example, electronic devices may also include components that are more... Figure 11 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 11 The different configurations shown.

[0135] A person skilled in the art will 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, which 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] Embodiments of this application also provide 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 Embodiment 1.

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

[0139] This application also provides a computer program product that, when executed on a data processing device, is suitable for performing transaction method steps in a fault scenario.

[0140] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0141] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions 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. In actual implementation, there may be other division methods, such as 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 separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0144] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0145] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this 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. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0146] The above is only a preferred embodiment 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 fault scenario, characterized in that, include: When the business system receives a transaction request and detects a fault in the business system, it obtains the merchant's information, wherein the merchant in the transaction request is the payee and the customer is the payer; the merchant's information includes at least target configuration information, which indicates whether the merchant agrees to execute a target transaction strategy, and the target transaction strategy indicates a strategy to complete the transaction request by having a financial institution advance the transaction amount in the event of a business system fault. Merchant access verification is performed on the merchant based on the merchant information, including: verifying the merchant's access when the target configuration information indicates that the merchant agrees to execute the target transaction strategy; executing the transaction request through the business system when the target configuration information indicates that the merchant does not agree to execute the target transaction strategy; and generating a first prompt message, ending the transaction request, and sending the first prompt message to the customer when the merchant fails the merchant access verification. If the merchant passes the merchant access verification, the transaction amount is determined based on the transaction request; If 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; Before obtaining the merchant's information, the method further includes: obtaining the merchant's attribute information; registering the merchant with each of the N third-party institutions based on the merchant's attribute information, where N is a positive integer greater than 1; if the registration is successful, determining the merchant identification information of each third-party institution to obtain the merchant identification information of the merchant in the N third-party institutions; obtaining the merchant's single transaction limit after a preset time interval, and storing the merchant identification information corresponding to the merchant and the merchant's single transaction limit in a preset storage space. After determining the transaction amount based on the transaction request, the method further includes: querying the merchant's current single transaction limit in the 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, if the transaction amount is determined to be greater than the single transaction limit based on the comparison result, then the transaction request is rejected, and a third prompt message is returned to the customer.

2. The method according to claim 1, characterized in that, Obtaining the credit information of the customer includes: Obtain the customer's customer information, and have a third-party organization assess the customer's credit rating based on the customer information to obtain the assessment result; The third-party institution determines the customer's credit rating based on the assessment results, and determines the customer's credit information based on the customer's credit rating. Receive the credit information of the customer sent by the third-party institution.

3. The method according to claim 1, characterized in that, Executing the transaction request based on the credit information includes: If the credit information indicates that the customer's credit rating belongs to the first category of customers, a second prompt message is sent to the merchant, or a preset risk control strategy is executed; If the credit information indicates that the customer's credit rating belongs to the second category of customers, a transaction detail is generated 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 that of the second category of customers; The payment operation is performed on the merchant based on the transaction details, and the transaction details are stored to complete the transaction request. At a preset time, a supplementary deduction request is initiated to the customer.

4. The method according to claim 1, characterized in that, After obtaining the merchant's information, the method further includes: Receive modification instructions triggered by the target object; The target configuration information of the merchant is modified according to the modification instruction to obtain the modified target configuration information; Merchant access verification is performed on the merchant based on the modified target configuration information.

5. A trading device for fault scenarios, characterized in that, A transaction method for performing a fault scenario as described in claim 1, characterized in that it includes: The first acquisition unit is used to acquire merchant information when the business system receives a transaction request and detects a fault in the business system. In the transaction request, the merchant is the payee and the customer is the payer. The merchant information includes at least target configuration information, which indicates whether the merchant agrees to execute a target transaction strategy. The target transaction strategy indicates a strategy to complete the transaction request by having a financial institution advance the transaction amount in the event of a business system fault. The first verification unit is used to perform merchant access verification on the merchant based on the merchant information. 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 strategy; 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 strategy; and 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. The first determining unit is used to determine the transaction amount based on the transaction request if the merchant passes the merchant access verification. An execution unit is configured to obtain the customer's credit information and execute the transaction request based on the credit information when the transaction amount is less than or equal to the merchant's single transaction limit. The device further includes: a second acquisition unit, configured to acquire the merchant's attribute information before acquiring the merchant's merchant information, and register the merchant with each of the N third-party institutions based on the merchant's attribute information, where N is a positive integer greater than 1; a second determination unit, configured to determine the merchant identification information of each third-party institution upon successful registration, thereby obtaining the merchant identification information of the merchant in the N third-party institutions; and a third acquisition unit, configured to acquire the merchant's single transaction limit after a preset time interval, and store the merchant identification information corresponding to the merchant and the merchant's single transaction limit in a preset storage space. The device further includes: a query unit, configured to query the merchant's current single transaction limit in the preset storage space based on the merchant information after determining the transaction amount according to the transaction request; a comparison unit, configured to compare the merchant's current single transaction limit with the transaction amount to obtain a comparison result; a third determination unit, configured 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, configured to refuse to execute the transaction request and send a third prompt message to the customer if the transaction amount is determined to be greater than the single transaction limit based on the comparison result.

6. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the steps of the method described in any one of claims 1 to 4.

Images