Transaction Order Processing Method, System, Electronic Device, and Storage Medium

Abstract

The present disclosure relates to a method, a system, an electronic device, and a storage medium for processing a transaction order. The method may include: obtaining a target transaction order and a set of payment channels; determining a set of target screening policies and target transaction parameters carried in the target transaction order; screening out a first screening result that matches the target transaction parameters from multiple payment channels; screening out a second screening result that matches the set of target screening policies from the first screening result; determining a payment channel that meets the priority condition in the second screening result as the target payment channel; and performing transaction processing on the target transaction order based on the target payment channel. According to the technical solution provided by the present disclosure, by screening according to the target transaction parameters and the set of target screening policies, a payment channel that meets the current transaction requirements can be screened out from multiple payment channels, improving the accuracy of payment channel selection, effectively reducing the transaction failure rate, and enhancing the overall payment performance and transaction success rate of the system.

Description

Technical Field

[0001] The present disclosure relates to the field of electronic payment systems and financial transaction processing, and particularly to a method, system, electronic device, and storage medium for processing transaction orders. Background Art

[0002] With the rapid development of e-commerce and online payment services, especially in the context of different payment scenarios and transaction requirements, the payment system needs to flexibly select payment channels according to various parameters to ensure the smooth completion of transactions. In existing payment systems, the selection of payment channels usually involves multiple factors, including payment methods, payment products, merchant attributes, etc. The selection of payment channels directly affects the success rate of transactions, the efficiency of system operation, and the payment experience of users.

[0003] Currently, the selection of payment channels in the payment system is mainly based on a fixed configuration method, which has certain limitations in the face of complex transaction environments. For example, the parameters of a transaction order may involve different payment methods, different currencies, and requirements for transaction amounts. A single priority configuration method is difficult to comprehensively handle these changing requirements, easily resulting in inappropriate selection of payment channels, thus affecting the success rate of transactions and the overall stability of the system. In addition, the reliability of the payment system largely depends on the accurate selection and real-time adjustment of payment channels. However, since the status and service capabilities of payment channels may change at any time, such as channel maintenance, fluctuations in network conditions, etc., there is a lack of a flexible screening mechanism in the prior art to dynamically adjust the selection of payment channels, which makes it difficult for the payment system to cope with the real-time changes in the status of payment channels, resulting in the failure of processing some transaction orders. Especially in the case of coexistence of multiple payment channels and complex payment requirements, the inaccuracy of channel selection and the lack of dynamic adjustment capabilities may further lead to a decline in the payment experience. Summary of the Invention

[0004] The present disclosure provides a method, system, electronic device, and storage medium for processing transaction orders to at least solve the problem of how to flexibly select payment channels to meet transaction requirements in related technologies. The technical solutions of the present disclosure are as follows:

[0005] According to the first aspect of the embodiments of the present disclosure, a method for processing a transaction order is provided, including:

[0006] Obtaining a target transaction order and a set of payment channels; the set of payment channels includes multiple payment channels;

[0007] Determining a set of target screening strategies and target transaction parameters carried in the target transaction order; the set of target screening strategies refers to the screening strategies dynamically configured for the target transaction order;

[0008] Screen out a first screening result that matches the target transaction parameters from the multiple payment channels; the first screening result includes at least one payment channel;

[0009] Screen out a second screening result that matches the target screening strategy set from the first screening result;

[0010] Determine the payment channels that meet the priority conditions in the second screening result as the target payment channels;

[0011] Perform transaction processing on the target transaction order based on the target payment channels.

[0012] According to a second aspect of the embodiments of the present disclosure, there is provided a transaction order processing system, including:

[0013] An acquisition module, configured to acquire a target transaction order and a payment channel set; the payment channel set includes multiple payment channels;

[0014] A parameter and set determination module, configured to determine a target screening strategy set and target transaction parameters carried in the target transaction order; the target screening strategy set refers to screening strategies dynamically configured for the target transaction order;

[0015] A first determination module, configured to screen out a first screening result that matches the target transaction parameters from the multiple payment channels; the first screening result includes at least one payment channel;

[0016] A second determination module, configured to screen out a second screening result that matches the target screening strategy set from the first screening result;

[0017] A channel determination module, configured to determine the payment channels that meet the priority conditions in the second screening result as the target payment channels;

[0018] A transaction module, configured to perform transaction processing on the target transaction order based on the target payment channels.

[0019] According to a third aspect of the embodiments of the present disclosure, there is provided an electronic device, including: a processor; a memory for storing executable instructions of the processor; wherein, the processor is configured to execute the instructions to implement the method according to any one of the first aspects above.

[0020] According to a fourth aspect of the embodiments of the present disclosure, there is provided a computer-readable storage medium, when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, enabling the electronic device to execute the method according to any one of the first aspects of the embodiments of the present disclosure.

[0021] According to a fifth aspect of the embodiments of the present disclosure, there is provided a computer program product including computer instructions, which when executed by a processor cause the computer to execute the method according to any one of the first aspects of the embodiments of the present disclosure.

[0022] The technical solutions provided by the embodiments of the present disclosure at least bring the following beneficial effects:

[0023] By obtaining the target transaction order and the set of payment channels, it is possible to match all payment channels with the transaction attributes of the order, ensure the availability of payment channels throughout the transaction process, improve the basic accuracy of payment channel selection, and reduce the participation of invalid payment channels; by determining the set of target screening strategies and target transaction parameters, the selection of payment channels can be dynamically adjusted according to the specific attributes of the target transaction order, improving the pertinence and flexibility of payment channel screening;

[0024] After obtaining the set of payment channels, a preliminary screening is performed through target transaction parameters to obtain a first screening result, reducing the payment channels that do not meet the requirements and improving the efficiency of subsequent screening and sorting; a second screening result that matches the set of target screening strategies is screened out from the first screening result, making the screened payment channels meet all strategy requirements and improving the success rate of the transaction; by determining the target payment channel according to the priority conditions in the second screening result and preferentially selecting the payment channel that meets the current transaction requirements, the selection of payment channels has higher flexibility; based on the target payment channel, transaction processing is performed on the target transaction order, and the payment request can be processed in a timely manner according to the suitable payment channel, enabling the transaction to be successfully completed.

[0025] In summary, the present disclosure ensures the selection of payment channels and the completion of transactions through multiple screenings and priority sorting of the target transaction order and payment channels, improving the success rate of transactions, reducing the failure risk, and optimizing the system operation efficiency.

[0026] It should be understood that the above general description and the following detailed description are only exemplary and explanatory, and do not limit the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] The accompanying drawings herein are incorporated into the specification and constitute a part of this specification, showing embodiments consistent with the present disclosure and used together with the specification to explain the principles of the present disclosure, and do not constitute an improper limitation to the present disclosure.

[0028] Figure 1 is a schematic diagram of an application environment shown according to an exemplary embodiment.

[0029] Figure 2 is a flowchart of a transaction order processing method shown according to an exemplary embodiment.

[0030] Figure 3 It is a flowchart of obtaining a first screening result through screening shown according to an exemplary embodiment.

[0031] Figure 4 It is a flowchart of obtaining a second screening result through screening shown according to an exemplary embodiment.

[0032] Figure 5 It is a block diagram of a transaction order processing system shown according to an exemplary embodiment.

[0033] Figure 6 It is a block diagram of an electronic device for transaction order processing shown according to an exemplary embodiment. Detailed implementation manners

[0034] In order to enable those of ordinary skill in the art to better understand the technical solutions of the present disclosure, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below with reference to the accompanying drawings.

[0035] It should be noted that the terms "first", "second", etc. in the specification and claims of the present disclosure and the above-mentioned drawings are used to distinguish similar objects, and do not necessarily have to be used to describe a specific order or sequence. It should be understood that such used data may be interchanged under appropriate circumstances so that the embodiments of the present disclosure described herein can be implemented in an order different from those illustrated or described herein. The implementation manners described in the following exemplary embodiments do not represent all implementation manners consistent with the present disclosure. On the contrary, they are merely examples of devices and methods consistent with some aspects of the present disclosure as detailed in the appended claims.

[0036] Please refer to Figure 1 , Figure 1 It is a schematic diagram of an application environment shown according to an exemplary embodiment. As Figure 1 shown, the application environment may include a transaction order processing system 10, an external data source 20, and a terminal device 30.

[0037] The transaction order processing system 10 can be used to process transaction orders and dynamically select appropriate payment channels. The transaction order processing system 10 can include multiple subsystems, including an order management system 11, a channel selection system 12, a transaction execution system 13, a script management system 14, and a data call system 15. The order management system 11 can be used to obtain and manage the submitted transaction order information and transfer the relevant information to the channel selection system 12; the channel selection system 12 can select a payment channel that meets the current transaction requirements according to the transaction parameters and screening strategies carried in the transaction order; the transaction execution system 13 can be used to process the transaction order based on the target payment channel; the script management system 14 can be used to manage and execute dynamic scripts; the data call system 15 can be used to obtain information related to payment channel selection from an external data source 20.

[0038] The external data source 20 can be used to provide external information related to payment channel selection, such as the real-time service status of the payment channel, network conditions, transaction statistics data, etc. The external data source 20 can include a banking system, a third-party payment platform, etc. The transaction order processing system 10 can interact with the external data source 20 through the data call system 15 to obtain the real-time status and other external data of the payment channel, so as to optimize and dynamically adjust the payment channel selection.

[0039] The terminal device 30 can be used to submit a transaction request. The terminal device 30 can be a computer, a mobile device, or other devices with networking capabilities. The terminal device 30 can be used to submit a transaction order to the transaction order processing system 10 so that the system can process the transaction order. The terminal device 30 and the transaction order processing system 10 can achieve real-time data transmission and feedback through a network connection.

[0040] In addition, through the collaborative work of the script management system 14 and the data call system 15, the real-time status and feedback information of the payment channel can be obtained, the payment channel screening strategy can be dynamically adjusted, and the script can be executed according to the current transaction parameters, thereby improving the processing efficiency and success rate of transaction orders.

[0041] In an alternative embodiment, the transaction order processing system 10, the external data source 20, and the terminal device 30 can be connected through a LAN (Local Area Network), a WAN (Wide Area Network), or a 5G / 4G-based mobile data network to achieve real-time transmission of transaction data and channel status information.

[0042] In practical applications, through the collaborative work of each module of the transaction order processing system 10 and combined with the real-time information provided by the external data source 20, the payment channel can be dynamically and flexibly selected and adjusted to meet complex and changeable transaction requirements, improving the payment success rate of the system and the overall transaction experience.

[0043] In addition, it should be noted that Figure 1 The shown is only an application environment of the transaction order processing method provided by this disclosure.

[0044] It should be noted that the following shows a possible step sequence, and actually it is not limited to strictly follow this sequence. Some steps can be executed in parallel without mutual dependence. The user information (including but not limited to user device information, user personal information, user behavior information, etc.) and data (including but not limited to data for display, training data, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties.

[0045] Figure 2 It is a flowchart of a transaction order processing method shown according to an exemplary embodiment. As Figure 2 shown, it may include the following steps.

[0046] In step S201, obtain the target transaction order and the set of payment channels.

[0047] In the embodiments of this specification, the target transaction order may be an order request containing basic transaction information generated by the transaction order processing system.

[0048] The set of payment channels may be a set of multiple payment channels supporting different payment methods. The payment channels may be associated with information such as payment methods, payment products, signing entities, channel codes, etc., and are attached with many configuration parameters, including priority, weight, 3DS (3-Domain Secure) support, quick payment support, channel gateway application, refund application, channel maintenance time, channel service scope, etc.

[0049] In a possible implementation, the target transaction order can be obtained from the terminal device. The terminal device may include various networked devices, such as POS machines (Point of Sale), mobile payment devices, or online payment terminals, etc. After the order management system receives the order information, it can transfer the information to the channel selection system for subsequent processing.

[0050] In an alternative implementation, the channel selection system may need to interact with the payment channel multiple times to complete authentication or payment authorization. For example, during a transaction, the payment channel may require additional authentication steps such as 3DS verification, payment authorization, etc., which can be achieved through multiple interactions between the payment channel and the order management system.

[0051] In another possible implementation, the target transaction order can be obtained through real-time communication with the terminal device. For example, the terminal device submits a transaction order through the user's payment request. The order management system can establish a connection with the terminal device through the network interface, receive the order data and perform verification to protect the integrity and correctness of the order information.

[0052] In an alternative implementation, the payment channel set can be managed through a database within the transaction order processing system. This database can record the configuration information of all available payment channels. After receiving the target transaction order, the order management system can query this database to obtain the payment channel set to ensure that the obtained payment channels are available and meet the requirements of the current transaction.

[0053] In a possible implementation, when obtaining the payment channel set, all available payment channels with normal current status and meeting the transaction attributes can be preferentially selected to make the subsequent screening process more efficient.

[0054] In practical applications, by obtaining the target transaction order and the payment channel set, different payment requests can be quickly responded to, ensuring that the obtained payment channels are available during the transaction and support the attributes of the target transaction order, thereby improving the success rate of the transaction and the overall operating efficiency of the system.

[0055] In step S203, determine the target screening strategy set and the target transaction parameters carried in the target transaction order.

[0056] In the embodiments of this specification, the target screening strategy set may refer to the screening strategies dynamically configured for the target transaction order.

[0057] The target transaction parameters can be information related to the transaction extracted from the target transaction order, including but not limited to payment method, transaction amount, currency, merchant attributes, etc.

[0058] In a possible implementation, after receiving the target transaction order, applicable screening strategies can be matched based on the attributes of the target transaction order and the configuration requirements of the transaction order processing system, thereby generating the target screening strategy set. The target screening strategy set can include various conditions for determining payment channels, such as transaction amount, payment method, etc., so as to meet the payment requirements of different transaction scenarios.

[0059] In an alternative implementation, a target screening strategy set can be generated according to the transaction attributes of a certain merchant or a preset screening strategy to optimize the payment channel selection process.

[0060] In a possible implementation, the target transaction parameters carried in the target transaction order can be extracted through an order management system. After receiving the target transaction parameters, the channel selection system can match the applicable screening strategies according to these parameters and dynamically generate a target screening strategy set to ensure the flexibility and accuracy of the payment channel selection process.

[0061] In practical applications, by determining the target screening strategy set and the target transaction parameters, different transaction requirements can be effectively met, and the selection of payment channels can be dynamically adjusted to improve the payment success rate and the overall operation efficiency of the system.

[0062] In step S205, a first screening result that matches the target transaction parameters is screened out from multiple payment channels; the first screening result includes at least one payment channel.

[0063] In the embodiments of this specification, the first screening result can be a set of payment channels that match the target transaction parameters screened out from multiple payment channels.

[0064] In a possible implementation, after receiving the target transaction order, through the channel selection system of the transaction order processing system, according to the target transaction parameters carried in the target transaction order, which can include payment methods, payment products, transaction amounts, etc., the payment channels that meet the requirements are screened out from the payment channel set to form the first screening result.

[0065] In practical applications, by screening out the first screening result that matches the target transaction parameters from multiple payment channels, the accuracy of the payment channel selection can be effectively improved, ensuring that the selected payment channels meet the requirements of the target transaction order, thereby improving the success rate of transactions and the overall operation efficiency of the system.

[0066] In a possible implementation, the target transaction parameters include payment product information and payment method information; in the case where a preset channel set exists, the preset channel set is obtained and determined as the pre-screening result; or, in the case where the preset channel set does not exist, according to the payment product information and the payment method information, a pre-screening result that matches the target transaction parameters is screened out from multiple payment channels; a first screening result that matches the target configuration information is screened out from the pre-screening result.

[0067] In the embodiments of this specification, payment product information may refer to specific payment products involved in the transaction process, such as bank card payment, QR code payment, WeChat payment, etc. The payment product information may also include the specific categories and characteristics of the payment products, such as whether installment payment is supported, etc.

[0068] Payment method information may be specific payment methods related to the payment product. For example, for bank card payment, the payment methods may be credit cards, debit cards, etc.; for QR code payment, the payment methods may be dynamic codes, merchant codes, etc.; for WeChat payment, the payment methods may be dynamic codes, merchant scanning codes, in-app payment, etc.

[0069] The preset channel set may be a group of payment channels pre-configured by the target resource recipient (such as a merchant or a site) according to its business needs and transaction characteristics. The preset channel set is usually associated with the payment product, payment method, and merchant attributes in the target transaction order, representing one or more payment channels set by the target merchant and adapted to the target transaction order. The preset channel set may be configured based on factors such as the preferences of the target resource recipient, cost-effectiveness, historical transaction data, etc.

[0070] The pre-screening result may be the preset channel set or a set of payment channels screened from all payment channels according to the payment product information and payment method information, representing a group of payment channels that match the target transaction order in the preliminary screening and will enter the subsequent screening steps.

[0071] The target configuration information may be configuration parameters related to the payment channel selection, specifically including but not limited to the service time of the channel, the range of transaction currencies, whether specific security verification is required, etc. The target configuration information is used to further match the characteristics of the payment channels based on the pre-screening result.

[0072] In a possible implementation manner, after receiving the target transaction order, the internal database may be accessed or interacted with the external system through the data call system to obtain the preset channel set related to the target merchant. The preset channel set is a group of payment channels pre-configured by the merchant, and these channels match the parameters such as the payment method and payment product of the target transaction order. If the preset channel set exists, it can be directly determined as the pre-screening result.

[0073] In an alternative implementation manner, the process of obtaining the preset channel set may be achieved by querying the database. The database records the payment channel configurations related to each merchant, and these configurations may be based on the merchant's historical transaction records, the merchant's business characteristics, and channel costs, etc. After receiving the target transaction order, the order management system can directly query the database to determine the preset channel set. If a preset channel set that matches the target transaction order is queried, it can be determined as the pre-screening result.

[0074] In another possible implementation, if the target merchant has not pre-configured a preset channel set adapted to the target transaction order, the payment product information and payment method information carried in the target transaction order are used as screening conditions. By comparing the configuration parameters associated with each payment channel in the payment channel set, a payment channel set that meets the transaction requirements is screened out from all available payment channels as the pre-screening result. For example, if the target transaction order involves the credit card payment method in the bank card payment product, the channel selection system will select the payment channels that support the credit card payment method from all payment channels to form the pre-screening result.

[0075] In one possible implementation, the payment channels in the pre-screening result can be checked one by one, and a first screening result that matches the target configuration information is further screened out from the pre-screening result. The target configuration information may include the service availability of the channel, whether it supports the transaction amount range, whether 3DS dynamic authentication is required, etc. Only the payment channels that meet all the requirements of the target configuration information will be retained in the first screening result.

[0076] Exemplarily, for the 3DS dynamic authentication, it can be implemented through the following logic:

[0077] If the merchant configures mandatory use of 3DS verification, then only the payment channels that support 3DS verification will be selected, excluding the payment channels that do not support 3DS. The payment channels that do not support 3DS will not be included in the first screening result.

[0078] If the merchant does not mandatorily require 3DS verification, but the available payment channels only support 3DS verification, then even if the merchant's configuration does not require it, the transaction will be upgraded to 3DS verification. Even if the merchant does not explicitly set the 3DS requirement, the payment process will still be carried out according to the more stringent 3DS security standard.

[0079] If the merchant does not configure the requirement for 3DS verification, but the risk control standard requires 3DS verification, then the payment channels that support 3DS verification will be selected, regardless of whether the merchant has configured this requirement, to ensure the security of the transaction.

[0080] In practical applications, by obtaining the preset channel set and performing corresponding screening, the process of selecting payment channels can be effectively simplified, the computational overhead of screening can be reduced, and the efficiency of transaction order processing can be improved. At the same time, according to the merchant's settings and risk control strategies, channel screening is carried out according to the same-level or higher security requirements, which not only meets the basic configuration requirements of the merchant, but also can be adjusted according to the risk control requirements or the support situation of the payment channels themselves, thereby enhancing the security and flexibility of the transaction.

[0081] In a possible implementation, the target configuration information includes service - type configuration information, transaction - type configuration information, verification - type configuration information, and query - type configuration information; a first screening result that matches the service - type configuration information, transaction - type configuration information, verification - type configuration information, and query - type configuration information is screened out from the pre - screening results.

[0082] In the embodiments of this specification, the service - type configuration information may refer to parameters related to the service availability of the payment channel, such as the service time of the payment channel, service coverage area, and other information.

[0083] The transaction - type configuration information may refer to parameters related to transaction processing, such as the transaction amount range, supported transaction currencies, the processing capacity of the payment channel, etc.

[0084] The verification - type configuration information may refer to parameters related to payment security verification, such as whether 3DS verification is required, whether a specific authentication protocol is supported, etc.

[0085] The query - type configuration information may refer to parameters related to transaction query or status feedback, such as whether the payment channel supports functions such as transaction status query and refund query.

[0086] In a possible implementation, the payment channels in the pre - screening results can be further inspected to screen out the payment channels that meet all the requirements of the service - type configuration information, transaction - type configuration information, verification - type configuration information, and query - type configuration information as the first screening result. For example, if the target transaction order involves a transaction amount greater than 10,000 yuan and requires identity verification (such as SMS verification code or dynamic password), then the payment channels that meet the following conditions can be screened out: available within the service time, supporting a transaction amount greater than 10,000 yuan, having the required identity verification function, etc. After checking the service - type configuration information, transaction - type configuration information, verification - type configuration information, and query - type configuration information of each payment channel one by one, the selected payment channels meet all the requirements of the target transaction order and are returned as the first screening result.

[0087] In an alternative implementation, various types of target configuration information can be applied according to the different attributes of the target transaction order to perform a more refined screening of the pre - screening results. For example, for transactions of certain merchants, 3DS verification may not be required, but transactions in specific currencies need to be supported.

[0088] In practical applications, by further screening the payment channels in the pre - screening results, the requirements in aspects such as services, verification, and query can be met, thereby improving the success rate and security of transactions, and enhancing the user's payment experience and the overall operating efficiency of the system.

[0089] Exemplarily, takeFigure 3 For example, Figure 3 FIG. 1 is a flowchart showing a first screening result obtained through screening according to an exemplary embodiment. First, obtain a target transaction order and a set of payment channels. The target transaction order may include basic information of the transaction, such as merchant information, transaction amount, payment product information, payment method information, etc. Through the obtained target transaction order, start the screening process. Determine the target transaction parameters and determine whether there is a preset channel set. If the preset channel set exists, use the preset channel set as the preliminary screening result.

[0090] If the target transaction order does not have a preset channel set, screen out a set of channels that match the target transaction parameters from multiple payment channels as the preliminary screening result. Screen out the payment channels that match the service class configuration information from the preliminary screening result. The service class configuration information may include the service time of the payment channel, the service coverage area, etc., and screen each payment channel in the preliminary screening result one by one to confirm whether its service class attributes meet the transaction requirements. Continue to screen the payment channels based on the transaction class configuration information. The transaction class configuration information may include the transaction amount range, supported currencies, channel processing capabilities, etc., to ensure that the selected payment channels fully meet the target transaction order in terms of transaction class requirements.

[0091] Further, continue to screen the payment channels based on the verification class configuration information. The verification class configuration information may include whether the payment channel supports a specific verification method (such as 3DS verification) and whether it has a verification ability that meets the system security standards. Continue to screen the payment channels based on the query class configuration information. The query class configuration information may include whether the payment channel supports functions such as status query and refund query to ensure that the selected payment channels can provide comprehensive transaction query services.

[0092] Through the above steps, the first screening result is finally obtained.

[0093] In practical applications, through this screening process, the selection process of payment channels can be made more efficient and accurate, ensuring that the selected payment channels meet the requirements of the target transaction order, thereby improving the transaction success rate and overall operation efficiency.

[0094] In a possible implementation, obtain a preset screening policy set; in the case where the preset screening policy set exists, determine the preset screening policy set as the target screening policy set.

[0095] In the embodiments of this specification, the preset screening policy set may represent the screening policy dynamically configured by the target resource recipient for the target transaction order.

[0096] In a possible implementation, the order management system can obtain a set of preset screening policies that match the target transaction order from the database. Different sets of screening policies set by the target resource recipient for different types of transaction orders can be recorded in the database. If there is a set of preset screening policies that match the target transaction order, then directly determine this set as the target screening policy set.

[0097] In another possible implementation, the preset screening policy set can be obtained by the data call system interacting with an external system. For example, the target resource recipient may configure screening policies in different third-party payment platforms or bank systems. After confirming that the screening policy set exists and matches the target transaction order, it can be determined as the target screening policy set.

[0098] In practical applications, by obtaining the preset screening policy set, the process of selecting screening policies can be effectively simplified, the efficiency of transaction processing can be improved, and at the same time, the selection of payment channels can meet the business requirements and transaction characteristics of the target resource recipient.

[0099] In a possible implementation, in the case where the preset screening policy set does not exist, obtain the screening policy corresponding to the target transaction parameter as the screening policy set to be configured; verify the screening policy set to be configured; in the case where the screening policy set to be configured meets the target screening conditions, determine the screening policy set to be configured as the target screening policy set; or, in the case where the screening policy set to be configured does not meet the target screening conditions, obtain the default screening policy set as the target screening policy set.

[0100] In the embodiments of this specification, the screening policy set to be configured can be a screening policy set dynamically generated in the transaction order processing system according to the target transaction parameter, which includes screening requirements corresponding to the target transaction parameter, such as the upper limit of the transaction amount, merchant type, payment method support range, etc. The screening policy set to be configured is used to dynamically configure screening policies for the target transaction order when the preset screening policy set does not exist.

[0101] The target screening conditions can be the criteria for verifying the effectiveness of the screening policy set to be configured, and are used to determine whether the selected policy conforms to the business logic and can be used for transaction processing. For example, the target screening conditions can include whether the policy set is complete, whether the parameter configuration meets the minimum requirements of the target transaction order, etc.

[0102] The default screening policy set can include some basic payment channel selection policies, which may include, for example, the basic service availability of the channel, the basic range of the transaction amount, the minimum support requirements for payment methods, etc.

[0103] In a possible implementation, when the preset screening policy set does not exist, the to-be-configured screening policy set can be obtained according to the payment product information and payment method information in the target transaction order.

[0104] In a possible implementation, after obtaining the to-be-configured screening policy set, its effectiveness can be determined by verifying whether the parameters in the to-be-configured screening policy set meet the target screening conditions. For example, if the transaction amount limit in the policy set matches the transaction amount of the target transaction order and all necessary security verification policies are configured, the policy set can be confirmed to be effective. When the to-be-configured screening policy set meets the target screening conditions, it is determined as the target screening policy set.

[0105] In another possible implementation, if the to-be-configured screening policy set fails to meet the preset screening conditions, the default screening policy set will be used as the target screening policy set. The default screening policy set is set to handle the situation where an effective to-be-configured policy set cannot be generated and contains the minimum necessary parameter configurations, which can ensure the payment processing of the transaction order under certain security and reliability conditions.

[0106] In practical applications, by verifying and adjusting the to-be-configured screening policy set, a suitable screening policy can be dynamically generated and applied when the preset screening policy is unavailable, thereby improving the flexibility and success rate of transaction processing and ensuring the stability of the system in various transaction scenarios. If the to-be-configured screening policy does not meet the requirements, the default screening policy set can reduce the possibility of transaction failure, thereby increasing the overall transaction success rate.

[0107] In step S207, the second screening result that matches the target screening policy set is screened out from the first screening result.

[0108] In the embodiments of this specification, the second screening result may refer to a group of payment channels that are further screened from the first screening result after preliminary screening and meet the conditions of the target screening policy set.

[0109] In a possible implementation, the generation process of the second screening result can be completed by the channel selection system. After receiving the first screening result, according to the screening conditions included in the target screening policy set, the payment channels in the first screening result are matched, and the payment channels that meet all policy requirements are screened out to form the second screening result. For example, the target screening policy set may include requirements for aspects such as the service response time of the payment channel, the fee charging standard, the stability of the payment channel, and the available time of the service. Only the payment channels that meet the target screening policy set will be retained in the second screening result.

[0110] In practical applications, by further screening the payment channels that meet the target screening strategy set from the first screening result, the payment path can be effectively optimized, so that the finally selected payment channel meets the specific requirements of the transaction, thereby improving the success rate of the transaction and the system operation efficiency.

[0111] In one possible implementation, the target screening strategy set includes a target screening strategy and a target sorting strategy; the payment channels that match the target screening strategy are screened out from the first screening result and sorted according to the target sorting strategy to obtain a second screening result.

[0112] In the embodiments of this specification, the target screening strategy can be a part of the target screening strategy set, such as the requirements for the stability, response time, and supported transaction methods of the payment channel.

[0113] The target sorting strategy can be another part of the target screening strategy set, which refers to the rule for prioritizing the payment channels that meet the screening strategy, such as sorting based on the fees of the payment channel, service response speed, transaction success rate, etc.

[0114] In one possible implementation, a set of payment channels that meet the target screening strategy is screened out, and this set of payment channels is sorted according to the target sorting strategy to obtain a second screening result. For example, if the target sorting strategy requires preferentially selecting payment channels with lower transaction fees, the channel selection system will sort the payment channels that meet the screening conditions based on this criterion.

[0115] In practical applications, by screening and sorting the payment channels, the payment path can be effectively optimized, and the efficiency and success rate of transaction processing can be improved.

[0116] In one possible implementation, the target screening strategy set consists of one or more target routing conditions; each target routing condition corresponds to a set of target scripts; the target screening strategy set is parsed to obtain one or more target routing conditions; the target scripts corresponding to each target routing condition are obtained; and multiple target scripts are executed to screen and sort from the first screening result to obtain a second screening result.

[0117] In the embodiments of this specification, the target routing condition can be a component of the target screening strategy set, and each target routing condition represents a business requirement or screening requirement for screening payment channels, such as the geographical coverage of the payment channel, the service time of the channel, transaction limits, response speed, compatibility of payment methods, etc.

[0118] The target script can be a dynamic program instruction set corresponding to each target routing condition. Each set of target scripts screens and sorts the characteristics of the payment channels according to the specific requirements of the target routing condition.

[0119] In a possible implementation, the channel selection system can parse the set of target screening policies to obtain one or more target routing conditions. After parsing out the target routing conditions, the corresponding target scripts for these target routing conditions are obtained one by one. For example, if the set of target screening policies contains multiple routing conditions, respectively requiring that the service response time of the payment channel within a specific time period is lower than a certain threshold and supporting high transaction amounts, then the target scripts corresponding to these conditions are executed one by one. In the target script, the configuration parameters related to the payment channel can be detected in real time, such as calculating the response speed and transaction limit of the payment channel, and filtering out the payment channels that meet all the target routing conditions.

[0120] In a possible implementation, during the execution of the target script, not only is it determined whether the payment channel meets the target routing conditions to ensure that the payment channels that meet the requirements enter the second screening result, but also the sorting of the payment channels is involved. Each payment channel can be sorted according to its corresponding priority or weight, ensuring that during the screening and sorting process, the payment channels that meet the business requirements are preferentially selected.

[0121] Exemplarily, the priority can be set by directly specifying the priority order of a certain payment channel among the same type of channels. For example, for a specific merchant, the priority may be determined according to the cumulative interaction times. The payment channel with more cumulative interaction times has a higher priority than the one with fewer interaction times; the payment channel with the most cumulative interaction times can be used as the first priority, and the other payment channels are arranged in the order of interaction times. The priority can also be dynamically adjusted through historical transaction data. For example, if a certain payment channel shows excellent transaction success rate within a specific time period, its priority can be temporarily increased.

[0122] The weight is set by performing a weighted calculation based on multiple configuration parameters of the payment channel. Specifically, the weight of the payment channel may include but is not limited to the following aspects: transaction success rate, service response time, transaction fee, current load, etc. For example, the transaction success rate of the payment channel can account for 50% of the weight ratio, the fee accounts for 20%, the response time accounts for 20%, and the current load accounts for 10%. Through the weighted calculation of these attributes, the final sorting score of each payment channel can be obtained, thereby realizing refined payment channel selection. During the weighting process, if a certain payment channel has a high transaction success rate, its proportion in the total score will be larger, thereby increasing its likelihood of being selected.

[0123] Sorting based on priority or weight allows for the preferential selection of payment channels that meet the requirements during peak trading periods, ensuring the smooth progress of payments. For example, during peak trading periods, some payment channels may experience response delays due to high loads. The target script can sort by attaching respective weights based on the real-time status of the payment channels (such as current load and response speed), adjust the sorting of the payment channels, and obtain a list of payment channels sorted by priority with lower load and faster response speed. At the same time, under the combined action of priority and weight, the most suitable payment channel can be flexibly selected according to business requirements, ensuring the efficiency and stability of the payment process.

[0124] In practical applications, by parsing and executing multiple target scripts for the target screening strategy set, payment channels that meet specific routing conditions can be dynamically and flexibly screened, and priority sorting can be performed on this basis. Such a screening and sorting process can improve the accuracy and real-time nature of payment channel selection, thus having higher flexibility and response capabilities when dealing with complex transaction requirements.

[0125] In a possible implementation, obtain external call information and dynamic adjustment information for multiple target scripts; update the multiple target scripts based on the external call information and dynamic adjustment information to obtain target updated scripts; execute the multiple target updated scripts, screen and sort from the first screening result to obtain a second screening result.

[0126] In the embodiments of this specification, the external call information may refer to information related to the payment environment obtained from an external data source during the payment channel selection process, such as the real-time status of payment channels, network load conditions, etc. The external call information is mainly used to help administrators adjust the payment channel selection strategy according to the current payment environment conditions to optimize the selection of payment channels.

[0127] The dynamic adjustment information may refer to relevant information actively modified by the administrator to adjust the execution logic of the target script, such as rules and parameters for updating aspects such as the priority of payment channels, response speed, and current load.

[0128] The target update script can be a new set of scripts obtained by updating the version of the original target script by combining external call information and dynamic adjustment information. Specifically, the target update script is not automatically modified or adjusted by the target script itself to complete the update. Instead, under the active intervention of developers or system administrators, through version iteration of the target script, that is, during the execution of the target script, based on external call information (such as the load status of payment channels, network conditions, etc.) and dynamic adjustment information manually set according to business requirements or system conditions, the administrator actively adjusts its configuration and rules to update the target script to a new version, thereby adjusting and optimizing the target script so that the target script can better adapt to the current payment environment and business requirements.

[0129] Exemplarily, if the external call information indicates that some payment channels respond slowly due to high load, the target update script can instruct to adjust the priorities of these payment channels or exclude them from the candidate channels to ensure the smooth progress of transaction processing.

[0130] In a possible implementation, the target script can make a remote call through an HTTP (Hyper Text Transfer Protocol) request object to access external data sources in real time and obtain external information related to the payment environment, such as the real-time status of payment channels, network load, service response, etc. The data call system can adjust the screening and sorting strategies according to the obtained external call information and apply these adjustment information to the target script, thereby optimizing the selection of payment channels. For example, during the peak transaction period, if a certain payment channel has a high load, the external call information can be obtained through a remote call, and the priority or screening conditions of the payment channel can be adjusted in the target update script.

[0131] In a possible implementation, the target script can be updated by combining the dynamic adjustment information of multiple target scripts. The dynamic adjustment information can include modifying the priorities of payment channels, adjusting the sorting strategy, or actively modifying the screening strategy according to the current business requirements. For example, the target script can be modified through the dynamic adjustment information to obtain the updated target update script. When executing the target update script, the priorities of some payment channels can be reduced or they can be excluded from the candidate list.

[0132] In an alternative implementation, the target script can be implemented in ways such as Groovy (Groovy Class) classes, Groovy (Groovy Expression) expressions, Drools (an open-source business rule management system), etc., and supports target compilation and execution. When executed for the first time, the script can be automatically compiled, and the compiled script can be stored in the local cache to improve execution efficiency. When the script needs to be updated, the cache is cleared and the updated script is reloaded to implement the dynamic refresh and replacement functions of the logic. This design allows the script content to be adjusted in a timely manner when the routing logic and business requirements change, thereby maintaining the flexibility and adaptability of the system.

[0133] In practical applications, by obtaining external call information and dynamically adjusting the target script, it is possible to achieve the dynamicization and intelligentization of payment channel selection, effectively respond to changes in the payment environment, and improve the accuracy and efficiency of payment path selection. The introduction of the target update script makes the screening process of payment channels no longer static, but can be adjusted in real time according to changes in external conditions, thereby improving the success rate and stability of payment transactions.

[0134] Exemplarily, taking Figure 4 as an example, Figure 4 FIG. is a flowchart showing a second screening result obtained through screening according to an exemplary embodiment. First, it is determined whether there is a target screening policy set. If the preset target screening policy set exists, it is directly determined as the target screening policy set; otherwise, it is further determined whether the target transaction order has relevant configuration requirements that match the target screening policy set.

[0135] In the case where the target screening policy set exists, the preset screening policy set is used as the target screening policy set. On the contrary, if there is no preset screening policy set, but the target transaction order has relevant configuration requirements, a corresponding screening policy set can be generated as the target screening policy set. If the target screening policy set cannot meet the target screening conditions, the default screening policy set is used as the target screening policy set.

[0136] After determining the set of target screening strategies, gradually analyze each target routing condition in the set. Each target routing condition may include different requirements for payment channel service attributes, transaction attributes, verification attributes, etc. For each target routing condition, obtain the corresponding target script and execute these scripts to further screen the payment channels. For example, a certain target routing condition may involve the availability requirement of the payment channel within a specific time period, and the target script can judge the available time of each payment channel. During the execution of multiple target scripts, screen and sort the payment channels multiple times to determine the set of payment channels that finally meet the target routing conditions. Specifically, according to the sorting rules in the set of target screening strategies, sort the eligible payment channels according to priority or weight to ensure that the payment channels that best meet the transaction requirements are ranked at the front. After completing the screening and sorting, obtain the second screening result.

[0137] In practical applications, through this process of multiple screening, sorting, and script execution, it can be ensured that the selection of payment channels meets the requirements of specific businesses, has good adaptability to changes in the trading environment, and improves the accuracy and success rate of the payment process.

[0138] In a possible implementation manner, the external call information includes channel information, transaction information, and memory information; based on the channel information, transaction information, memory information, and dynamic adjustment information, update multiple target scripts to obtain target update scripts.

[0139] In the embodiments of this specification, the channel information may refer to specific data related to the payment channel, such as the name, identification code, service type, current availability status, etc. of the payment channel.

[0140] The transaction information may refer to data related to the current transaction, such as the transaction amount, transaction type, transaction time, etc.

[0141] The memory information may refer to historical transaction records and the usage situation of the payment channel, such as the transaction success rate, historical response time, failure rate, etc. of a certain payment channel within a specific time period.

[0142] In a possible implementation, the target script can be updated according to the channel information, transaction information, and memory information, combined with the dynamic adjustment information, and the screening rules and priorities of the target script can be adjusted in real time to form a target update script. For example, the availability of the payment channel can be adjusted according to the channel information, the priority can be adjusted based on the transaction information, or the selection weight of certain channels can be dynamically reduced using the memory information; if a certain payment channel has a high failure rate in recent use, the priority of this payment channel can be reduced through the memory information, or the priorities of certain channels can be adjusted according to the transaction amount; when it is detected that a certain payment channel cannot provide normal services due to high network load, this channel can be removed from the candidate list or its priority can be reduced.

[0143] In a possible implementation, the target script can achieve reverse control of the payment channel. When a large number of failed transactions or high load occur in the payment channel, the priority of this payment channel can be reduced or even the channel can be closed through the target script to ensure system stability and transaction success rate. For example, the transaction success rate and load status of the payment channel can be monitored in real time. When the failure rate of a certain channel exceeds a predetermined threshold, its priority can be reduced or it can be removed from the optional channels until the problem is solved.

[0144] In practical applications, by updating the target script by combining the channel information, transaction information, memory information, and dynamic adjustment information, dynamic adjustment and optimization of the payment channel selection can be achieved, making the selection process more intelligent and real-time. The introduction of the target update script improves the flexibility and adaptability of the payment channel selection, can better cope with changes in the transaction environment, and enhances the payment success rate and user experience.

[0145] In step S209, the payment channels that meet the priority conditions in the second screening result are determined as the target payment channels;

[0146] In the embodiments of this specification, the priority condition can be a numerical criterion for determining the payment channel selection order. For example, the payment channel that meets the first priority ranking, or the payment channels that meet the top two rankings.

[0147] The target payment channel can be the payment channel finally selected from the second screening result to complete the target transaction order.

[0148] In a possible implementation, the payment channels in the second screening result can be sorted according to the priority conditions, and the payment channel with the highest priority can be selected as the target payment channel. For example, if both payment channel A and payment channel B meet the requirements of the target transaction order, but the transaction fee of payment channel A is lower and the response speed is faster, the channel selection system will preferentially select payment channel A as the target payment channel.

[0149] In an alternative embodiment, under the constraint of priority conditions, the target payment channel is usually the first payment channel after sorting by priority. However, in some business scenarios, it can also be selected from the first few payment channels after priority sorting according to requirements such as load balancing as the target payment channel.

[0150] In practical applications, by determining the payment channel that meets the priority conditions as the target payment channel, the efficiency and success rate of the payment process can be effectively improved, and the flexibility of the payment channel selection process can be ensured.

[0151] In step S211, transaction processing is performed on the target transaction order based on the target payment channel.

[0152] In one possible implementation, the transaction execution system can perform transaction processing based on the channel after determining the target payment channel. Specifically, the transaction execution system can send a transaction request to the target payment channel, including detailed information of the target transaction order, such as the transaction amount, payment method, etc. After receiving the transaction request, the payment channel will process the transaction and return the processing result.

[0153] In another possible implementation, the transaction execution system can interact with the target payment channel multiple times to ensure the smooth completion of the transaction. For example, after initially sending a transaction request, the transaction execution system may receive additional verification requests from the payment channel, such as identity verification or payment authorization. In this case, the transaction execution system will perform corresponding verification and authorization operations according to the requirements of the payment channel until the transaction is successfully completed.

[0154] In practical applications, by performing transaction processing on the target transaction order based on the target payment channel, the smooth connection between the selection of the payment channel and the execution of the transaction can be ensured, thereby improving the success rate of the transaction and the payment experience of users. At the same time, the flexible interaction between the transaction execution system and the payment channel can also handle complex payment scenarios and enhance the adaptability of the transaction order processing system.

[0155] Figure 5 is a block diagram of a transaction order processing system shown according to an exemplary embodiment. Referring to Figure 5 , the device may include:

[0156] An acquisition module 501, configured to acquire a target transaction order and a set of payment channels; the set of payment channels includes multiple payment channels;

[0157] A parameter and set determination module 503, configured to determine a set of target screening policies and target transaction parameters carried in the target transaction order; the set of target screening policies refers to the screening policies dynamically configured for the target transaction order;

[0158] The first determination module 505 is configured to screen out a first screening result that matches the target transaction parameters from multiple payment channels; the first screening result includes at least one payment channel;

[0159] The second determination module 507 is configured to screen out a second screening result that matches the target screening policy set from the first screening result;

[0160] The channel determination module 509 is configured to determine the payment channels that meet the priority condition in the second screening result as the target payment channels;

[0161] The transaction module 511 is configured to perform transaction processing on the target transaction order based on the target payment channels.

[0162] In a possible implementation manner, the target transaction parameters include payment product information and payment method information; the first determination module 505 includes:

[0163] The preset channel acquisition unit is configured to, when the preset channel set exists, acquire the preset channel set and determine the preset channel set as the pre-screening result; the preset channel set represents one or more payment channels set by the target resource recipient and adapted to the target transaction order;

[0164] The pre-screening result determination unit is configured to, when the preset channel set does not exist, screen out a pre-screening result that matches the target transaction parameters from multiple payment channels according to the payment product information and the payment method information;

[0165] The first result determination unit is configured to screen out a first screening result that matches the target configuration information from the pre-screening result.

[0166] In a possible implementation manner, the target configuration information includes service class configuration information, transaction class configuration information, verification class configuration information, and query class configuration information; the first result determination unit includes:

[0167] The first screening result determination subunit is configured to screen out a first screening result that matches the service class configuration information, transaction class configuration information, verification class configuration information, and query class configuration information from the pre-screening result.

[0168] In a possible implementation manner, it may further include:

[0169] The preset policy acquisition module is configured to acquire a preset screening policy set; the preset screening policy set represents the screening policies dynamically configured by the target resource recipient for the target transaction order;

[0170] The target policy first determination module is configured to, when the preset screening policy set exists, determine the preset screening policy set as the target screening policy set.

[0171] In a possible implementation, it may further include:

[0172] A to-be-configured policy determination module, configured to obtain a screening policy corresponding to target transaction parameters as a to-be-configured screening policy set when the preset screening policy set does not exist;

[0173] An inspection module, configured to inspect the to-be-configured screening policy set;

[0174] A target policy second determination module, configured to determine the to-be-configured screening policy set as the target screening policy set when the to-be-configured screening policy set meets the target screening conditions; or, when the to-be-configured screening policy set does not meet the target screening conditions, obtain the default screening policy set as the target screening policy set.

[0175] In a possible implementation, the target screening policy set includes a target screening policy and a target sorting policy; the second determination module 507 includes:

[0176] A screening and sorting unit, configured to screen out payment channels that match the target screening policy from the first screening result and perform sorting according to the target sorting policy to obtain a second screening result.

[0177] In a possible implementation, the target screening policy set is composed of one or more target routing conditions; each target routing condition corresponds to a set of target scripts; the second determination module 507 includes:

[0178] An analysis unit, configured to analyze the target screening policy set to obtain one or more target routing conditions;

[0179] A script acquisition unit, configured to acquire the target script corresponding to each target routing condition;

[0180] A script execution unit, configured to execute multiple target scripts, screen and sort from the first screening result to obtain a second screening result.

[0181] In a possible implementation, it may further include:

[0182] An external call and adjustment information acquisition unit, configured to acquire external call information and dynamic adjustment information for multiple target scripts;

[0183] An update unit, configured to update multiple target scripts based on the external call information and the dynamic adjustment information to obtain target updated scripts;

[0184] The script execution unit includes:

[0185] An update script execution unit is used to execute multiple target update scripts, filter and sort them from the first screening result to obtain a second screening result.

[0186] In a possible implementation manner, the external call information includes channel information, transaction information, and memory information; the update unit includes:

[0187] An update subunit is used to update multiple target scripts based on the channel information, transaction information, memory information, and dynamic adjustment information to obtain target update scripts.

[0188] Regarding the system in the above embodiments, the specific manners in which each module performs operations have been described in detail in the embodiments related to the method, and will not be elaborated here.

[0189] Figure 6 is a block diagram of an electronic device for processing transaction orders shown according to an exemplary embodiment. The electronic device may be a terminal, and its internal structure diagram may be as Figure 6 shown. The electronic device includes a processor, a memory, a network interface, a display screen, and an input device connected through a system bus. Among them, the processor of the electronic device is used to provide computing and control capabilities. The memory of the electronic device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the electronic device is used to communicate with an external terminal through a network connection. The computer program, when executed by the processor, is used to implement a method for processing transaction orders. The display screen of the electronic device may be a liquid crystal display screen or an electronic ink display screen. The input device of the electronic device may be a touch layer covered on the display screen, or a button, a trackball, or a touchpad provided on the housing of the electronic device, or an external keyboard, a touchpad, or a mouse, etc.

[0190] Those skilled in the art can understand that Figure 6 the structure shown in

[0191] merely represents a block diagram of some structures related to the solution of the present disclosure, and does not constitute a limitation on the electronic device to which the solution of the present disclosure is applied. The specific electronic device may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0192] In an exemplary embodiment, a computer-readable storage medium is further provided. When the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to execute the transaction order processing method in the embodiments of the present disclosure. The computer-readable storage medium may be a ROM, a random access memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, etc.

[0193] In an exemplary embodiment, a computer program product containing instructions is further provided. When it runs on a computer, the computer is enabled to execute the method for processing a transaction order in the embodiments of the present disclosure.

[0194] Those of ordinary skill in the art can understand that all or part of the processes of implementing the methods in the above embodiments can be completed by instructing relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it may include the processes of the embodiments of the above methods. Among them, any reference to a memory, storage, database, or other medium used in the various embodiments provided by the present application may include non-volatile and / or volatile memories. The non-volatile memory may include a read-only memory (ROM), a programmable ROM (PROM), an electrically programmable ROM (EPROM), an electrically erasable programmable ROM (EEPROM), or a flash memory. The volatile memory may include a random access memory (RAM) or an external cache memory. By way of illustration and not limitation, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0195] After considering the specification and practicing the invention disclosed herein, those skilled in the art will readily conceive of other embodiments of the present disclosure. This application is intended to cover any variations, uses, or adaptations of the present disclosure, which follow the general principles of the present disclosure and include known common knowledge or conventional technical means in the technical field not disclosed by the present disclosure. The specification and embodiments are only to be considered exemplary, and the true scope and spirit of the present disclosure are pointed out by the following claims.

[0196] It should be understood that the present disclosure is not limited to the exact structures described above and shown in the drawings, and various modifications and changes can be made without departing from its scope. The scope of the present disclosure is only limited by the appended claims.

Claims

1. A method for processing a transaction order, characterized in that, The method includes: Obtaining a target transaction order and a set of payment channels; the set of payment channels includes multiple payment channels; Determining a set of target screening strategies and target transaction parameters carried in the target transaction order; the set of target screening strategies refers to the screening strategies dynamically configured for the target transaction order; Screening out a first screening result that matches the target transaction parameters from the multiple payment channels; the first screening result includes at least one payment channel; Parsing the set of target screening strategies to obtain one or more target routing conditions; Obtaining a target script corresponding to each of the target routing conditions; Obtaining external call information and dynamic adjustment information for the multiple target scripts; the external call information refers to information related to the payment environment obtained from an external data source; the external call information includes the real-time status and network load of the payment channels; the dynamic adjustment information includes rules and parameters for updating the priority, response speed, and current load of the payment channels in the target scripts; Updating the multiple target scripts based on the external call information and the dynamic adjustment information to obtain target updated scripts; Executing the multiple target updated scripts, screening and sorting from the first screening result to obtain a second screening result; Determining the payment channels that meet the priority condition in the second screening result as the target payment channels; Performing transaction processing on the target transaction order based on the target payment channels.

2. The method according to claim 1, wherein The target transaction parameters include payment product information and payment method information; the screening out of the first screening result that matches the target transaction parameters from the multiple payment channels includes: When a preset channel set exists, obtaining the preset channel set and determining the preset channel set as the pre-screening result; the preset channel set represents one or more payment channels set by the target resource recipient and adapted to the target transaction order; When the preset channel set does not exist, screening out a pre-screening result that matches the target transaction parameters from the multiple payment channels according to the payment product information and the payment method information; Screening out the first screening result that matches the target configuration information from the pre-screening result.

3. The method according to claim 2, wherein The target configuration information includes service class configuration information, transaction class configuration information, verification class configuration information, and query class configuration information; the screening out of the first screening result that matches the target configuration information from the pre-screening result includes: Screening out the first screening result that matches the service class configuration information, the transaction class configuration information, the verification class configuration information, and the query class configuration information from the pre-screening result.

4. The method according to claim 1, characterized in that, The method further includes: Obtaining a preset set of screening strategies; the preset set of screening strategies represents the screening strategies dynamically configured by the target resource recipient for the target transaction order; When the preset set of screening strategies exists, determining the preset set of screening strategies as the set of target screening strategies.

5. The method according to claim 4, wherein The method further includes: In the case where the preset screening strategy set does not exist, obtain the screening strategy corresponding to the target transaction parameter as the to-be-configured screening strategy set; Verify the to-be-configured screening strategy set; In the case where the to-be-configured screening strategy set meets the target screening conditions, determine the to-be-configured screening strategy set as the target screening strategy set; Or, in the case where the to-be-configured screening strategy set does not meet the target screening conditions, obtain the default screening strategy set as the target screening strategy set.

6. The method according to claim 1, wherein The target screening strategy set includes a target screening strategy and a target sorting strategy; the method further includes: Screen out the payment channels that match the target screening strategy from the first screening result, and sort them according to the target sorting strategy to obtain a second screening result.

7. The method according to claim 1, wherein The external call information includes channel information, transaction information, and memory information; updating the multiple target scripts based on the external call information and the dynamic adjustment information to obtain a target updated script includes: Update the multiple target scripts based on the channel information, the transaction information, the memory information, and the dynamic adjustment information to obtain a target updated script.

8. A trading order processing system, characterized in that, Includes: An acquisition module, configured to acquire a target transaction order and a payment channel set; The payment channel set includes multiple payment channels; A parameter and set determination module, configured to determine a target screening strategy set and the target transaction parameters carried in the target transaction order; The target screening strategy set refers to the screening strategy dynamically configured for the target transaction order; A first determination module, configured to screen out a first screening result that matches the target transaction parameter from the multiple payment channels; The first screening result includes at least one payment channel; A second determination module, configured to screen out a second screening result that matches the target screening strategy set from the first screening result; A channel determination module, configured to determine the payment channels that meet the priority conditions in the second screening result as the target payment channels; A transaction module, configured to perform transaction processing on the target transaction order based on the target payment channels; Wherein, the second determination module includes a parsing unit, configured to parse the target screening strategy set to obtain one or more target routing conditions; a script acquisition unit, configured to acquire the target scripts respectively corresponding to each target routing condition; an external call and adjustment information acquisition unit, configured to acquire external call information and the dynamic adjustment information for the multiple target scripts; the external call information refers to the information related to the payment environment obtained from an external data source; the external call information includes the real-time status and network load of the payment channels; the dynamic adjustment information includes the rules and parameters for updating the priority, response speed, and current load of the payment channels in the target scripts; an update unit, configured to update the multiple target scripts based on the external call information and the dynamic adjustment information to obtain a target updated script; an updated script execution unit, configured to execute the multiple target updated scripts, screen and sort from the first screening result to obtain a second screening result.

9. An electronic device, characterized in that, Includes: A processor; A memory for storing the processor-executable instructions; Wherein, the processor is configured to execute the instructions to implement the transaction order processing method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, When the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to execute the transaction order processing method according to any one of claims 1 to 7.

11. A computer program product, comprising computer instructions, characterized in that, When the computer instructions are executed by a processor, the transaction order processing method according to any one of claims 1 to 7 is implemented.

Images