Payment method, apparatus, device, medium, and program product

Abstract

This application provides a payment method, apparatus, device, medium, and program product that can be applied to the field of artificial intelligence technology. The method includes: acquiring payment characteristics of a target payment task; determining payment channel optimization strategies for multiple payment channels based on the payment characteristics and multiple predefined optimization objectives using a multi-objective optimization model; the payment channel optimization strategies characterize the priority of each payment channel in executing the target payment task under the predefined multiple optimization objectives, and the multi-objective optimization model is trained from historical payment data; acquiring payment channel profiles of multiple payment channels; the payment channel profiles characterize the performance evaluation results of the payment channels; determining a target payment channel from the multiple payment channels based on the payment characteristics, payment channel optimization strategies, and payment channel profiles; generating a payment instruction based on the target payment channel; and the payment instruction is used to instruct the execution of the target payment task.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and more specifically to a payment method, device, equipment, medium, and program product. Background Technology

[0002] In corporate payment operations, the selection of payment channels usually relies on fixed rules or human experience. The payment methods in related technologies are difficult to optimize comprehensively under multiple conflicting objectives such as payment cost, arrival time, and transaction success rate. At the same time, they cannot be dynamically adjusted according to the real-time performance status of payment channels, resulting in rigid payment path selection and an inability to achieve a balance between cost, efficiency, and reliability. Summary of the Invention

[0003] In view of the above problems, embodiments of this application provide a payment method, apparatus, device, medium, and program product.

[0004] According to a first aspect of this application, a payment method is provided, comprising: obtaining payment characteristics of a target payment task; determining payment channel optimization strategies for multiple payment channels based on the payment characteristics and multiple predefined optimization objectives using a multi-objective optimization model; the payment channel optimization strategies characterize the priority of each payment channel in executing the target payment task under the predefined multiple optimization objectives, and the multi-objective optimization model is trained from historical payment data; obtaining payment channel profiles for multiple payment channels; the payment channel profiles characterize the performance evaluation results of the payment channels; determining a target payment channel from the multiple payment channels based on the payment characteristics, payment channel optimization strategies, and payment channel profiles; generating a payment instruction based on the target payment channel; and the payment instruction being used to instruct the execution of the target payment task.

[0005] According to an embodiment of this application, the training steps of the multi-objective optimization model include: acquiring a historical payment data set; the historical payment data set includes multiple historical payment task instances, each historical payment task instance being associated with payment characteristics at the time of payment, the payment channel used, and the payment result representing the payment effect; using the historical payment data set as training samples, training the initial model through a multi-objective optimization algorithm to obtain a trained multi-objective optimization model.

[0006] According to embodiments of this application, the method further includes: obtaining the business scenario and / or associated customer needs to which the target payment task belongs; selecting at least two optimization objectives from a set of optimization objectives to constitute a predefined plurality of optimization objectives based on the business scenario and / or customer needs; the set of optimization objectives includes at least optimizing transaction costs, optimizing transaction time, and optimizing transaction security; and configuring the weight of each selected optimization objective in the multi-objective optimization model for decision-making.

[0007] According to an embodiment of this application, obtaining payment channel profiles for multiple payment channels includes: obtaining a historical payment data set; the historical payment data set includes multiple historical payment task instances, each historical payment task instance being associated with the payment channel used during payment and a payment result characterizing the payment effect; extracting channel features related to the performance of each payment channel from the historical payment data set; the channel features include at least one of the following: payment success rate, payment response time, and payment cost; determining the evaluation result of each payment channel on at least one performance dimension based on the channel features; the performance dimensions include stability dimension, efficiency dimension, and cost dimension; and generating a payment channel profile for each payment channel based on the evaluation results.

[0008] According to an embodiment of this application, after generating a payment instruction based on a target payment channel, the method further includes: using a streaming rule engine to monitor and match the payment instruction in real time based on preset risk control rules to obtain a first risk assessment result; using a graph neural network model to identify risks in the payment entity relationship network associated with the payment instruction to obtain a second risk assessment result; generating a risk control decision for the payment instruction based on the first and second risk assessment results; the risk control decision includes allowing or blocking; and executing or blocking the payment instruction based on the risk control decision.

[0009] According to embodiments of this application, obtaining payment features of a target payment task includes: obtaining a billing file for the target payment task; performing image preprocessing on the billing file; the image preprocessing steps include at least denoising, binarization, and tilt correction; extracting text information from the preprocessed billing file using optical character recognition technology; performing semantic understanding on the extracted text information using natural language processing technology to identify and extract key fields; verifying and correcting the extracted key fields using a knowledge graph and preset verification rules to obtain verified and corrected data; and converting the verified and corrected data into a structured format to obtain the payment features of the target payment task.

[0010] According to embodiments of this application, key fields extracted are validated and corrected using a knowledge graph and preset validation rules to obtain validated and corrected data. This includes: validating the extracted key fields using a knowledge graph and preset validation rules to obtain validation results; the preset validation rules include format rules for validating field formats and content rules for validating logical relationships between fields; and correcting key fields that do not conform to the preset validation rules based on the validation results to obtain validated and corrected data.

[0011] According to a second aspect of this application, a payment device is provided, comprising: a first acquisition module for acquiring payment characteristics of a target payment task; a first determination module for determining payment channel optimization strategies for multiple payment channels based on the payment characteristics and multiple predefined optimization objectives using a multi-objective optimization model; the payment channel optimization strategies characterize the priority of each payment channel in executing the target payment task under the predefined multiple optimization objectives, and the multi-objective optimization model is trained from historical payment data; a second acquisition module for acquiring payment channel profiles of the multiple payment channels; the payment channel profiles characterize the performance evaluation results of the payment channels; a second determination module for determining a target payment channel from the multiple payment channels based on the payment characteristics, payment channel optimization strategies, and payment channel profiles; and a generation module for generating a payment instruction based on the target payment channel; the payment instruction is used to instruct the execution of the target payment task.

[0012] According to a third aspect of this application, an electronic device is provided, comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method described above.

[0013] According to a fourth aspect of this application, a computer-readable storage medium is also provided, on which a computer program or instructions are stored, wherein the computer program or instructions, when executed by a processor, implement the steps of the above-described method.

[0014] According to a fifth aspect of this application, a computer program product is also provided, including a computer program or instructions that, when executed by a processor, implement the steps of the above-described method. Attached Figure Description

[0015] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0016] Figure 1 The illustrations depict application scenarios of payment methods, apparatuses, devices, media, and program products according to embodiments of this application.

[0017] Figure 2 A flowchart illustrating a payment method according to an embodiment of this application is shown schematically;

[0018] Figure 3 A schematic diagram illustrating the principle of a payment method according to an embodiment of this application is provided.

[0019] Figure 4 A schematic diagram illustrating a payment method according to another embodiment of this application is shown.

[0020] Figure 5A schematic block diagram of a payment device according to an embodiment of this application is shown.

[0021] Figure 6 A block diagram schematically illustrates an electronic device suitable for implementing a payment method according to an embodiment of this application. Detailed Implementation

[0022] The embodiments of this application will now be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of this application. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of this application for ease of explanation. However, it will be apparent that one or more embodiments may be implemented without these specific details. Furthermore, descriptions of well-known structures and technologies are omitted in the following description to avoid unnecessarily obscuring the concepts of this application.

[0023] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The terms “comprising,” “including,” etc., as used herein indicate the presence of features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0024] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0025] When using expressions such as "at least one of A, B and C", they should generally be interpreted in accordance with the meaning that is commonly understood by those skilled in the art (e.g., "a system having at least one of A, B and C" should include, but is not limited to, a system having A alone, a system having B alone, a system having C alone, a system having A and B, a system having A and C, a system having B and C, and / or a system having A, B and C, etc.).

[0026] As used in this paper, the term "model" refers to a model that learns the relationship between inputs and outputs from training data, enabling it to generate corresponding outputs for a given input after training. Model generation can be based on machine learning techniques. Deep learning is a machine learning algorithm that processes inputs and provides corresponding outputs using multiple layers of processing units. A neural network model is an example of a deep learning-based model. In this paper, "model" may also be referred to as a "machine learning model," "learning model," "machine learning network," or "learning network," and these terms are used interchangeably.

[0027] In the technical solution of this application, the user information (including but not limited to user personal information, user image information, user device information, such as location information) and data (including but not limited to data used for analysis, stored data, and displayed data) involved 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 relevant laws, regulations, and standards, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse.

[0028] In scenarios where personal information is used for automated decision-making, the methods, devices, and systems provided in this application all provide users with corresponding operation entry points for users to choose to agree to or reject the automated decision results; if the user chooses to reject, the process enters the expert decision-making process.

[0029] Figure 1 The illustrations depict application scenarios of payment methods, apparatuses, devices, media, and program products according to embodiments of this application.

[0030] like Figure 1 As shown, application scenario 100 according to an embodiment of this application may include a first terminal device 101, a second terminal device 102, a database 103, a network 104, and a server 105. The network 104 serves as a medium for providing a communication link between the first terminal device 101, the second terminal device 102, the database 103, and the server 105. The network 104 may include various connection types, such as wired or wireless communication links or fiber optic cables. For example, a user can use the first terminal device 101 and the second terminal device 102 to interact with the server 105 and / or the database 103 through the network 104 to receive or send information, etc.

[0031] The first terminal device 101 and the second terminal device 102 can be electronic devices such as smartphones, wearable devices, personal computers, intelligent voice interaction devices, smart home appliances, intelligent vehicles, in-vehicle terminals, aircraft, unmanned vending terminals, and extended reality devices. Extended reality devices can include virtual reality devices, augmented reality devices, and mixed reality devices. A client application for the target application can be installed and run on the terminal device. This target application can include, but is not limited to, financial transaction applications, payment applications, shopping applications, web browser applications, search applications, instant messaging tools, email clients, and social media platform software (these are just examples). Furthermore, this application embodiment does not limit the form of the target application, including but not limited to applications, mini-programs, etc., installed on the terminal device, and can also be in web page form.

[0032] Server 105 can be a server providing various services, such as a backend management server supporting websites browsed by users using the first terminal device 101 and the second terminal device 102 (this is just an example). The backend management server can analyze and process received user requests and other data, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal devices. The server can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services such as cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks, and big data. The server can be a backend server for the aforementioned target application, used to provide backend services to the clients of the target application.

[0033] Database 103 is a professional storage system for storing and managing data. It can store various types of data related to the target application, such as user account information, business transaction records, and content resource data. It supports structured, semi-structured, or unstructured data storage and has management capabilities such as adding, deleting, modifying, querying, backing up, and restoring data. In this application scenario, database 103 can be connected to server 105 via a communication link. Server 104 can retrieve the required data from database 103 for processing based on requests from the first terminal device 101 and the second terminal device 102. It can also synchronously store new data generated by the operations of the first terminal device 101 and the second terminal device 102 into database 103, thereby achieving data persistence and efficient retrieval.

[0034] It should be noted that the payment method provided in this application embodiment can generally be executed by server 105 and / or terminal devices 101-102. Accordingly, the payment method apparatus provided in this application embodiment can generally be set in server 105 and / or terminal devices 101-102.

[0035] It should be understood that Figure 1 The number of terminal devices, networks, databases, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, databases, and servers can be included.

[0036] Figure 2 A flowchart illustrating a payment method according to an embodiment of this application is shown schematically. Figure 2 As shown, the payment method 200 according to the embodiments of this application may include steps S210 to S250.

[0037] In step S210, the payment characteristics of the target payment task are obtained.

[0038] In the embodiments of this application, the target payment task refers to a specific payment transaction to be processed, such as paying a supplier for goods, paying taxes, or distributing wages. Payment features refer to a set of key information describing the attributes of the target payment task itself; these features are the basic inputs for subsequent intelligent decision-making.

[0039] For example, payment characteristics may include, but are not limited to: payment amount (e.g., 980 yuan), payment type (e.g., "supplier payment" bank transfer), payment time requirements (e.g., required to arrive today), and payee information (e.g., payee account, bank of account).

[0040] In the embodiments of this application, the payment characteristics of the target payment task are obtained. The system extracts the core data, i.e., the payment characteristics, that characterizes the current payment task from the business system or related interfaces.

[0041] In step S220, a multi-objective optimization model is used to determine the payment channel optimization strategies for multiple payment channels based on payment characteristics and multiple predefined optimization objectives. The payment channel optimization strategy represents the priority of each payment channel in executing the target payment task under the multiple predefined optimization objectives. The multi-objective optimization model is trained from historical payment data.

[0042] In the embodiments of this application, a payment channel refers to a specific financial service interface or path on which the payment operation is completed, such as a bank's real-time transfer system, a third-party payment platform's enterprise payment interface, or a large or small value payment system.

[0043] In the embodiments of this application, the multi-objective optimization model can be a machine learning model trained from historical payment data. The core feature of the multi-objective optimization model is that it can consider multiple optimization objectives simultaneously for comprehensive decision-making. The predefined multiple optimization objectives refer to the business indicators that are set before the model makes decisions and that are expected to be achieved. For example, the predefined multiple optimization objectives may include optimizing transaction costs (pursuing the lowest handling fees), optimizing transaction time (pursuing the fastest arrival speed), optimizing transaction security (pursuing the highest payment success rate), etc.

[0044] In the embodiments of this application, the payment channel optimization strategy refers to the evaluation conclusion calculated by the model for each payment channel currently available in the system based on the current payment characteristics and predetermined optimization objectives. The payment channel optimization strategy can characterize the priority of different payment channels for executing the current target payment task under various optimization objectives. It should be noted that the payment channel optimization strategy is not a final instruction; rather, it is a quantitative suggestion output by the multi-objective optimization model.

[0045] In the embodiments of this application, a multi-objective optimization model is used to determine payment channel optimization strategies for multiple payment channels based on payment characteristics and multiple predefined optimization objectives. The multi-objective optimization model receives specific payment characteristics, performs calculations under the constraints of multiple pre-set business objectives, and outputs a payment channel optimization strategy that assesses the performance of each available payment channel across different objective dimensions, providing a theoretical basis for subsequent selection.

[0046] For example, for a payment of 500 yuan that needs to be received within 2 hours, the multi-objective optimization model can, based on historical learning, calculate the following according to multiple predefined optimization objectives (such as "cost" and "time" objectives): Channel A (a bank's ordinary transfer) has the highest priority in the "cost" objective and a medium priority in the "time" objective; Channel B (a payment company's real-time channel) has the highest priority in the "time" objective and a low priority in the "cost" objective.

[0047] In step S230, payment channel profiles of multiple payment channels are obtained; the payment channel profiles represent the performance evaluation results of the payment channels.

[0048] In the embodiments of this application, a payment channel profile refers to a comprehensive performance evaluation result obtained by calculating and evaluating the operating status and performance of a payment channel based on historical and real-time data. The payment channel profile is a dynamic description of the channel's health status.

[0049] In the embodiments of this application, payment channel profiles of multiple payment channels are obtained; each payment channel profile represents the performance evaluation results of the payment channel. The latest status of all relevant payment channels within the system is obtained, and the payment channel profile is independent of the current specific payment task, reflecting the real-time and objective performance indicators of the payment channel itself.

[0050] For example, payment channel profiling can assess a channel's stability (e.g., a recent payment success rate of 99.5%), efficiency (e.g., an average arrival time of 30 minutes), and cost (e.g., transaction fees for specific amount ranges). For instance, the profile of channel X might show a high current success rate but with slight delays, while the profile of channel Y might show low costs but only availability during weekday business hours.

[0051] In step S240, the target payment channel is determined from multiple payment channels based on payment characteristics, payment channel optimization strategies, and payment channel profiles.

[0052] In the embodiments of this application, the decision-making system integrates three types of information: payment characteristics representing task requirements, payment channel optimization strategies representing theoretically optimal suggestions, and payment channel profiles representing the real-time status of the channels. Based on this, weighted, game-like, and calibrated calculations are performed to select the target payment channel from all available payment channels that best balances or satisfies various business requirements (cost, time, security, etc.) under the current specific conditions.

[0053] For example, even if the model suggests that channel B is optimal in terms of "time", if the payment channel profile of channel B shows a sharp drop in the current success rate, while the profile of channel A is stable and can meet the 2-hour arrival requirement, the decision system may ultimately select channel A as the target payment channel to achieve higher reliability and lower cost while meeting the timeliness requirement.

[0054] In step S250, a payment instruction is generated based on the target payment channel; the payment instruction is used to instruct the execution of the target payment task.

[0055] In the embodiments of this application, a payment instruction refers to an operation command containing specific execution information, used to drive the payment system to complete a transaction.

[0056] In the embodiments of this application, a payment instruction is generated based on the target payment channel. According to the determined target payment channel and combined with necessary information from the payment characteristics (such as amount and payee account), a standardized and fully parameterized executable payment instruction is generated. The payment instruction is used to instruct the payment execution system to call the corresponding target payment channel to complete the target payment task.

[0057] This application's embodiments utilize a multi-objective optimization model trained on historical data to generate payment channel optimization strategies. These strategies, combined with a payment channel profile reflecting real-time performance, jointly determine the target payment channel and generate corresponding payment instructions. This method overcomes the shortcomings of traditional payment channel selection methods, which rely on fixed rules and cannot dynamically balance multiple objectives such as cost, timeliness, and security. It accurately selects the currently optimal payment channel for each payment task, effectively improving payment efficiency and reducing costs while ensuring success and security, thus achieving intelligent and optimized payment channel selection.

[0058] In some embodiments, the training steps of the multi-objective optimization model include: acquiring a historical payment data set; the historical payment data set includes multiple historical payment task instances, each of which is associated with payment characteristics at the time of payment, the payment channel used, and the payment result representing the payment effect; using the historical payment data set as training samples, training the initial model through a multi-objective optimization algorithm to obtain a trained multi-objective optimization model.

[0059] In the embodiments of this application, the historical payment dataset is a dataset used for model training, and it consists of a large number of previously completed payment records. A historical payment task instance is a data record in the historical payment dataset, corresponding to a completed historical payment task.

[0060] In the embodiments of this application, each historical payment task instance is associated with payment characteristics at the time of payment, the payment channel used, and a payment result characterizing the payment effect. Payment characteristics at the time of payment refer to the attributes possessed by the historical payment task when it was initiated, synonymous with the payment characteristics in the aforementioned embodiments, such as historical payment amount, business type, expected arrival time, etc. The payment channel used refers to the actual payment channel used in the historical payment task, such as the specific bank or third-party payment interface used. The payment result characterizing the payment effect refers to the final actual effect information of the payment, used to evaluate the merits of the payment channel used. The payment result typically includes whether the transaction was successful, the actual transaction fees incurred, and the actual arrival time.

[0061] In embodiments of this application, a set of historical payment data is obtained. Structured training samples are collected, and each sample (instance) must simultaneously contain "input" (payment features), "action taken at the time" (payment channel), and "feedback from the action" (payment result).

[0062] For example, a historical payment task instance can be associated with: payment characteristics {amount: 100 yuan, type: social security payment, requirement: within this month}, payment channel "UnionPay payment channel A", and payment result {result: successful, handling fee: 5 yuan, arrival time: 2 business days}.

[0063] In the embodiments of this application, multi-objective optimization algorithms are a type of method in the field of machine learning, used to solve problems with multiple optimization objectives. In this embodiment, the objective of the multi-objective optimization algorithm is to balance multiple objectives such as cost, time, and security during training.

[0064] In the embodiments of this application, the initial model refers to the model structure that has not been assigned values ​​before training begins. The trained multi-objective optimization model refers to a model that has acquired capabilities after learning the patterns of historical data through algorithms. When new payment features are input, the trained multi-objective optimization model can mimic the historical optimal decision-making pattern, evaluate and output the priority strategy for each payment channel.

[0065] In the embodiments of this application, a historical payment dataset is used as training samples, and an initial model is trained using a multi-objective optimization algorithm to obtain a trained multi-objective optimization model. The prepared historical data is then input into the multi-objective optimization algorithm, which continuously adjusts the internal parameters of the initial model to minimize the gap between its predictions and historical optimal decisions. After training, the model possesses the ability to map payment characteristics to payment channel evaluation.

[0066] Through the embodiments of this application, by using structured historical payment data and employing multi-objective optimization algorithms to enable the model to learn the complex relationship between payment characteristics, channel selection and payment results, it can be ensured that the trained model can intelligently evaluate the advantages and disadvantages of different payment channels in new task scenarios based on historical experience.

[0067] In some embodiments, the method further includes: obtaining the business scenario and / or associated customer needs to which the target payment task belongs; selecting at least two optimization objectives from a set of optimization objectives to form a predefined plurality of optimization objectives based on the business scenario and / or customer needs; the set of optimization objectives includes at least optimizing transaction costs, optimizing transaction time, and optimizing transaction security; and configuring the weight of each selected optimization objective in the decision-making process of the multi-objective optimization model.

[0068] In the embodiments of this application, the business scenario refers to the specific business background or type in which the target payment task occurs. For example, paying social security and housing provident fund, paying suppliers, and distributing employee salaries. Customer needs refer to the requirements that the customer or enterprise initiating the payment task is particularly concerned about or raises, which may go beyond basic payment functions, such as "cost minimization priority," "the arrival time must be guaranteed to be within today," and "the highest security requirements."

[0069] In the embodiments of this application, the business scenario and / or associated customer needs of the target payment task are obtained. The system identifies the specific business environment of the current payment and the customer's specific preferences through interfaces, configuration, or parsing task information, laying the foundation for subsequent selection of targeted optimization targets.

[0070] For example, a business scenario might involve a payment being identified as "employee salary payment." The client's requirement might be that the company explicitly requires all employees to receive their salaries on time on payday (timeliness requirement), while also being sensitive to transaction costs (cost requirement).

[0071] In the embodiments of this application, the set of optimization objectives is a pool of selectable optimization dimensions preset by the system. The set of optimization objectives includes at least optimizing transaction costs (aiming for the lowest possible costs such as payment fees), optimizing transaction time (aiming for the fastest payment arrival speed), and optimizing transaction security (aiming for the highest payment success rate and the lowest risk).

[0072] In the embodiments of this application, the predefined multiple optimization objectives are a combination of indicators specifically selected for the current target payment task, which are intended to be comprehensively considered by the multi-objective optimization model when making decisions.

[0073] For example, in the scenario of "paying employee salaries", the system may select two objectives from the set: optimizing transaction time and optimizing transaction cost, based on the requirements of "timely arrival" and "cost control", to form "multiple predefined optimization objectives" for the current task.

[0074] In the embodiments of this application, the weight represents the importance of each selected optimization objective in the final decision. It is a quantitative value; the higher the weight, the greater the bias of the model in the trade-offs for that objective.

[0075] In the embodiments of this application, a weight is assigned to each selected optimization objective when making decisions in a multi-objective optimization model. By assigning appropriate weights to different objectives, the value orientation of the multi-objective optimization model in calculating payment channel optimization strategies can be precisely controlled, enabling the final decision to reflect the differentiated emphasis on performance requirements of each dimension under different scenarios.

[0076] For example, given that "optimize transaction time" and "optimize transaction cost" have been selected, the system can assign a higher weight (e.g., 0.7) to "optimize transaction time" and a lower weight (e.g., 0.3) to "optimize transaction cost" to reflect that "on-time arrival" has a higher priority than "cost saving".

[0077] Through the embodiments of this application, by dynamically selecting and configuring the type and weight of optimization targets according to the specific business scenario and customer needs of the payment task, the optimization decision of the payment path can flexibly adapt to diverse actual business requirements, thereby significantly enhancing the practicality, adaptability and personalized service level of the intelligent payment system.

[0078] In some embodiments, obtaining payment channel profiles for multiple payment channels includes: obtaining a historical payment data set; the historical payment data set includes multiple historical payment task instances, each historical payment task instance being associated with the payment channel used during payment and a payment result characterizing the payment effect; extracting channel features related to the performance of each payment channel from the historical payment data set; the channel features include at least one of the following: payment success rate, payment response time, and payment cost; determining the evaluation result of each payment channel on at least one performance dimension based on the channel features; the performance dimensions include stability dimension, efficiency dimension, and cost dimension; and generating a payment channel profile for each payment channel based on the evaluation results.

[0079] In the embodiments of this application, the historical payment dataset is the source data used to calculate the channel profile, and consists of past payment records. A historical payment task instance is a single data point in the historical payment dataset, representing a completed payment. The payment channel used during payment refers to the specific path actually used for that payment (such as a bank's interface). The payment result, characterizing the payment effect, refers to the actual effect information after the payment is executed, which may include whether the payment was successful, the actual handling fee, and the actual arrival time of funds.

[0080] For example, a historical payment task instance might be associated with: the payment channel is "the real-time channel of payment platform X", and the payment result is {success, handling fee of 10 yuan, arrival time of 5 minutes}.

[0081] In the embodiments of this application, channel characteristics are metrics derived from historical data and used to quantitatively measure the performance of a payment channel. Channel characteristics include at least one of the following: payment success rate, payment response time, and payment cost. Payment success rate refers to the percentage of successful transactions in a channel's history. Payment response time refers to the average time elapsed from initiating a payment to receiving the final result. Payment cost refers to the average fee or fee rule incurred when using the channel for payment.

[0082] For example, for "the real-time channel of payment platform X", based on its recent 1,000 historical instances, the channel characteristics can be extracted: payment success rate = 99.5%, average payment response time = 120 seconds, and average payment cost = 0.1% of the transaction amount.

[0083] In the embodiments of this application, the performance dimension is a macro-level perspective for evaluating the performance of a payment channel. The performance dimension includes stability, efficiency, and cost. The stability dimension can assess the reliability of the channel based on characteristics such as "payment success rate." The efficiency dimension can assess the speed of the channel based on characteristics such as "payment response time." The cost dimension can assess the economic efficiency of the channel based on characteristics such as "payment cost."

[0084] In the embodiments of this application, the evaluation results of each payment channel on at least one performance dimension are determined based on channel characteristics. The evaluation result refers to the conclusive score or grade obtained after further analysis or standardization of the channel characteristics on each selected performance dimension. By mapping the extracted channel characteristics to higher-level, business-meaning performance dimensions and forming horizontally comparable evaluation conclusions, structured content can be provided for channel profiling.

[0085] For example, the evaluation results are determined as follows: Grade A in stability (success rate > 99%) and Grade B in efficiency (average response time 2 minutes).

[0086] In the embodiments of this application, the performance dimensions include stability, efficiency, and cost. Based on the evaluation results, a payment channel profile is generated for each payment channel. The evaluation results of the payment channel on each performance dimension are integrated and encapsulated to form a standardized evaluation report or data object on the overall performance of the channel, i.e., a payment channel profile. The payment channel profile can intuitively reflect the historical performance and current capability assessment of the channel.

[0087] Through the embodiments of this application, historical payment data is systematically processed to extract key performance characteristics and generate quantitative channel evaluation results across multiple dimensions, thereby constructing a dynamic and objective payment channel profile. The method of this embodiment provides real-time and accurate channel performance data support for intelligent payment decision-making.

[0088] In some embodiments, after generating a payment instruction based on a target payment channel, the method further includes: using a streaming rule engine to perform real-time monitoring and rule matching on the payment instruction based on preset risk control rules to obtain a first risk assessment result; using a graph neural network model to identify risks in the payment entity relationship network associated with the payment instruction to obtain a second risk assessment result; generating a risk control decision for the payment instruction based on the first and second risk assessment results; the risk control decision includes allowing or blocking; and executing or blocking the payment instruction based on the risk control decision.

[0089] In the embodiments of this application, a streaming rule engine is a software system for real-time processing of unbounded data streams. In payment scenarios, data such as payment instructions and transaction logs are continuously generated like flowing water, and the streaming rule engine can judge each piece of data (payment instruction) that flows through in real time. The streaming rule engine can intercept all transactions that meet known risk characteristics first, handling simple and clear threats with extremely high efficiency.

[0090] In the embodiments of this application, preset risk control rules refer to a series of explicit risk judgment conditions predefined by the system. For example, preset risk control rules may include "a single payment amount exceeding 50 yuan requires secondary authorization", "more than 10 transactions initiated by the same payment account within 1 hour trigger an alert", and "the payee's account is marked as suspicious if it is not in the company's whitelist".

[0091] In the embodiments of this application, a streaming rule engine is used to monitor and match payment instructions in real time based on preset risk control rules to obtain a first risk assessment result. The first risk assessment result is a judgment conclusion generated by the streaming rule engine after applying the rules, which is usually whether one or more risk rules are triggered or not.

[0092] For example, when a payment instruction (such as: {Payer: Company A, Payee: Account X, Amount: 60 yuan}) flows through the engine, the engine matches it against all preset rules in real time. In this case, because the "single transaction exceeding 50 yuan" rule is triggered, the first risk assessment result may be marked as "high risk - triggering large amount rule".

[0093] In the embodiments of this application, the graph neural network model is a deep learning model specifically designed for processing graph-structured data. In a graph structure, entities are represented as "nodes," and the relationships between entities are represented as "edges." The graph neural network model can perform relational network analysis on transactions to uncover hidden complex risk patterns. The payment entity relationship network refers to a complex network consisting of various entities involved in the payment instruction (such as payment accounts, receiving accounts, enterprises, individuals, devices, etc.) as "nodes," and relationships such as historical transactions, ownership, and associations between entities as "edges." The second risk assessment result refers to the risk probability or score output by the graph neural network model after analyzing the payment instruction embedded in the aforementioned relationship network.

[0094] In the embodiments of this application, a graph neural network model is used to identify risks in the payment entity relationship network associated with the payment instruction, resulting in a second risk assessment result. For example, the receiving account X of the current payment instruction may have indirect transaction relationships with multiple accounts that have been previously marked as suspicious, or belong to a newly registered cluster that has hidden connections with known suspicious groups. The graph neural network model analyzes the local relationship network in which the instruction is located and identifies such abnormal association patterns. The second risk assessment result may output as "High Risk - Associated Suspicious Network".

[0095] In the embodiments of this application, risk control decision refers to the final handling judgment made on the payment instruction after comprehensively considering two risk assessments. A risk control decision for the payment instruction is generated based on the results of the first and second risk assessments. The system performs a fusion judgment based on the first and second risk assessment results (e.g., one high risk, one low risk; or both high risk), according to a predetermined decision logic (e.g., "block if either result is high risk" or "block if weighted score exceeds a threshold"), to generate a final, clear "allow" or "block" instruction.

[0096] In the embodiments of this application, payment instructions are executed or blocked based on risk control decisions. If the risk control decision is "allow," the payment instruction is sent to the payment channel execution cluster to complete the payment; if the risk control decision is "block," the subsequent process of the payment instruction is terminated, and the reason for the block can be recorded.

[0097] Through the embodiments of this application, by introducing a dual real-time risk control system combining a streaming rule engine and a graph neural network model before payment execution, the system achieves simultaneous identification and interception of known rule risks and hidden associated risks, constructs a proactive and precise payment security defense line, and significantly improves the security and reliability of the transaction process.

[0098] In some embodiments, obtaining the payment characteristics of a target payment task includes: obtaining a billing file for the target payment task; performing image preprocessing on the billing file; the image preprocessing steps include at least denoising, binarization, and tilt correction; extracting text information from the preprocessed billing file using optical character recognition technology; performing semantic understanding on the extracted text information using natural language processing technology to identify and extract key fields; verifying and correcting the extracted key fields using a knowledge graph and preset verification rules to obtain verified and corrected data; and converting the verified and corrected data into a structured format to obtain the payment characteristics of the target payment task.

[0099] In embodiments of this application, a billing document refers to an original electronic document containing information about a payment task to be processed. The billing document may take the form of a Portable Document Format (PDF) file or a scanned image. For example, a billing document may be a PDF file of a supplier invoice generated by a scanner, or a photo of a payslip taken with a mobile phone.

[0100] In the embodiments of this application, the billing file for the target payment task is obtained. The user-submitted raw, unstructured document containing payment instruction information is received as the data source for all subsequent automated processing.

[0101] In the embodiments of this application, image preprocessing refers to optimization operations performed on the image to improve the accuracy of subsequent optical character recognition. The image preprocessing steps include at least denoising, binarization, and tilt correction. Denoising is used to eliminate interference information such as specks and dirt in the image. Binarization converts a color or grayscale image into a black and white image to highlight the contrast between the text and the background. Tilt correction automatically detects and corrects the tilt angle of the text in the image to make it horizontal.

[0102] For example, for a scanned invoice that is slightly tilted and has ink stains, the preprocessing steps will first remove the stains (denoising), then convert the image to black and white (binarization), and finally rotate the image to restore the text lines to horizontal (tilt correction).

[0103] In the embodiments of this application, optical character recognition (OCR) technology is used to extract text information from a preprocessed billing document. OCR technology is a technique for converting text in an image into computer-encoded text. This step achieves the conversion from image to text. The preprocessed, clear image is processed using OCR technology to identify the text regions and output as the original string sequence.

[0104] In the embodiments of this application, natural language processing (NLP) technology is used to perform semantic understanding on the extracted text information in order to identify and extract key fields. NLP technology enables computers to understand, interpret, and manipulate human language. This step achieves an initial transformation from unstructured text to structured data. Identifying and extracting key fields through semantic understanding provides preliminary, business-meaningful data units for subsequent processing.

[0105] For example, in the text "Total amount: 500 yuan, Account number: 123456" extracted by optical character recognition technology, natural language processing technology can understand the semantics of "total amount" and "account number" and thus extract the key fields: amount: 500; account number: 123456.

[0106] In the embodiments of this application, a knowledge graph is a semantic network containing entities, attributes, and their relationships, used to store domain knowledge. Preset verification rules refer to pre-defined logical conditions used to check data compliance.

[0107] In the embodiments of this application, a knowledge graph and preset verification rules are used to verify and correct the extracted key fields, resulting in verified and corrected data. For example, the knowledge graph may store standard bank account number encoding rules. Combining the preset rule that "account length should be 19 digits", the system can verify that the extracted account number is only 18 digits and automatically correct it according to the padding rules in the knowledge graph.

[0108] In the embodiments of this application, the verified and corrected data is converted into a structured format to obtain the payment characteristics of the target payment task. The verified and corrected, accurate key field data is encapsulated and organized according to the unified data model defined by the system, and finally output as standard, machine-readable payment characteristics.

[0109] Through the embodiments of this application, unstructured billing documents are efficiently and accurately converted into high-quality payment feature data through automated image processing, text recognition, semantic understanding, and intelligent verification and correction processes. This greatly reduces manual data entry and verification work, thereby improving the processing efficiency and data accuracy of the entire intelligent payment system.

[0110] In some embodiments, the extracted key fields are validated and corrected using a knowledge graph and preset validation rules to obtain validated and corrected data. This includes: validating the extracted key fields using a knowledge graph and preset validation rules to obtain validation results; the preset validation rules include format rules for validating field formats and content rules for validating logical relationships between fields; and correcting key fields that do not conform to the preset validation rules based on the validation results to obtain validated and corrected data.

[0111] In the embodiments of this application, preset verification rules refer to a set of logical conditions predefined by the system for judging data compliance. Preset verification rules include format rules for verifying field formats and content rules for verifying the logical relationships between fields. Format rules are used to verify whether the format of a single key field conforms to specifications. For example, verifying the number of digits in a bank account number, the format of a date string (YYYY-MM-DD), and the numerical format of an amount. Content rules are used to verify whether the logical relationships or business meanings between multiple key fields are reasonable. For example, verifying whether the "payment amount" is not greater than the "account available balance," and verifying whether the "payee name" and the "payee account" have matching bank names.

[0112] In the embodiments of this application, the verification result refers to the judgment conclusion on the compliance of each key field or field combination after applying the knowledge graph and preset verification rules. It is usually marked as "compliant" or "non-compliant" and the specific reason for non-compliance.

[0113] In the embodiments of this application, knowledge graphs and preset verification rules are used to verify the extracted key fields and obtain verification results. By simultaneously applying knowledge graphs (which provide semantic associations) and preset format and content rules (which provide specific judgment logic), a comprehensive and multi-level compliance scan is performed on the initially extracted key fields, and detailed verification results are generated, providing a basis for accurate correction.

[0114] For example, consider the extracted payee account: 12345678; bank: XX Bank. Format validation: Applying the format rule that "bank account number length should be 19 digits," the account number is only 8 digits long and is marked as "format mismatch." Content validation: The knowledge graph records that the first 6 digits of a standard bank account number belong to a specific range. Validation is performed using the content rule that "account prefix must match the bank's standard," or by combining the "transfer amount" and "payer account type" fields to determine if the corporate transfer limit has been exceeded.

[0115] In the embodiments of this application, based on the verification results, key fields that do not conform to preset verification rules are corrected to obtain verified and corrected data. The system locates the specific non-compliant fields and their causes based on the verification results generated in the previous step, and initiates the correction logic. Correction can be based on correction strategies in a knowledge graph or rule base (such as intelligent padding for accounts with insufficient digits) or reasoning about related fields. After correction, all key fields conform to preset specifications, forming high-quality "verified and corrected data".

[0116] Figure 3 A schematic diagram illustrating the principle of a payment method according to an embodiment of this application is shown.

[0117] like Figure 3 As shown, the transaction rules are the preset verification rules in this embodiment. The transaction rules include field rules, which correspond to the format rules in this embodiment. The format rules are used to verify whether the format of a single key field conforms to the predefined specifications. Figure 3 The “Contains” connector indicates that transaction rules can include field rules. The “Example” connector points out that “Account Rules” and “Date Rules” are two typical examples of field rules.

[0118] In the embodiments of this application, the account rules are format rules for fields such as "receiving account" or "paying account". The "19-22 characters" constraint stipulates that the length of the account string must be between 19 and 22 characters. This is the most basic format verification. The "checksum algorithm" is a more advanced format and validity verification method that specifies that the account must conform to specific encoding rules, and the system can verify the legitimacy of the account itself through calculation.

[0119] In the embodiments of this application, the date rules are formatting rules for date fields such as "payment date" and "due date". "YYYY-MM-dd" and "YYYY / MM / DD" specify that date strings must conform to one of these two standard formats. This ensures the standardization and parsability of date data and avoids ambiguous formats such as "2024.5.1" and "5 / 1 / 2024".

[0120] In the embodiments of this application, Figure 3 This fully demonstrates part of the underlying logic for the verification step using knowledge graphs and preset verification rules. After the system extracts key fields such as "receiving account" and "payment date," it will call [the appropriate function] based on the field type. Figure 3The system validates the corresponding "field rules" (such as account number rules and date rules) defined in the knowledge graph. For "account number," the system checks if its length is between 19 and 22 characters and may verify its validity using a checksum algorithm. For "date," the system checks if its format conforms to "YYYY-MM-dd" or "YYYY / MM / DD." These all fall under the scope of format rule validation. The validation result indicates whether the field "conforms" or "does not conform" to the rule. For example, an 18-digit account number or an incorrectly formatted date will be marked as not conforming to the "format rule." Based on this validation result, the system can trigger automatic correction logic. For example, for an incorrectly formatted date, the system may attempt to convert it to a standard format; for an account number lacking a checksum, it may provide a prompt or reject the application based on the bank coding rules in the knowledge graph.

[0121] In the embodiments of this application, Figure 3 It is a specific instance of the preset verification rules (especially the format rules section), revealing how the verification rules are designed as specific, executable constraints in the actual system to ensure the accuracy and standardization of the extracted payment feature data in terms of format.

[0122] Through the embodiments of this application, by refining the verification rules into two categories, format and content, and relying on knowledge graphs for correlation verification and intelligent correction, deep and high-precision automated quality control of extracted fields is achieved, ensuring the accuracy of data input into the payment decision system and the rationality of business logic, and significantly reducing processing failures or risks caused by errors in the original data.

[0123] Figure 4 A schematic diagram of a payment method according to another embodiment of this application is shown.

[0124] like Figure 4 As shown, Figure 4 This document fully demonstrates the system architecture and data flow process of this solution. The entire system is divided into two core layers: the intelligent import layer and the payment decision layer, with security provided by a real-time risk control layer, ultimately completing the payment task. The intelligent import layer and the payment decision layer can be located on the server described in the aforementioned embodiments.

[0125] In the embodiments of this application, the intelligent import layer is responsible for transforming unstructured raw bill files into high-quality, structured payment feature data, serving as the data preparation stage for intelligent decision-making. Start: The starting point of the process, representing the system receiving bill files (such as scanned copies) uploaded by users. Data Preprocessing: Optimizing the raw file images, including denoising, binarization, and skew correction, to improve the accuracy of subsequent text recognition. Optical Character Recognition (OCR) Module: Converting the text information in the preprocessed image into machine-readable text information. Natural Language Processing (NLP) Module: Performing semantic analysis on the text extracted by the OCR module, identifying and extracting key business fields (such as payee, amount, date, etc.). Knowledge Graph: A semantic network storing domain knowledge (such as bank coding rules, enterprise information, and business terminology specifications). It interacts with the NLP module to assist semantic understanding and provide a knowledge base for subsequent verification. After the intelligent import layer completes processing, it outputs structured payment features and passes them to the payment decision layer.

[0126] In the embodiments of this application, the payment decision layer is the intelligent core of the system, responsible for determining the optimal payment path and controlling its execution based on payment characteristics and integrating various information. The AI ​​routing engine is the decision-making and control center of the payment decision layer. It receives payment characteristics from the intelligent import layer and coordinates the invocation of all other modules. The multi-objective optimization model is a machine learning model trained on historical data. The AI ​​routing engine inputs payment characteristics and preset optimization objectives (such as cost, time, and security) into this model, and the model outputs a payment channel optimization strategy (i.e., priority suggestions for each channel) for the current task. The channel profile calculation is a dynamic calculation module that continuously analyzes historical and real-time payment data to generate a payment channel profile for each channel, including dimensions such as stability, efficiency, and cost, and provides it to the routing engine. The real-time risk control layer is a security checkpoint that intercepts risks before the final execution of payment instructions. It is triggered by the routing engine and performs dual risk analysis on payment instructions. The streaming rule engine performs real-time, high-speed risk screening of payment instructions based on a series of preset, explicit rules (such as amount thresholds and frequency limits). Graph Neural Network Risk Control Model: By analyzing the complex relationship network of accounts, individuals, and other entities involved in payment instructions, it identifies complex risk patterns that are difficult to detect using rules. The real-time risk control layer returns the evaluation results to the AI ​​routing engine to decide whether to grant the request.

[0127] In the embodiments of this application, the process begins with a billing file (start), which, after processing by the intelligent import layer, generates payment features and sends them to the AI ​​routing engine. The AI ​​routing engine simultaneously acquires strategy suggestions from a multi-objective optimization model and dynamic evaluations from channel profile calculations, comprehensively deciding on the target payment channel. After generating a payment instruction, a real-time risk control layer is invoked for review. If risk control is successful, the instruction is sent to the corresponding payment channel for execution; if intercepted, the process terminates. End: This represents the termination of a payment task processing flow, whether the payment is successfully executed or intercepted by risk control.

[0128] This application illustrates a complete, closed-loop automated payment processing system, encompassing data perception and structuring (intelligent import layer), intelligent decision-making through multi-source information fusion (payment decision layer), and continuous real-time proactive defense (real-time risk control layer). The AI ​​routing engine, acting as the core scheduler, drives the entire system to work collaboratively, ultimately achieving intelligent, dynamic, and secure selection of payment paths.

[0129] Based on the above payment method, embodiments of this application also provide a payment device. The following will be combined with... Figure 5 The device is described in detail.

[0130] Figure 5 A schematic block diagram of a payment device according to an embodiment of this application is shown.

[0131] like Figure 5 As shown, the payment device 500 in this embodiment includes a first acquisition module 510, a first determination module 520, a second acquisition module 530, a second determination module 540, and a generation module 550.

[0132] The first acquisition module 510 is used to acquire the payment characteristics of the target payment task. In one embodiment, the first acquisition module 510 can be used to execute step S210 described above, which will not be repeated here.

[0133] The first determining module 520 is used to determine payment channel optimization strategies for multiple payment channels based on payment characteristics and multiple predefined optimization objectives using a multi-objective optimization model. The payment channel optimization strategy represents the priority of each payment channel in executing the target payment task under the predefined multiple optimization objectives. The multi-objective optimization model is trained from historical payment data. In one embodiment, the first determining module 520 can be used to execute step S220 described above, which will not be repeated here.

[0134] The second acquisition module 530 is used to acquire payment channel profiles of multiple payment channels; the payment channel profile represents the performance evaluation results of the payment channel. In one embodiment, the second acquisition module 530 can be used to execute step S230 described above, which will not be repeated here.

[0135] The second determining module 540 is used to determine a target payment channel from multiple payment channels based on payment characteristics, payment channel optimization strategies, and payment channel profiles. In one embodiment, the second determining module 540 can be used to perform step S240 described above, which will not be repeated here.

[0136] The generation module 550 is used to generate a payment instruction based on the target payment channel; the payment instruction is used to instruct the execution of the target payment task. In one embodiment, the generation module 550 can be used to execute step S250 described above, which will not be repeated here.

[0137] According to embodiments of this application, any plurality of modules among the first acquisition module 510, the first determination module 520, the second acquisition module 530, the second determination module 540, and the generation module 550 can be combined into one module, or any one of these modules can be split into multiple modules. Alternatively, at least part of the functionality of one or more of these modules can be combined with at least part of the functionality of other modules and implemented in one module. According to embodiments of this application, at least one of the first acquisition module 510, the first determination module 520, the second acquisition module 530, the second determination module 540, and the generation module 550 can be at least partially implemented as hardware circuitry, such as field-programmable gate arrays, programmable logic arrays, systems-on-a-chip, systems-on-a-substrate, systems-on-package, application-specific integrated circuits, or implemented in hardware or firmware by any other reasonable means of integrating or packaging circuitry, or implemented in any one of software, hardware, and firmware methods, or in a suitable combination of any of these methods. Alternatively, at least one of the first acquisition module 510, the first determination module 520, the second acquisition module 530, the second determination module 540, and the generation module 550 can be at least partially implemented as a computer program module, which can perform corresponding functions when the computer program module is run.

[0138] In some embodiments, the apparatus further includes a training module for: acquiring a historical payment data set; the historical payment data set includes multiple historical payment task instances, each historical payment task instance being associated with payment characteristics at the time of payment, the payment channel used, and a payment result characterizing the payment effect; using the historical payment data set as training samples, training the initial model through a multi-objective optimization algorithm to obtain a trained multi-objective optimization model.

[0139] In some embodiments, the apparatus further includes: a third acquisition module, configured to acquire the business scenario to which the target payment task belongs and / or the associated customer demand; a selection module, configured to select at least two optimization objectives from the set of optimization objectives to form a predefined plurality of optimization objectives based on the business scenario and / or customer demand; the set of optimization objectives includes at least optimizing transaction costs, optimizing transaction time, and optimizing transaction security; and a configuration module, configured to configure the weight of each selected optimization objective in the multi-objective optimization model.

[0140] In some embodiments, the second acquisition module includes: a fourth acquisition module, configured to acquire a historical payment data set; the historical payment data set includes multiple historical payment task instances, each historical payment task instance being associated with the payment channel used during payment and a payment result characterizing the payment effect; an extraction module, configured to extract channel features associated with the performance of each payment channel from the historical payment data set; the channel features include at least one of the following: payment success rate, payment response time, and payment cost; a third determination module, configured to determine the evaluation result of each payment channel on at least one performance dimension based on the channel features; the performance dimension includes a stability dimension, an efficiency dimension, and a cost dimension; and a first processing module, configured to generate a payment channel profile for each payment channel based on the evaluation results.

[0141] In some embodiments, the apparatus further includes: a matching module, configured to, after generating a payment instruction based on a target payment channel, perform real-time monitoring and rule matching on the payment instruction based on preset risk control rules using a streaming rule engine to obtain a first risk assessment result; an identification module, configured to perform risk identification on the payment entity relationship network associated with the payment instruction using a graph neural network model to obtain a second risk assessment result; a second processing module, configured to generate a risk control decision for the payment instruction based on the first and second risk assessment results; the risk control decision includes allowing or blocking; and an execution module, configured to execute or block the payment instruction based on the risk control decision.

[0142] In some embodiments, the first acquisition module includes: an acquisition unit for acquiring a bill file for the target payment task; a first processing unit for performing image preprocessing on the bill file; the image preprocessing steps include at least denoising, binarization, and tilt correction; a second processing unit for extracting text information from the preprocessed bill file using optical character recognition technology; a third processing unit for performing semantic understanding on the extracted text information using natural language processing technology to identify and extract key fields; a fourth processing unit for verifying and correcting the extracted key fields using a knowledge graph and preset verification rules to obtain verified and corrected data; and a fifth processing unit for converting the verified and corrected data into a structured format to obtain the payment features of the target payment task.

[0143] In some embodiments, the fourth processing unit includes: a first processing subunit, used to validate the extracted key fields using a knowledge graph and preset validation rules to obtain validation results; the preset validation rules include format rules for validating field formats and content rules for validating logical relationships between fields; and a second processing subunit, used to correct key fields that do not conform to the preset validation rules based on the validation results to obtain validated and corrected data.

[0144] Figure 6 A block diagram schematically illustrates an electronic device suitable for implementing a payment method according to an embodiment of this application.

[0145] like Figure 6 As shown, an electronic device 600 according to an embodiment of this application includes a processor 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory 602 or a program loaded from a storage portion 608 into a random access memory 603. The processor 601 may include, for example, a general-purpose microprocessor, an instruction set processor and / or an associated chipset and / or a dedicated microprocessor. The processor 601 may also include onboard memory for caching purposes. The processor 601 may include a single processing unit or multiple processing units for executing different steps of the method flow according to an embodiment of this application.

[0146] Random access memory 603 stores various programs and data required for the operation of electronic device 600. Processor 601, read-only memory 602, and random access memory 603 are interconnected via bus 604. Processor 601 executes various steps of the method flow according to embodiments of this application by executing programs in read-only memory 602 and / or random access memory 603. It should be noted that programs may also be stored in one or more memories other than read-only memory 602 and random access memory 603. Processor 601 may also execute various steps of the method flow according to embodiments of this application by executing programs stored in one or more memories.

[0147] According to embodiments of this application, the electronic device 600 may further include an input / output interface 605, which is also connected to a bus 604. The electronic device 600 may also include one or more of the following components connected to the input / output interface 605: an input section 606 including a keyboard, mouse, etc.; an output section 607 including a cathode ray tube, liquid crystal display, etc., and a speaker, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card, such as a local area network card, modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the input / output interface 605 as needed. A removable medium 611, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 610 as needed so that computer programs read from it can be installed into the storage section 608 as needed.

[0148] Embodiments of this application also provide a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not assembled into the device / apparatus / system. The computer-readable storage medium carries one or more programs, which, when executed, implement the method according to the embodiments of this application.

[0149] According to embodiments of this application, the computer-readable storage medium can be a non-volatile computer-readable storage medium, such as including but not limited to: portable computer disks, hard disks, random access memory, read-only memory, erasable programmable read-only memory, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination thereof. In embodiments of this application, the computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. For example, according to embodiments of this application, the computer-readable storage medium may include the read-only memory 602 described above, and / or random access memory 603, and / or one or more memories other than read-only memory 602 and random access memory 603.

[0150] Embodiments of this application also include a computer program product comprising a computer program containing program code for performing the methods shown in the flowchart. When the computer program product is run on a computer system, the program code is used to cause the computer system to implement the methods provided in the embodiments of this application.

[0151] In one embodiment, the computer program may rely on a tangible storage medium such as an optical storage device or a magnetic storage device. In another embodiment, the computer program may also be transmitted and distributed in the form of signals over a network medium, and downloaded and installed via the communication section 609, and / or installed from the removable medium 611. The program code contained in the computer program can be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination thereof.

[0152] In embodiments of this application, the computer program can be downloaded and installed from a network via communication section 609, and / or installed from removable medium 611. When the computer program is executed by processor 601, it performs the functions defined in the system of embodiments of this application. According to embodiments of this application, the systems, devices, apparatuses, modules, units, etc., described above can be implemented by computer program modules.

[0153] According to embodiments of this application, program code for executing the computer programs provided in the embodiments of this application can be written in any combination of one or more programming languages. Specifically, these computational programs can be implemented using high-level procedural and / or object-oriented programming languages, and / or assembly / machine languages. The program code can be executed entirely on the user's computing device, partially on the user's device, partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0154] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0155] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application.

Claims

1. A payment method, characterized in that, The method includes: Obtain the payment characteristics of the target payment task; Based on the payment characteristics and multiple predefined optimization objectives, a multi-objective optimization model is used to determine the payment channel optimization strategies for multiple payment channels. The payment channel optimization strategy represents the priority of each payment channel in executing the target payment task under the multiple predefined optimization objectives. The multi-objective optimization model is trained from historical payment data. Obtain payment channel profiles for the multiple payment channels; the payment channel profiles represent the performance evaluation results of the payment channels. Based on the payment characteristics, the payment channel optimization strategy, and the payment channel profile, a target payment channel is determined from the plurality of payment channels; Based on the target payment channel, a payment instruction is generated; the payment instruction is used to instruct the execution of the target payment task.

2. The method according to claim 1, characterized in that, The training steps of the multi-objective optimization model include: Obtain a historical payment data set; the historical payment data set includes multiple historical payment task instances, each of which is associated with the payment characteristics at the time of payment, the payment channel used, and the payment result characterizing the payment effect; Using the historical payment data set as training samples, the initial model is trained using a multi-objective optimization algorithm to obtain the trained multi-objective optimization model.

3. The method according to claim 1, characterized in that, The method further includes: Obtain the business scenario and / or associated customer needs of the target payment task; Based on the business scenario and / or the customer needs, at least two optimization objectives are selected from the set of optimization objectives to constitute the predefined plurality of optimization objectives; the set of optimization objectives includes at least optimizing transaction costs, optimizing transaction time, and optimizing transaction security. Assign weights to each selected optimization objective when making decisions in the multi-objective optimization model.

4. The method according to claim 1, characterized in that, The process of obtaining payment channel profiles for the multiple payment channels includes: Obtain a historical payment data set; the historical payment data set includes multiple historical payment task instances, each of which is associated with the payment channel used during the payment and the payment result representing the payment effect; From the historical payment data set, extract channel features associated with the performance of each payment channel; the channel features include at least one of the following: payment success rate, payment response time, and payment cost; Based on the channel characteristics, the evaluation results of each payment channel in at least one performance dimension are determined; the performance dimensions include stability, efficiency, and cost. Based on the evaluation results, a payment channel profile is generated for each payment channel.

5. The method according to claim 1, characterized in that, After generating a payment instruction based on the target payment channel, the method further includes: The payment instructions are monitored and matched in real time based on preset risk control rules through a streaming rule engine to obtain the first risk assessment result. By using a graph neural network model, risk identification is performed on the payment entity relationship network associated with the payment instruction to obtain a second risk assessment result; Based on the first risk assessment result and the second risk assessment result, a risk control decision is generated for the payment instruction; the risk control decision includes allowing or blocking. Based on the risk control decision, execute or intercept the payment instruction.

6. The method according to any one of claims 1 to 5, characterized in that, The acquisition of payment characteristics for the target payment task includes: Obtain the billing file for the target payment task; The billing file is subjected to image preprocessing; the image preprocessing steps include at least denoising, binarization, and tilt correction. Text information is extracted from the preprocessed billing document using optical character recognition technology. Natural language processing technology is used to perform semantic understanding on the extracted text information in order to identify and extract key fields; Using knowledge graphs and preset verification rules, the extracted key fields are verified and corrected to obtain the verified and corrected data; The verified and corrected data is converted into a structured format to obtain the payment characteristics of the target payment task.

7. The method according to claim 6, characterized in that, The process of using knowledge graphs and preset verification rules to verify and correct the extracted key fields yields verified and corrected data, including: The extracted key fields are validated using the knowledge graph and the preset validation rules to obtain validation results. The preset validation rules include format rules for validating field formats and content rules for validating logical relationships between fields. Based on the verification results, key fields that do not conform to the preset verification rules are corrected to obtain the verified and corrected data.

8. A payment device, characterized in that, The device includes: The first acquisition module is used to acquire the payment characteristics of the target payment task; The first determining module is used to determine payment channel optimization strategies for multiple payment channels based on the payment characteristics and multiple predefined optimization objectives using a multi-objective optimization model; the payment channel optimization strategy represents the priority of each payment channel in executing the target payment task under the multiple predefined optimization objectives; the multi-objective optimization model is trained from historical payment data. The second acquisition module is used to acquire payment channel profiles of the multiple payment channels; the payment channel profiles represent the performance evaluation results of the payment channels; The second determining module is used to determine a target payment channel from the plurality of payment channels based on the payment characteristics, the payment channel optimization strategy, and the payment channel profile. The generation module is used to generate a payment instruction based on the target payment channel; the payment instruction is used to instruct the execution of the target payment task.

9. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program or instructions stored thereon, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 7.

11. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 7.

Images