Data processing method and device, electronic equipment and computer readable storage medium

Abstract

The data processing method and device, the electronic device and the computer readable storage medium provided by the embodiments of the present application are related to the fields of artificial intelligence, natural language processing, cloud technology, intelligent transportation and blockchain technology. The method comprises: in response to a payment request for a to-be-paid task of a target object, determining a task feature of the to-be-paid task; determining a repeated payment possibility of the to-be-paid task based on the task feature of the to-be-paid task and an association relationship between the to-be-paid task and a paid task of the target object; and if it is determined that the to-be-paid task has repeated payment, determining whether to intercept a payment operation of the payment request for the to-be-paid task according to a task level of a task type of the to-be-paid task. The present application can quickly and accurately determine the repeated payment possibility of the to-be-paid task, and then determine whether to intercept the payment operation of the payment request for the to-be-paid task, thereby avoiding repeated payment of the to-be-paid task and improving the processing efficiency of the payment request for the to-be-paid task.

Description

TECHNICAL FIELD

[0001] The present application relates to the fields of artificial intelligence, natural language processing, cloud technology, intelligent transportation and blockchain technology, in particular, the present application relates to a data processing method and device, electronic equipment, computer readable storage medium and computer program product. BACKGROUND

[0002] With the development of intelligent terminals and the popularity of network applications, there are more and more payment scenarios, and users can realize various payment operations through the application program with payment function installed on the terminal, but in various payment scenarios, there will inevitably be repeated payment phenomenon.

[0003] In order to solve the technical problem, in the related art, after completing the payment operation, the payment result corresponding to the serial number of the payment operation is used to identify whether the payment operation is a repeated payment operation, and based on the identification result, the payment operation of the repeated payment operation is refunded and other remedial operations. But this way will have the problems of misidentification and missed identification, and the practicability needs to be improved. SUMMARY

[0004] The embodiments of the present application provide a data processing method, device, electronic equipment, computer readable storage medium and computer program product, which can avoid repeated payment of the to-be-paid task and better meet the practical needs.

[0005] According to an aspect of an embodiment of the present application, a data processing method is provided, which comprises:

[0006] In response to a payment request for a to-be-paid task of a target object, determining the task characteristics of the to-be-paid task, wherein the task characteristics of the to-be-paid task include the task type of the to-be-paid task;

[0007] Based on the association relationship between the task characteristics of the to-be-paid task and the paid tasks of the target object, determining the possibility of repeated payment of the to-be-paid task;

[0008] If it is determined that the to-be-paid task exists repeated payment, according to the task level of the task type of the to-be-paid task, determining whether to intercept the payment operation of the payment request for the to-be-paid task.

[0009] According to another aspect of an embodiment of the present application, a data processing device is provided, which comprises:

[0010] The feature determination module is configured to determine the task characteristics of the to-be-paid task in response to the payment request for the to-be-paid task of the target object, wherein the task characteristics of the to-be-paid task include the task type of the to-be-paid task;

[0011] The possibility determination module is configured to determine a repeated payment possibility of the to-be-paid task based on an association between a task feature of the to-be-paid task and a paid task of the target object.

[0012] The processing module is configured to determine whether to intercept a payment operation of a payment request for the to-be-paid task according to a task level of a task type of the to-be-paid task if it is determined that the to-be-paid task has the repeated payment.

[0013] Optionally, when determining the repeated payment possibility of the to-be-paid task based on the association between the task feature of the to-be-paid task and the paid task of the target object, the possibility determination module is specifically configured to:

[0014] input the task feature of the to-be-paid task into a trained repeated payment determination module to determine the repeated payment possibility of the to-be-paid task, wherein the repeated payment determination module is configured to extract an association between the task feature of the to-be-paid task and a task feature of the paid task.

[0015] The repeated payment determination module is obtained based on the paid task as a training sample.

[0016] Optionally, the repeated payment determination module is obtained by the following method:

[0017] obtain a training data set, wherein the training data set includes a plurality of training samples, each training sample includes a sample task and a labeled label of the sample task, and the labeled label includes whether the sample task belongs to repeated payment, and the sample task is any one of the plurality of paid tasks.

[0018] input each sample task into an initial neural network model in sequence to obtain a repeated payment possibility of each sample task;

[0019] determine a loss of the initial neural network model based on the repeated payment possibility of each sample task and the labeled label.

[0020] if the loss meets a preset training end condition, end the training to obtain the repeated payment determination module.

[0021] if the loss does not meet the preset training end condition, adjust model parameters of the initial neural network model, and continue to train the adjusted initial neural network model based on the training data set.

[0022] Optionally, when determining the repeated payment possibility of the to-be-paid task based on the association between the task feature of the to-be-paid task and the paid task of the target object, the possibility determination module is specifically configured to:

[0023] determine a behavior feature of the target object according to the paid task.

[0024] determine whether the task characteristic of the to-be-paid task matches the behavior characteristic of the target object according to the task characteristic of the to-be-paid task and the behavior characteristic of the target object;

[0025] If the task characteristic of the to-be-paid task matches the behavior characteristic of the target object, it is determined that the possibility of repeated payment is that the to-be-paid task exists repeated payment.

[0026] If the task characteristic of the to-be-paid task does not match the behavior characteristic of the target object, it is determined that the possibility of repeated payment is that the to-be-paid task does not exist repeated payment.

[0027] Optionally, when determining whether to intercept the payment operation of the payment request for the to-be-paid task according to the task level of the task type of the to-be-paid task, the processing module is specifically configured to:

[0028] If the task level of the task type of the to-be-paid task is the first level, the payment operation for the to-be-paid task is performed.

[0029] If the task level of the task type of the to-be-paid task is not the first level, the payment operation for the to-be-paid task is intercepted.

[0030] The payment priority of the to-be-paid task corresponding to the first level is higher than the payment priority of the to-be-paid task corresponding to the level other than the first level.

[0031] Optionally, after intercepting the payment operation for the to-be-paid task, the processing module is further configured to:

[0032] If the task level of the task type of the to-be-paid task is the second level, the first prompt information is generated according to the to-be-paid task, and the first prompt information is sent to the terminal corresponding to the target object.

[0033] In response to the first feedback information received from the target object for the first prompt information, it is determined whether to perform the payment operation for the to-be-paid task, wherein the first feedback information is used to indicate whether to perform the payment operation for the to-be-paid task.

[0034] Optionally, after intercepting the payment operation for the to-be-paid task, the processing module is further configured to:

[0035] If the task level of the task type of the to-be-paid task is the third level, the second prompt information is generated according to the to-be-paid task, and the second prompt information is sent to the third-party service platform corresponding to the task type.

[0036] In response to the second feedback information received from the third-party service platform for the second prompt information, it is determined whether the to-be-paid task belongs to the repeated payment task.

[0037] If it is determined that the to-be-paid task does not belong to the repeated payment task, a payment operation for the to-be-paid task is performed.

[0038] Optionally, the processing module is further configured to:

[0039] obtain evaluation information of an execution result of the to-be-paid task;

[0040] If it is determined according to the evaluation information that the to-be-paid task belongs to the repeated payment task, a refund operation of a payment resource quantity for the to-be-paid task is performed.

[0041] According to still another aspect of the embodiments of the present application, an electronic device is provided, which includes a memory, a processor, and a computer program stored in the memory, and the processor executes the computer program to implement the steps of the above method.

[0042] According to still another aspect of the embodiments of the present application, a computer readable storage medium is provided, which stores a computer program, and the computer program is executed by a processor to implement the steps of the above method.

[0043] According to still another aspect of the embodiments of the present application, a computer program product is provided, which includes a computer program, and the computer program is executed by a processor to implement the steps of the above method.

[0044] The technical scheme provided by the embodiments of the present application has the beneficial effects that:

[0045] The data processing method, device, electronic device, computer readable storage medium and computer program product provided by the embodiments of the present application. In the data processing method, by responding to the payment request of the to-be-paid task of the target object, the task characteristics of the to-be-paid task are determined, and based on the association relationship between the task characteristics of the to-be-paid task and the paid task of the target object, the repeated payment possibility of the to-be-paid task is determined, which can quickly and accurately determine the repeated payment possibility of the to-be-paid task.

[0046] In the method, in a case where it is determined that the to-be-paid task exists repeated payment, it is determined whether to intercept the payment operation of the payment request for the to-be-paid task according to the task level of the task type of the to-be-paid task. It can be seen that, compared with the manner in the related art that whether the executed payment operation belongs to the repeated payment operation is determined after the payment operation is executed, the method can consider the possibility of repeated payment of the to-be-paid task before the payment request of the to-be-paid task is processed, determine whether to intercept the payment operation of the payment request for the to-be-paid task that exists the possibility of repeated payment in combination with the task level of the task type of the to-be-paid task, effectively prevent the case of repeated payment, avoid the repeated payment of the to-be-paid task, improve the processing efficiency of the payment request of the to-be-paid task, guarantee the payment safety of the target object, and better meet the practical requirements. BRIEF DESCRIPTION OF DRAWINGS

[0047] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the description of the embodiments of the present application will be briefly introduced.

[0048] Figure 1 An optional structure diagram of a data processing system in this scenario is shown;

[0049] Figure 2 A flowchart of a data processing method executed by the data processing system in this application scenario is shown;

[0050] Figure 3 A flowchart of a data processing method provided by the embodiments of the present application is shown;

[0051] Figures 4a to 4f A schematic diagram of initiating a payment request for a to-be-paid task is shown;

[0052] Figure 5 A specific flowchart of step S130 in the embodiments of the present application is shown;

[0053] Figure 6 A flowchart of implementing the above method in a specific application scenario of the present application is shown;

[0054] Figure 7 A structure diagram of a data processing apparatus provided by the embodiments of the present application is shown;

[0055] Figure 8 A structure diagram of an electronic device to which the embodiments of the present application are applicable is shown. DETAILED DESCRIPTION

[0056] The embodiments of the present application will be described below in conjunction with the accompanying drawings. It should be understood that the embodiments described below in conjunction with the accompanying drawings are exemplary descriptions of the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions of the embodiments of the present application.

[0057] Those skilled in the art can understand that the singular forms "a", "an" and "the" used herein include plural forms, unless specifically stated otherwise. It should be further understood that the terms "include" and "contain" used in the embodiments of the present application mean that the corresponding features can be implemented as the presented features, information, data, steps, operations, elements and / or components, but do not exclude other features, information, data, steps, operations, elements, components and / or combinations thereof supported by the present technology. It should be understood that when we say that an element is "connected" or "coupled" to another element, the element can be directly connected or coupled to the other element, or can mean that the element and the other element establish a connection relationship through an intermediate element. In addition, "connected" or "coupled" used herein can include wireless connection or wireless coupling. The term "and / or" used herein indicates that at least one of the items defined by the term, for example, "A and / or B" can be implemented as "A", or as "B", or as "A and B".

[0058] In order to make the purposes, technical solutions and advantages of the present application clearer, the embodiments of the present application will be described in further detail below in conjunction with the accompanying drawings.

[0059] The terms and related technologies involved in the present application will be described below:

[0060] Payment institution (i.e., third-party service platform): any online or offline institution that can provide payment services, including but not limited to public utilities such as water, electricity, gas, cable TV, and life payment services, and offline or online business halls such as broadband, communication, traffic, etc.

[0061] Anti-repayment: preventing duplicate payment operations for the same payment task, resulting in duplicate charges to the account of the target object corresponding to the payment task.

[0062] Seizure and charge: in response to the payment operation of the payment request for the to-be-paid task initiated by the target object on the terminal corresponding to the target object according to the to-be-paid task, and successfully completing the payment operation.

[0063] The institution (i.e., the payment institution) initiates the withholding: after the target object signs a payment agreement with the third-party service platform, the third-party service platform initiates a payment request for the to-be-paid task according to the payment agreement. After performing the payment operation for the institution withholding, a receipt message can be generated according to the payment operation, and the receipt message is sent to the target object corresponding to the to-be-paid task.

[0064] In the related art, after the payment operation is completed, the serial number corresponding to the payment result of the payment operation is used to identify whether the payment task is a repeated payment task. In view of this, the embodiments of the present application creatively find that the method in the related art cannot determine whether the payment task has the possibility of repeated payment before performing the payment operation of the payment request of the payment task, in order to prevent the user from performing repeated payment operations. Moreover, according to the method provided in the related art, after the payment operation is completed, the serial number corresponding to the payment result of the payment operation is used to identify whether the payment operation is a repeated payment task. In the case where it is found that the payment operation is a repeated payment task, performing the corresponding operation on the payment operation will waste a lot of time and cost, and cannot well guarantee the payment security.

[0065] In addition, due to the instability of the payment system and other reasons, in the case where the serial number generation is problematic (for example, two same serial numbers are generated for the payment result of the same payment task, or the same serial number is generated for the payment result of different payment tasks), it is also easy to misidentify whether the payment task is a repeated payment task. Or, in the case of other people paying, the difference in payment system of different third-party service platforms, etc., it is also impossible to accurately determine whether the payment task is a repeated payment task according to the serial number.

[0066] To address at least one of the above technical problems or areas for improvement in the related art that are discovered by the inventors in a creative manner, embodiments of the present disclosure provide a data processing method, apparatus, electronic device, computer-readable storage medium, and computer program product. In the data processing method, by responding to a payment request for a to-be-paid task of a target object, a task feature of the to-be-paid task is determined, and based on an association relationship between the task feature of the to-be-paid task and a paid task of the target object, the possibility of repeated payment of the to-be-paid task can be quickly and accurately determined. Moreover, in the method, if it is determined that the to-be-paid task has the possibility of repeated payment, whether to intercept a payment operation of the payment request for the to-be-paid task can be determined according to a task level of a task type of the to-be-paid task, that is, before the payment request of the to-be-paid task is processed, the possibility of repeated payment of the to-be-paid task can be considered, and whether to intercept the payment operation of the payment request for the to-be-paid task that has the possibility of repeated payment can be determined in combination with the task level of the task type of the to-be-paid task, thereby avoiding the repeated payment of the to-be-paid task, effectively preventing the situation of repeated payment, improving the processing efficiency of the payment request of the to-be-paid task, and better meeting the practical needs.

[0067] Optionally, the data processing method provided in the embodiments of the present disclosure can be implemented based on artificial intelligence (AI) technology. AI is the use of digital computers or computer-controlled machines to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use knowledge to obtain the best results. With the research and progress of artificial intelligence technology, artificial intelligence technology has been widely researched and applied in many fields. It is believed that with the development of technology, artificial intelligence technology will be applied in more fields and play an increasingly important role.

[0068] Optionally, the data processing method provided in the embodiments of the present disclosure can be implemented based on natural language processing (NLP) technology. NLP is an important direction in the fields of computer science and artificial intelligence. It studies various theories and methods that can enable effective communication between people and computers using natural language. Natural language processing is a science that integrates linguistics, computer science, and mathematics. Therefore, the research in this field will involve natural language, that is, the language used in daily life, so it has a close relationship with the study of linguistics. Natural language processing technology usually includes text processing, semantic understanding, machine translation, robot question answering, knowledge graph, and other technologies.

[0069] With the research and progress of artificial intelligence technology, artificial intelligence technology is researched and applied in many fields, such as common smart home, smart wearable device, virtual assistant, smart speaker, smart marketing, unmanned driving, automatic driving, unmanned aerial vehicle, robot, smart medical treatment, smart customer service, Internet of vehicles, automatic driving, intelligent transportation and the like. It is believed that with the development of technology, artificial intelligence technology will be applied in more fields and play more and more important value.

[0070] Optionally, the data processing method provided by the embodiment of the application can be implemented based on cloud technology, for example, the data calculation involved in the process of updating and training the deep learning model can be implemented in a cloud computing manner. Cloud technology refers to a kind of hosting technology that unifies a series of resources such as hardware, software and network in a wide area network or a local area network to realize the calculation, storage, processing and sharing of data. Cloud technology is a general term of network technology, information technology, integration technology, management platform technology, application technology and the like applied based on cloud computing business model, can form a resource pool, and can be used on demand, flexibly and conveniently. Cloud computing technology will become an important support. Cloud computing refers to a delivery and use mode of IT infrastructure, that is, obtaining required resources in a manner of on-demand and easy expansion through a network; and broad-sense cloud computing refers to a delivery and use mode of service, that is, obtaining required service in a manner of on-demand and easy expansion through a network. Such service can be related to IT and software, Internet, or other services. With the development of Internet, real-time data flow and diversified connection devices, and the promotion of requirements such as search service, social network, mobile commerce and open collaboration, cloud computing has developed rapidly. Different from previous parallel distributed computing, the generation of cloud computing will revolutionarily change the whole Internet mode and enterprise management mode in concept.

[0071] Optionally, the data processing method provided in this application embodiment can also be implemented in the field of intelligent transportation and applied to autonomous driving or transportation applications. For example, based on this data processing method, it can determine whether there is a possibility of duplicate payment for payment tasks in toll scenarios such as parking lots and ETC (Electronic Toll Collection, an automatic road toll payment system, or non-stop electronic toll collection system). Specifically, application scenarios in the field of intelligent transportation may include, but are not limited to, Intelligent Traffic Systems (ITS). Intelligent Traffic Systems, also known as Intelligent Transportation Systems, effectively integrate advanced science and technology (information technology, computer technology, data communication technology, sensor technology, electronic control technology, automatic control theory, operations research, artificial intelligence, etc.) into transportation, service control, and vehicle manufacturing, strengthening the connection between vehicles, roads, and users, thereby forming a comprehensive transportation system that ensures safety, improves efficiency, improves the environment, and saves energy.

[0072] Optionally, the data processing method provided in this application embodiment can also be implemented based on blockchain technology. Specifically, the data used in this data processing method, such as training datasets, paid tasks of the target object, the association between the task characteristics of tasks to be paid and the paid tasks of the target object, and the correspondence between preset task types and task levels, can be stored on the blockchain.

[0073] To facilitate understanding of the application value of the data processing method provided in this application embodiment, the data processing method will be described below with reference to a specific application scenario embodiment.

[0074] Figure 1 A schematic diagram of an alternative data processing system for this scenario is shown, such as... Figure 1 As shown, the system includes a terminal device 10, a third-party service platform (i.e., the aforementioned payment institution) 20, a network 30, an application server 40, and a module training server 50. The terminal device 10 and the third-party service platform 20 can sign a payment agreement. Both the terminal device 10 and the third-party service platform 20 can communicate with the application server 40 through the network 30. The application server 40 and the module training server 50 can interact. For example, the application server 40 can receive a duplicate payment determination module or a multi-class aggregation model sent by the module training server 50.

[0075] In the data processing system, an application program for performing data processing can be installed in the terminal device 10, or a plug-in or applet for performing data processing can be provided in an application program in the terminal device 10. By opening the application program for performing data processing on the terminal device 10 or opening the corresponding plug-in or applet in the application program provided with the plug-in or applet for performing the data processing method, the terminal device 10 can be enabled to perform the data processing method. Alternatively, by triggering the interface of the third-party service platform 20, the third-party service platform 20 can be enabled to perform the data processing method. The data processing method can also be implemented by a processor calling computer-readable instructions stored in a memory.

[0076] The terminal device 10 can be a user equipment (UE), a mobile device, a user terminal, a terminal, a cellular phone, a cordless phone, a personal digital assistant (PDA), a handheld device, a computing device, or a wearable device, etc. The interface of the third-party service platform 20 can be provided with a plug-in for performing data processing. The form of the interface of the third-party service platform 20 is not limited in the present application. For example, the interface of the third-party service platform 20 can be an API (Application Programming Interface). The third-party service platform 20 can be any online or offline institution that can provide payment services.

[0077] The module training server 50 can be configured to train an initial multi-classification aggregation model based on a first training set determined by the paid tasks of the target object corresponding to the payment request of the to-be-paid task, to obtain a multi-classification aggregation model, or to train an initial neural network model based on a training data set determined by the paid tasks of the target object corresponding to the payment request of the to-be-paid task, to obtain a repeated payment determination module, and send the repeated payment determination module or the multi-classification aggregation model to the application server 40.

[0078] The application server 40 can be configured to deploy the multi-classification aggregation model after receiving the multi-classification aggregation model, or to deploy the repeated payment determination module after receiving the repeated payment determination module, so as to execute the data processing method provided in the embodiments of the present application.

[0079] The data processing system shown in Figure 1 The data processing system shown in Figure 2 The data processing system shown in Figure 2As shown, the method can include the following steps S21 to S28.

[0080] Step S21: The terminal device 10 generates a payment request for the to-be-paid task of the target object according to a triggering operation of the target object, and sends the payment request to the application server 40 through the network 30.

[0081] Step S22: The third-party service platform 20 generates a payment request for the to-be-paid task of the target object according to a pre-set payment agreement signed with the target object, and sends the payment request to the application server 40 through the network 30.

[0082] Wherein, the execution order of step S21 and step S22 is not limited in the embodiments of the present application, and step S21 and step S22 can also be executed simultaneously, or only step S21 can be executed without executing step S22, or only step S22 can be executed without executing step S21. The present application does not limit this.

[0083] Step S23: After receiving the payment request from the terminal device 10 or the third-party service platform 20, the application server 40 can perform permission verification on the terminal device 10 or the third-party service platform 20 according to the payment request.

[0084] Wherein, the identity information of the target object corresponding to the payment request (i.e., the target object corresponding to the terminal device 10) (for example, the nickname, ID number, etc. of the target object), login information, etc. can be used to perform permission verification on the target object corresponding to the payment request. If it is determined according to the identity information and login information of the target object that the target object has booked a task type corresponding to the to-be-paid task, it can be determined that the target object (i.e., the terminal device 10) has the corresponding permission.

[0085] The identity information of the third-party service platform 20 (for example, the signature of the third-party service platform 20), whether the third-party service platform 20 has signed a payment agreement with the target object corresponding to the payment request, etc. can be used to perform permission verification on the third-party service platform 20. If it is determined that the third-party service platform 20 has signed a payment agreement with the target object corresponding to the payment request, and the identity information of the third-party service platform 20 matches the identity information of the third-party service platform 20 corresponding to the to-be-paid task, it can be determined that the third-party service platform 20 has the corresponding permission.

[0086] Step S24: In response to the payment request for the to-be-paid task of the target object, the application server 40 determines the task characteristics of the to-be-paid task, wherein the task characteristics of the to-be-paid task include the task type of the to-be-paid task.

[0087] Step S25: The application server 40 determines the possibility of duplicate payment for the task to be paid based on the task characteristics of the task to be paid and the association between the paid tasks of the target object.

[0088] Alternatively, application server 40 can also determine the likelihood of duplicate payments for a pending payment task through A processing.

[0089] Process A may include: the application server 40 may input the task characteristics of the task to be paid into the received duplicate payment determination module trained by the module training server 50, and determine the probability of duplicate payment of the task to be paid.

[0090] Process A may also include:

[0091] Determine the behavioral characteristics of the target object based on the paid tasks;

[0092] Based on the task characteristics of the task to be paid and the behavioral characteristics of the target object, determine whether the task characteristics of the task to be paid match the behavioral characteristics of the target object;

[0093] If the task characteristics of the pending payment task match the behavioral characteristics of the target object, the possibility of duplicate payment is determined as the pending payment task has duplicate payment.

[0094] If the task characteristics of the task to be paid do not match the behavioral characteristics of the target object, the probability of duplicate payment is determined to be that the task to be paid does not have duplicate payment.

[0095] Step S26: Determine whether to block the payment operation for the payment request for the pending payment task based on the probability of duplicate payment for the pending payment task.

[0096] If it is determined that a payment task involves duplicate payments, the application server 40 can determine whether to intercept the payment operation for that payment task based on the task level of the task type. If it is determined that there are no duplicate payments, the payment operation for the payment task is executed directly. Specifically, if it is determined that a payment task involves duplicate payments, the application server 40 can execute step S26 through process B. Specifically, process B includes:

[0097] If the task type of the task to be paid is at the first level, execute the payment operation for the task to be paid.

[0098] If the task type of the task to be paid is not at the first level, intercept the payment operation for the task to be paid.

[0099] Among them, the payment priority of the tasks corresponding to the first level is higher than that of the tasks not corresponding to the first level.

[0100] Optionally, after intercepting the payment operation for the pending payment task, the B process may further include:

[0101] If the task type of the task to be paid is at the second level, generate a first prompt message based on the task to be paid and send the first prompt message to the terminal corresponding to the target object;

[0102] In response to a first feedback message received from the target object regarding the first prompt message, it is determined whether to perform a payment operation for the pending payment task, wherein the first feedback message is used to indicate whether to perform a payment operation for the pending payment task.

[0103] Optionally, after intercepting the payment operation for the pending payment task, the B process may further include:

[0104] If the task type of the task to be paid is at level three, generate a second prompt message based on the task to be paid and send the second prompt message to the third-party service platform corresponding to the task type.

[0105] In response to the second feedback information received from the third-party service platform regarding the second prompt information, determine whether the task to be paid is a duplicate payment task;

[0106] If it is determined that the task to be paid is not a duplicate payment task, execute the payment operation for the task to be paid.

[0107] Step S27: Application server 40 obtains evaluation information of the execution results of the task to be paid.

[0108] Step S28: The application server 40 determines further processing for the payment task based on the evaluation information.

[0109] If the application server 40 determines, based on the evaluation information, that the task to be paid is a duplicate payment task, it will perform a refund operation on the amount of payment resources for the task to be paid. If the application server 40 determines, based on the evaluation information, that the task to be paid is not a duplicate payment task, it will end the processing operation for that task.

[0110] This data processing system can respond to payment requests for pending tasks targeting a target object, determine the task characteristics of the pending task, and determine the probability of duplicate payment for the pending task based on the correlation between the task characteristics of the pending task and the target object's already paid tasks. It can quickly and accurately determine the probability of duplicate payment for the pending task.

[0111] Furthermore, this data processing system can determine whether to block payment requests for tasks with duplicate payment potential based on the task type and task level of the task to be paid. In other words, it can consider the possibility of duplicate payment before processing the payment request for a task, and determine whether to block payment requests for tasks with duplicate payment potential based on the task type and task level of the task to be paid. This effectively avoids duplicate payment of tasks, prevents duplicate payment situations, improves the processing efficiency of payment requests for tasks with duplicate payment potential, ensures the payment security of the target object, and better meets practical needs.

[0112] The technical solutions of this application and their effects are described below through several exemplary embodiments. It should be noted that the following embodiments can be referenced, borrowed from, or combined with each other. Identical terms, similar features, and similar implementation steps in different embodiments will not be repeated.

[0113] Figure 3 A flowchart of a data processing method provided in an embodiment of this application is shown. The entity executing this data processing method may be a data processing device. Optionally, the data processing device may include, but is not limited to, a terminal device or a server; optionally, the server may be a cloud server. The terminal device may be a user equipment (UE), mobile device, user terminal, terminal, cellular phone, cordless phone, personal digital assistant (PDA), handheld device, computing device, or wearable device, etc. This data processing method can also be implemented by a processor calling computer-readable instructions stored in memory.

[0114] Optionally, the method can be executed by a user terminal, such as mobile phones, computers, smart voice interaction devices, smart home appliances, in-vehicle terminals, wearable electronic devices, AR (augmented reality) / VR (virtual reality) devices, etc.

[0115] like Figure 3 As shown, this application provides a data processing method, which includes the following steps S110 to S130.

[0116] Step S110: In response to a payment request for a task to be paid for a target object, determine the task characteristics of the task to be paid, wherein the task characteristics of the task to be paid include the task type of the task to be paid.

[0117] Step S120: Based on the relationship between the task characteristics of the task to be paid and the paid tasks of the target object, determine the possibility of duplicate payment for the task to be paid.

[0118] Step S130: If it is determined that there is duplicate payment for the task to be paid, determine whether to block the payment operation for the payment request for the task to be paid based on the task level of the task type.

[0119] In this data processing method, by responding to a payment request for a pending payment task for a target object, the task characteristics of the pending payment task are determined, and based on the association between the task characteristics of the pending payment task and the paid tasks of the target object, the probability of duplicate payment for the pending payment task is determined, which can quickly and accurately determine the probability of duplicate payment for the pending payment task.

[0120] When it is determined that a payment task may involve duplicate payments, the method determines whether to block the payment operation for that task based on the task type and task level. Compared to related technologies that determine whether a payment operation is a duplicate payment after it has been executed, this method considers the possibility of duplicate payments before processing the payment request. By combining the task type and task level, it determines whether to block the payment operation for a task with a potential for duplicate payments, effectively preventing duplicate payments, avoiding duplicate payments for pending tasks, improving the processing efficiency of payment requests, ensuring the payment security of the target object, and better meeting practical needs.

[0121] In this method, the task to be paid can be any task that requires a payment operation, including but not limited to any task that requires a payment operation, such as utility bill payments (e.g., water bills, electricity bills, gas bills, cable TV fees, etc.) and communication bill payments (e.g., broadband fees, call fees, data fees, etc.).

[0122] The target object may include, but is not limited to, natural persons or organizations; this application makes no such limitation. The target object's identification information may include, but is not limited to, the target object's ID (identification), such as the last four digits of the target object's identification number, the target object's corresponding address information, etc. The third-party service platform may be an online or offline institution providing payment services corresponding to the task type of the payment task. For example, if the task type of the payment task is electricity bill, the third-party service platform corresponding to this task type may be the State Grid online business hall. The identification information of the third-party service platform may include the third-party service platform's signature, ID, etc.

[0123] In this application embodiment, the paid tasks of the target object can be tasks corresponding to all payment operations performed by the target object before executing the task to be paid, or tasks corresponding to all payment operations performed by the target object within a preset time period before executing the task to be paid, as determined according to actual needs. This application does not impose any restrictions on this. In practical applications, at least one paid task of the target object can be obtained by acquiring the payment records of the target object within the preset time period. Specifically, the preset time period and the number of paid tasks can be determined according to actual needs. In this application, tasks to be paid and paid tasks can be collectively referred to as payment tasks.

[0124] In this embodiment, the payment request for a task to be paid for a target object can be initiated by the terminal corresponding to the target object, or by a third-party service platform corresponding to the task type of the task to be paid for; this application does not impose any restrictions on this. The payment request can take the form of an instruction, a URL, etc., for example, it can be https.API. When the payment request is initiated, the corresponding payment interface is triggered and generates corresponding interface parameters. This application does not restrict the form of the payment interface; for example, it can be an API interface. After receiving the payment request for the task to be paid for a target object, the payment interface can generate interface parameters based on the received payment request, and the initiating entity of the payment request can be determined based on these interface parameters.

[0125] Figures 4a to 4f This diagram illustrates the process of initiating a payment request for a task awaiting payment. (The diagram shows the process of initiating a payment request for a task awaiting payment.) Figure 4a , Figure 4b , Figure 4c as well as Figure 4d This diagram illustrates a payment request initiated by the terminal corresponding to the target object of the task to be paid. Figure 4a , Figure 4b , Figure 4c , Figure 4e as well as Figure 4f This diagram illustrates a payment request initiated by a third-party service platform corresponding to the task type of the task to be paid.

[0126] The task type for pending payment tasks is targeted at a specific object (i.e.) Figure 4a Taking the electricity bill of "User 1" (i.e., the task type of the aforementioned payment task) as an example, if the data processing method is executed by a mini-program in an application on the terminal corresponding to the target object, such as... Figure 4a As shown, you can access the payment interface by opening the application, selecting "Payment" within the application, and then proceeding to the payment screen (e.g.).Figure 4b (As shown). In this "Payment" interface, select "Utility Payment" to access the mini-program used to perform the above data processing methods (such as...). Figure 4c As shown), through Figure 4c In the mini-program interface shown, selecting "Electricity Fee" will display the payment task content corresponding to "Electricity Fee," such as... Figure 4d As shown, the payment task corresponding to "electricity fee" specifically includes: the identification information of the third-party service platform, the identification information of the target object corresponding to the payment task, and the quantity of payment resources for the payment task. Among these, the identification information of the third-party service platform corresponding to the payment task is... Figure 4d The "electricity fee opq" shown; the identification information of the target object corresponding to this payment task, that is, in Figure 4d The input is the "payment account number mnl" associated with the target object; the quantity of payment resources corresponding to this payment task, i.e., in... Figure 4d "Enter the payment amount wh". After completing the above input, click "OK" to generate a payment request initiated by the terminal corresponding to the target object of the payment task.

[0127] In addition, such as Figure 4c As shown, after clicking "Automatic Payment", you can enter... Figure 4e The displayed interface is shown below. Figure 4e In the displayed interface, you can access the service by selecting the item related to "electricity bill" and clicking "activate". Figure 4f The displayed interface is shown below. Figure 4f In the displayed interface, after confirming the details of the payment task corresponding to "Electricity Fee," namely "Payment Account Number mnl," "Electricity Fee opq," "Payment Method r," "Payment Frequency f (i.e., the payment frequency of the aforementioned payment task)," and "Payment Amount wh," and clicking "Agree to Sign Payment Agreement," the signing of the payment agreement for the "Electricity Fee" task type between the target party and the third-party service platform is completed. After completing this signing operation, the third-party service platform can generate a payment request initiated by the third-party service platform for the "Electricity Fee" task with a payment amount of wh, based on the payment frequency f in the payment agreement and at the payment time corresponding to that payment frequency f.

[0128] Regardless of who initiates the payment request (i.e., whether the request is initiated by the terminal corresponding to the target object or by a third-party service platform corresponding to the task type of the payment task), upon receiving the payment request, authorization verification can be performed on the initiating entity to ensure payment security. Specifically, the initiating entity of the payment request can be determined through the interface parameters of the payment interface corresponding to the payment request. The authorization verification can be performed on the initiating entity of the payment request in the following ways:

[0129] If the initiator of the payment request is determined to be the target object through the interface parameters of the payment interface, the target object's permissions can be verified through its identity information (e.g., nickname, ID number, etc.) and login information. If the target object's identity information and login information indicate that it has subscribed to a task type corresponding to the task to be paid for, it can be determined that the target object possesses the corresponding permissions.

[0130] If the interface parameters of the payment interface determine that the initiator of the payment request is a third-party service platform, the platform's permissions can be verified through its identification information (e.g., its signature) and whether it has signed a payment agreement with the target object corresponding to the payment request. If it is determined that the third-party service platform has signed a payment agreement with the target object corresponding to the payment request, and its identification information matches the identification information of the third-party service platform corresponding to the task type of the task to be paid, then the third-party service platform can be deemed to have the corresponding permissions.

[0131] Optionally, the task characteristics of a payment task include, but are not limited to, the task type (pay_type), the payment time (pay_time), the payment frequency (pay_frequency), the amount of payment resources (payment), and the identification information of the initiating entity (uin, where the identification information of the initiating entity can be used to represent either the identification information of the target object corresponding to the payment task or the identification information of the third-party service platform corresponding to the task type of the payment task).

[0132] The task type of the payment task can be determined based on the attributes of the specific payment content, including but not limited to any one of the following: utility bill payments (e.g., water, electricity, gas, cable TV fees, etc.) and communication bill payments (e.g., broadband fees, call fees, data fees, etc.). The payment frequency of the payment task can be determined based on the payment task and the number of times the target object has made payments within a set time period prior to the payment task. The number of times payments have been made can include the payment count of all paid tasks of any type, or the payment count of paid tasks of the same type as the payment task. This application does not impose any restrictions on this. For example, if within one month prior to the payment task, the target object made two payments for all paid tasks of the same type as the payment task, then the payment frequency of the payment task is three times per month.

[0133] The quantity of payment resources for a payment task can be, for example, the payment amount or other equivalent exchange of payment content. It is understood that the quantity of payment resources for a payment task can be either the quantity of prepaid payment resources (i.e., prepaid fees) or the quantity of unpaid payment resources (i.e., unpaid fees), and this application does not impose any restrictions on this.

[0134] Based on the above, the payable tasks for the target object can be, for example, a company's electricity bill of 3,000 yuan or a user's data traffic fee of 150 yuan.

[0135] In one optional implementation, in response to a payment request for a task to be paid for a target object, the task to be paid can be input into a trained multi-class aggregation model to obtain the task features of the task to be paid. Optionally, the multi-class aggregation model (demo) can be obtained by ensemble of at least one classification model selected from GBDT (Gradient Boosting Decision Tree), XGB (eXtreme Gradient Boosting), LGBM (light Gradient Boosting Machine), Random Forest, etc., where each classification model in the aggregation model is used to determine different task features of the task to be paid. Specifically, the types and number of classification models ensembled in the multi-class aggregation model can be selected according to the types of task features to be determined.

[0136] In this implementation, the multi-class aggregation model can be trained in the following way:

[0137] Obtain a first training set, which contains multiple first training samples. Each first training sample includes a first sample task and the real task features of the first sample task, wherein the first sample task is any one of the multiple paid tasks of the target object.

[0138] Each first sample task is sequentially input into the initial multi-class aggregation model to obtain the predicted task features of each first sample task;

[0139] Based on the predicted task features of each first sample task and the actual task features of the first sample task, the loss value of each classification model in the initial multi-class aggregation model is determined.

[0140] Based on the loss value of each classification model in the initial multi-class aggregation model, calculate the total loss value of the initial multi-class aggregation model;

[0141] If the total loss value of the initial multi-class aggregation model meets the first training termination condition, the training ends, and the trained multi-class aggregation model is obtained.

[0142] If the total loss value of the initial multi-class aggregation model does not meet the first training termination condition, the model parameters of the initial multi-class aggregation model are adjusted, and the adjusted initial multi-class aggregation model is trained again based on the first training set.

[0143] Optionally, the first training termination condition can be configured according to requirements, and may include, but is not limited to, the convergence of the loss function corresponding to the initial multi-class aggregation model, the total loss value of the initial multi-class aggregation model being less than a set value, or the number of training iterations reaching a set number. The smaller the set value, the higher the accuracy of the trained multi-class aggregation model. The loss value for each classification model in the initial multi-class aggregation model can be determined based on parameters such as the AUC value (Area Under Curve, ROC curve) and the F1 score (F1 score, including precision, recall, etc.).

[0144] Understandably, before inputting each first sample task into the initial multi-class aggregation model, preprocessing operations can be performed on each first sample task to improve the accuracy and precision of subsequent data processing. These preprocessing operations can include, but are not limited to, data cleaning and PCA (principal component analysis).

[0145] Optionally, the association between the task characteristics of the task to be paid and the paid tasks of the target object can be determined based on the task characteristics of the task to be paid and the task characteristics of each paid task of the target object.

[0146] It is understandable that the possibility of duplicate payment for a pending task can include both the possibility that the pending task is subject to duplicate payment and the possibility that the pending task is not subject to duplicate payment.

[0147] In this implementation, if it is determined that there is no possibility of duplicate payment for the task to be paid, the payment operation for the task to be paid is executed directly.

[0148] If it is determined that there is a possibility of duplicate payment for the pending payment task, the payment operation for the payment request for the pending payment task can be blocked based on the task level of the task type.

[0149] In this application, the correspondence between task types and task levels for payment tasks can be established based on the impact of the time taken to complete a payment operation on the target object. Specifically, if the longer the payment operation takes to complete a certain payment task, the greater the impact on the target object, a higher task level can be assigned to that payment task type. For example, the task level corresponding to the first level can be set higher than the task level corresponding to the second level.

[0150] As a concrete example, for certain types of payment tasks, failure to pay on time can have an immediate impact on the target object. For instance, electricity bills and mobile phone bills, if not recharged promptly, may immediately cause a power outage in the target object's location, prevent normal communication with other objects, and have a significant impact on the target object. For example, if the target object is a factory, it could cause the entire production line to shut down, or even result in irreparable losses. Therefore, for payment tasks like those involving electricity bills and mobile phone bills, where the time spent completing the payment operation has a significant impact on the target object, the corresponding task level can be set to Level 1.

[0151] With the development of multimedia technology, more and more ways to watch videos have emerged, such as watching videos through internet TV, applications installed on user terminals, or mini-programs within applications. In other words, if the payment task corresponding to internet TV is not paid on time for a long period of time (e.g., within a month), the video can be watched through any other optional method. Therefore, the task type corresponding to this payment task, which takes almost no time to complete the payment operation, such as internet TV fees, can be defined as the third level.

[0152] Based on the above, the task type corresponding to the payment task that falls between the first and third levels and whose time spent completing the payment operation has a relatively small impact on the target object can be determined as the second level. For example, for water bill payment, if the water bill is not paid in time in the short term (e.g., within 3 days), it will not have a significant impact.

[0153] Optionally, a pre-defined correspondence between task types and task levels can be stored in any memory in the form of, for example, a database. When the task type of a task to be paid is obtained, the task level corresponding to that task type is determined by reading the pre-defined correspondence stored in the memory. It is understood that this application does not limit the storage format of the pre-defined correspondence between task types and task levels, nor the type of memory.

[0154] Optionally, determining the likelihood of duplicate payment for a task based on the correlation between the task characteristics of the task to be paid and the already paid tasks of the target object may include:

[0155] The task features of the task to be paid are input into the pre-trained duplicate payment determination module to determine the probability of duplicate payment for the task to be paid. The duplicate payment determination module is used to extract the correlation between the task features of the task to be paid and the task features of the already paid tasks.

[0156] The duplicate payment determination module is pre-trained based on already paid tasks as training samples.

[0157] Since the duplicate payment determination module is trained based on already paid tasks as training samples, and this module can be used to extract the correlation between the task features of the task to be paid and the features of already paid tasks, by inputting the task features of the task to be paid into the trained duplicate payment determination module, the probability of duplicate payment for the task to be paid can be quickly determined. This is beneficial for determining the next step of the payment request for the task to be paid based on the probability of duplicate payment.

[0158] Optionally, the duplicate payment determination module can be trained in the following way:

[0159] Obtain the training dataset, which contains multiple training samples. Each training sample includes a sample task and a label for that sample task. The label includes whether the sample task is a duplicate payment. The sample task is any one of multiple paid tasks.

[0160] Each sample task is input into the initial neural network model in sequence to obtain the probability of duplicate payment for each sample task;

[0161] Based on the probability of repeated payments and the labeling of each sample task, the loss of the initial neural network model is determined;

[0162] If the loss meets the preset training termination condition, the training ends, and the duplicate payment determination module is obtained;

[0163] If the loss does not meet the preset training termination condition, the model parameters of the initial neural network model are adjusted, and the adjusted initial neural network model is trained again based on the training dataset.

[0164] Optionally, the preset training termination condition can be configured according to requirements, and may include, but is not limited to, the convergence of the loss function corresponding to the initial neural network model, the loss of the initial neural network model being less than a set value, or the number of training iterations reaching a set number. The smaller the set value, the higher the accuracy of the duplicate payment determination module.

[0165] Understandably, preprocessing operations can be performed on each sample task before sequentially inputting it into the initial neural network model to improve the accuracy and precision of subsequent data processing. These preprocessing operations include, but are not limited to, data cleaning and PCA.

[0166] Since different target groups have different consumption habits, their paid tasks will also be different. Based on this, the recurring payment determination module can be trained in the above way to determine the recurring payment determination module for different target groups in a personalized way. This way, when a payment request for a task to be paid for a target group is received, the recurring payment determination module corresponding to the target group can accurately determine the recurring payment probability of the task to be paid for the target group.

[0167] In this implementation, a duplicate payment determination module corresponding to each target object can be pre-trained based on the paid tasks of different target objects. When training the duplicate payment determination module for each target object, the number of training samples included in the training dataset can be determined according to actual needs. Optionally, the multiple sample tasks in the training dataset can be all paid tasks within a preset time period, or a subset of paid tasks selected based on the task characteristics of all paid tasks within the preset time period.

[0168] Optionally, the initial neural network model mentioned above can be a model based on a convolutional neural network, including but not limited to neural network models based on CNN (Convolutional Neural Network), RNN (Recurrent Neural Network), S-ANN (Self-Attention Neural Network), and other model structures.

[0169] By inputting each sample task into the initial neural network model, the output of the initial neural network model can be either whether the sample task involves duplicate payments or not. Alternatively, the output of the initial neural network model can be the confidence level for the sample task corresponding to the presence or absence of duplicate payments, thereby determining whether the sample task involves duplicate payments based on these confidence levels. This application does not limit the output format of the initial neural network model.

[0170] Optionally, if the output of the initial neural network model is a confidence level indicating the presence of duplicate payments and a confidence level indicating the absence of duplicate payments for the sample task, the larger of the confidence level indicating the presence of duplicate payments and the confidence level indicating the absence of duplicate payments can be determined, and the presence of duplicate payments for the sample task can be determined based on this larger value. For example, if the confidence level indicating the presence of duplicate payments for the sample task is greater than the confidence level indicating the absence of duplicate payments, it can be determined that duplicate payments exist for the sample task.

[0171] The presence of duplicate payments in a sample task can also be determined by setting a confidence threshold for the existence of duplicate payments or a confidence threshold for the absence of duplicate payments. Optionally, if the output confidence threshold for the existence of duplicate payments is greater than or equal to the confidence threshold for the existence of duplicate payments, the sample task is determined to have duplicate payments. If the output confidence threshold for the absence of duplicate payments is greater than or equal to the confidence threshold for the absence of duplicate payments, the sample task is determined not to have duplicate payments. This application does not impose any restrictions on this. The confidence thresholds for the existence of duplicate payments and the confidence thresholds for the absence of duplicate payments can be configured according to actual needs (e.g., empirical or experimental values), and this application does not impose any restrictions on this. They can be the same or different. For example, the confidence threshold for the existence of duplicate payments can be set to 0.85, and the confidence threshold for the absence of duplicate payments can be set to 0.9.

[0172] Through the above training method, an accurate duplicate payment determination module can be obtained, which enables the accurate determination of the probability of duplicate payment of the target object's pending payment task when a payment request for the pending payment task is received, based on the duplicate payment determination module corresponding to the target object.

[0173] Optionally, based on the relationship between the task characteristics of the task to be paid and the already paid tasks of the target object, the probability of duplicate payment for the task to be paid is determined, including:

[0174] Determine the behavioral characteristics of the target object based on the paid tasks;

[0175] Based on the task characteristics of the task to be paid and the behavioral characteristics of the target object, determine whether the task characteristics of the task to be paid match the behavioral characteristics of the target object;

[0176] If the task characteristics of the pending payment task match the behavioral characteristics of the target object, the possibility of duplicate payment is determined as the pending payment task has duplicate payment.

[0177] If the task characteristics of the task to be paid do not match the behavioral characteristics of the target object, the probability of duplicate payment is determined to be that the task to be paid does not have duplicate payment.

[0178] In this implementation, the behavioral characteristics of the target object may include, but are not limited to, the target object's consumption type, at least one historical task type included in the target object's paid tasks, the historical payment frequency and the amount of historical payment resources for each historical task type, and the specific application scenario in which the target object is located. The target object's consumption type can be determined based on the number of paid tasks within a specific time period and a preset frequency threshold, including frequent consumption or occasional consumption. For example, taking a specific time period of one month (e.g., May 2019) and a preset frequency threshold of 50, if the target object has 78 paid tasks in May 2019, which is greater than the preset frequency threshold, then the target object's consumption type can be determined to be frequent consumption. At least one historical task type refers to the set of task types corresponding to all paid tasks of the target object. The specific application scenario in which the target object is located may include, but is not limited to, offline shopping mall promotions, e-commerce activities, live-streaming sales, and other application scenarios.

[0179] In this implementation, the task characteristics of the task to be paid can be determined to match the behavioral characteristics of the target object if one or more of the following conditions are met:

[0180] The task type of the task to be paid belongs to any historical task type;

[0181] The payment frequency of pending payment tasks matches the preset payment frequency range;

[0182] The amount of payment resources for the pending payment tasks matches the preset range of payment resource amounts.

[0183] In the above conditions, the payment frequency of the task to be paid matches the preset payment frequency range, that is, the payment frequency of the task to be paid is within the preset payment frequency range. Optionally, the preset payment frequency range [a, b] can be determined based on the historical payment frequency corresponding to the historical task type that is the same as the task to be paid in the target object's paid tasks. The specific values ​​of a and b can be set according to actual needs, and this application does not impose any restrictions on this. It is understood that the closer the values ​​of a and b are to the determined historical payment frequency, the higher the matching degree between the task characteristics of the task to be paid and the behavioral characteristics of the target object. For example, if the historical payment frequency corresponding to the historical task type that is the same as the task to be paid in the target object's paid tasks is 5 times / month, the preset payment frequency range [a, b] can be determined as [3, 7], that is, a is 3 times / month and b is 7 times / month.

[0184] Similarly, the amount of payment resources for the task to be paid matches the preset range of payment resources. That is, the amount of payment resources for the task to be paid is within the preset range. Optionally, the preset range [c, d] can be determined based on the historical payment resources corresponding to historical task types with the same task type as the task to be paid in the target object's paid tasks. The specific values ​​of c and d can be set according to actual needs, and this application does not impose any restrictions on this. It is understood that the closer the values ​​of c and d are to the determined historical payment resources, the higher the matching degree between the task characteristics of the task to be paid and the behavioral characteristics of the target object. For example, if the historical payment resources corresponding to historical task types with the same task type as the task to be paid in the target object's paid tasks are 3000 yuan / month, the preset payment frequency range [c, d] can be determined as [2800, 3500], that is, c is 2800 yuan / month and d is 3500 yuan / month.

[0185] Understandably, the more conditions are set to determine whether the task characteristics of the task to be paid match the behavioral characteristics of the target object, the higher the degree of matching between the task characteristics of the task to be paid and the behavioral characteristics of the target object, provided that both the task characteristics of the task to be paid and the behavioral characteristics of the target object meet the set conditions.

[0186] By using the method described above, which determines whether the characteristics of the task to be paid match the behavioral characteristics of the target object, the likelihood of duplicate payment for the target object's task to be paid can be accurately determined.

[0187] With societal development, a large number of paid tasks may be generated within a specific timeframe, resulting in sudden surges in the number of paid tasks, such as during Singles' Day or shopping mall discount events. Therefore, the aforementioned method for determining the likelihood of duplicate payments for pending tasks may not accurately pinpoint this possibility. To address this, this application provides the following optional implementation methods to assist the aforementioned method in more accurately determining the likelihood of duplicate payments for pending tasks. Specifically, the likelihood of duplicate payments for a pending task can be determined based on the new payment frequency of the task and the amount of payment resources available for that task.

[0188] In this optional implementation, the payment frequency for each business type can be disregarded. That is, in this implementation, the new payment frequency for the task to be paid is determined based on the number of payments for all paid tasks within the second preset time period. Specifically, this optional implementation includes any one of the following methods one to three:

[0189] Method 1: If the new payment frequency of the pending payment task is within the first frequency range, and there is a paid task with the same number of payment resources as the pending payment task within the first historical specified time period, it is determined that the pending payment task has duplicate payments. Otherwise, it is determined that the pending payment task does not have duplicate payments.

[0190] The first frequency interval and the first historical time period can be configured according to actual needs (such as empirical or experimental values), and this application does not impose any restrictions on them. For example, the first frequency interval can be set to 2-3 times / month, and the first historical time period to 1 month. This implementation can also be understood as follows: if there are 1-2 paid tasks within a month, and one of the paid tasks has the same number of payment resources as the pending task, then it can be determined that the pending task involves duplicate payment.

[0191] Method 2: If the new payment frequency of the pending payment task falls within the second frequency range, and there is a paid task with the same number of payment resources as the pending payment task within the second specified historical time period, then it is determined that the pending payment task involves duplicate payment. Otherwise, it is determined that the pending payment task does not involve duplicate payment.

[0192] The second frequency interval and the second historical time period can be configured according to actual needs (such as empirical or experimental values), and this application does not impose any restrictions on them. For example, the first frequency interval can be set to 2-3 times / 4 days, and the second historical time period to 4 days. This implementation can also be understood as follows: if there are 1-2 paid tasks within 4 days, and one of these paid tasks has the same number of payment resources as the pending payment task, then it can be determined that the pending payment task involves duplicate payment.

[0193] Method 3: If the new payment frequency of the pending payment task falls within the third frequency range, it is determined that the pending payment task involves duplicate payments. Otherwise, it is determined that the pending payment task does not involve duplicate payments.

[0194] The third frequency range can be configured according to actual needs (e.g., empirical or experimental values), and this application does not impose any restrictions on it. For example, the third frequency range can be set to 2-3 times per month, and the third historical time period to 1 month. This implementation can also be understood as follows: if there are 1-2 paid tasks within a month, it can be determined that the pending task has been paid repeatedly.

[0195] It is understandable that the first frequency range and the second frequency range should be different frequency ranges. The first frequency range and the third frequency range can be the same or different. The second frequency range and the third frequency range can be the same or different.

[0196] When the first frequency interval is set to be smaller than the second frequency interval, and the second frequency interval is smaller than the third frequency interval, the anti-duplicate payment methods of the above-mentioned methods one to three have progressively higher levels of anti-duplicate payment effectiveness. Therefore, method one can be defined as a light anti-duplicate payment method, method two as a medium anti-duplicate payment method, method three as a heavy anti-duplicate payment method, and the method of "determining the probability of duplicate payment for a task based on the correlation between the task characteristics of the task to be paid and the already paid tasks of the target object" can be defined as an intelligent anti-duplicate payment method.

[0197] By employing the above methods, in the event of a sudden surge in traffic to a paid task, the likelihood of duplicate payments for an pending task can be accurately determined. Corresponding actions can then be taken based on this likelihood, effectively preventing duplicate payments, avoiding duplicate payments for pending tasks, improving the processing efficiency of payment requests for pending tasks, ensuring the payment security of the target recipient, and better meeting practical needs.

[0198] Optionally, based on the task level of the task type to be paid, determine whether to block the payment operation for the payment request for the task to be paid, including:

[0199] If the task type of the task to be paid is at the first level, execute the payment operation for the task to be paid.

[0200] If the task type of the task to be paid is not at the first level, intercept and execute the payment operation for the task to be paid.

[0201] Among them, the payment priority of the tasks corresponding to the first level is higher than that of the tasks not corresponding to the first level.

[0202] As described above, the higher the task level of the task type to be paid, the longer the payment operation takes to complete the corresponding payment task, and the greater the impact on the target object. The task level corresponding to the first level is higher than that corresponding to the second level.

[0203] To address this, the aforementioned method for handling payment requests for pending tasks prioritizes tasks at the first-level payment category over those at other levels. Considering the impact of payment processing time on the target object, even in cases of duplicate payments, for tasks at the first-level, payment is executed first to prevent unnecessary losses due to delays. For tasks at other levels, payment operations are blocked (i.e., payment is intercepted), effectively preventing duplicate payments and ensuring payment security for the target object.

[0204] As an optional implementation, if the amount of payment resources for the task to be paid is less than or equal to a set value, such as 30 yuan, and if it is determined that there is a possibility of duplicate payment for the task, the payment operation for that task can be executed directly. Of course, to further ensure the payment security of the target, the payment request for the task to be paid can also be processed accordingly based on the task level of the task type, as described above.

[0205] Understandably, if the task type of the task to be paid is determined to be at the first level, an alarm can be generated based on the task to be paid, and this alarm can be sent to the third-party service platform corresponding to the task type to remind the operators of the third-party service platform to review whether the task to be paid is a duplicate payment task. This application does not restrict the specific form of the alarm; for example, the alarm can be a report, an audio message, etc.

[0206] In this embodiment of the application, when the task level of the task to be paid is determined to be the first level, the execution order of the steps to generate the alarm prompt and to perform the payment operation for the task to be paid is not limited, and the steps to generate the alarm prompt and to perform the payment operation for the task to be paid can be performed simultaneously.

[0207] Optionally, after performing a payment operation for the task to be paid, the method further includes:

[0208] Obtain evaluation information on the execution results of tasks awaiting payment;

[0209] If the assessment information determines that the task to be paid is a duplicate task, then the amount of payment resources for the task to be paid will be refunded.

[0210] Optionally, if the evaluation information of the execution result of the pending payment task determines that the pending payment task is not a duplicate payment task, the processing operation for the pending payment task is terminated.

[0211] In this implementation, the execution result of the pending payment task can include any one of the following: the payment operation for the pending payment task has been completed and the payment has been successful, or the payment operation for the pending payment task has been completed but the payment has failed. Specifically, the execution result of the pending payment task can be determined based on the receipt information generated by the payment operation for the pending payment task. This receipt information can be a serial number. By reading the identifier information at a first preset position in the serial number, the execution result of the pending payment task can be determined. The number of digits at the first preset position can be one or more, and this application does not impose any restrictions on this. For example, the number of digits at the first preset position can be set to one. If the identifier information at the first preset position is 1, the execution result of the pending payment task is determined to be that the payment operation for the pending payment task has been completed and the payment has been successful. If the serial number is garbled, the serial number cannot be obtained, or the identifier information at the first preset position is 0, the execution result of the pending payment task is determined to be that the payment operation for the pending payment task has been completed but the payment has failed.

[0212] If the execution result of a pending payment task indicates that the payment operation for that task has been completed and the payment has been successful, the evaluation information for the execution result of the pending payment task may include whether the pending payment task is a duplicate payment task. If the execution result of a pending payment task indicates that the payment operation for that task has been completed but the payment has failed, the evaluation information for the execution result of the pending payment task may include the reason for the payment failure.

[0213] Specifically, when the evaluation information of the execution result of the pending payment task is determined by the serial number corresponding to the pending payment task, the evaluation information of the execution result of the pending payment task can be determined by comparing the identifier information of the second preset position in the serial number corresponding to the pending payment task with the identifier information of the second preset position in the serial number corresponding to the paid task of the target object. For example, if the identifier information of the second preset position in the serial number corresponding to the pending payment task is the same as the identifier information of the second preset position in the serial number corresponding to the paid task of the target object, the evaluation information of the execution result of the pending payment task is determined to be that the pending payment task is a duplicate payment task. It is understood that the number of digits in the second preset position can be one or more, and this application does not limit this. If the serial number corresponding to the pending payment task is garbled or cannot be obtained, the evaluation information of the execution result of the pending payment task can be determined to be that the reason for the payment failure of the pending payment task may be network interruption or poor network, etc.

[0214] When obtaining evaluation information about the execution result of the pending payment task manually, for example, after the third-party service platform account corresponding to the task type receives the payment resources for the pending payment task, a notification message can be sent to the operator of that third-party service platform to confirm that the pending payment task is a duplicate payment task. Specific confirmation methods may include, but are not limited to, following up with the target object of the pending payment task through methods such as telephone communication to confirm whether the target object has performed multiple payment operations for the pending payment task.

[0215] Understandably, if there are multiple pending payment tasks, the execution results of each pending payment task can be added to the evaluation list in sequence according to the time of the payment operation of each pending payment task. This way, after the evaluation operation of the execution results of the payment tasks that are ranked ahead of the current pending payment task in the evaluation list is completed, the execution result of the pending payment task can be evaluated to determine the evaluation information of the execution result of the pending payment task.

[0216] Furthermore, if the task type of the pending task is at the first level and the amount of payment resources for that pending task exceeds a preset threshold, the priority for evaluating the payment result of that pending task can be set to be higher than the priority for evaluating the payment result of other payment tasks. That is, after completing the current evaluation operation in the evaluation list, the execution result of that pending task is evaluated first, and then the evaluation operations for the execution results of the pending tasks listed before the current pending task are executed. This allows for the prompt execution of a refund operation for the amount of payment resources for a pending task when the amount of payment resources exceeds the preset threshold and the pending task is a duplicate payment task, maximizing the payment security of the target recipient.

[0217] In this implementation, if the assessment information determines that the task to be paid is a duplicate payment task, the payment resources for the task to be paid can be returned to the payment account corresponding to the target object according to the pre-configured payment account corresponding to the target object.

[0218] By obtaining the evaluation information of the execution result of the pending payment task after the payment operation is performed, and further determining whether the pending payment task is a duplicate payment task based on the evaluation information, the amount of payment resources that have been duplicated can be refunded after the payment operation is completed and in the event that duplicate payment actually occurs, thus ensuring the payment security of the target object.

[0219] Optionally, after intercepting the payment operation for the task to be paid, the method may further include:

[0220] If the task type of the task to be paid is at the second level, generate a first prompt message based on the task to be paid and send the first prompt message to the terminal corresponding to the target object;

[0221] In response to a first feedback message received from the target object regarding the first prompt message, it is determined whether to perform a payment operation for the pending payment task, wherein the first feedback message is used to indicate whether to perform a payment operation for the pending payment task.

[0222] In this implementation, the first prompt information can take various forms, such as text, voice, text plus voice, animation, etc., and this application does not impose any restrictions on this. The specific content of the first prompt information can be "Is the task to be paid a duplicate payment task?". As an example, "Is the task to be paid a duplicate payment task?" can be displayed on the display interface of the terminal corresponding to the target object, and two trigger buttons, "Yes" and "No", can be provided. By triggering the trigger button corresponding to "Yes" or "No", the aforementioned first feedback information can be generated. For example, if the trigger button "Yes" is triggered, it can be determined that the first feedback information is used to indicate that the task to be paid is a duplicate payment task, and no payment operation is required for the task to be paid. If the trigger button "No" is triggered, it can be determined that the first feedback information is used to indicate that the task to be paid is not a duplicate payment task, and a payment operation is required for the task to be paid.

[0223] According to the above description, the task type of payment task that falls between the first and third levels and whose time spent completing the payment operation has a relatively small impact on the target object is the second level. If the payment operation for this type of payment task is not executed in the short term, it will not affect the target object.

[0224] Based on this, when the task type of the task to be paid is at the second level, considering that the impact of not performing the payment operation on the task to be paid in the short term should be minimized, that is, the real-time completion of the payment operation should be ensured, the first prompt information generated according to the payment task can be sent to the terminal corresponding to the target object, so as to quickly determine the processing operation for the task to be paid based on the first feedback information from the target object regarding the first prompt information.

[0225] If, based on the first feedback information, it is determined that a payment operation for the pending payment task can be executed, then the payment operation for the pending payment task is executed immediately. If, based on the first feedback information, it is determined that a payment operation for the pending payment task should not be executed, then the payment operation for the pending payment task is not executed, and the processing operation for that pending payment task is terminated.

[0226] This method effectively prevents duplicate payments, avoids duplicate payments for pending tasks, ensures payment security for the target, and minimizes the impact on users from not performing payment operations on pending tasks in the short term, thus better meeting practical needs.

[0227] It is understandable that, through this method, if it is determined that a payment operation will be performed for the task to be paid, the evaluation information of the execution result of the task to be paid can be obtained through the method described above after the payment operation is performed, and the corresponding operation can be performed based on the evaluation information, which will not be elaborated here.

[0228] Of course, to improve the immediacy of payment operations for pending tasks, payment operations can also be directly executed for pending tasks of the second level. Furthermore, in conjunction with the related operations following the execution of payment operations for pending tasks, a refund operation can be performed on the amount of payment resources for pending tasks that are duplicate payment tasks; this application does not impose any restrictions on this.

[0229] Optionally, after intercepting the payment operation for the task to be paid, the method may further include:

[0230] If the task type of the task to be paid is at level three, generate a second prompt message based on the task to be paid and send the second prompt message to the third-party service platform corresponding to the task type.

[0231] In response to the second feedback information received from the third-party service platform regarding the second prompt information, determine whether the task to be paid is a duplicate payment task;

[0232] If it is determined that the task to be paid is not a duplicate payment task, execute the payment operation for the task to be paid.

[0233] In this implementation, the second prompt message can take various forms, such as text, voice, text plus voice, animation, etc., and this application does not impose any restrictions on this. The content of the second prompt message can be "Whether to execute the payment task". It is understood that the second prompt message can be the same as the first prompt message.

[0234] As described above, the third level refers to the task level corresponding to a payment task type where the time spent completing the payment operation has almost no impact on the target recipient. Since third-party service platforms typically handle payment-related or unrelated tasks from different target recipients, while the immediacy of task processing through a third-party service platform may not be very high, it minimizes interaction with the user and improves the user experience. Based on this, a second prompt message generated according to the payment task can be sent to the third-party service platform corresponding to the task type. The second feedback message from the third-party service platform regarding this second prompt message can then determine whether the payment operation for the task still needs to be executed.

[0235] If, based on the second feedback information, it is determined that a payment operation for the pending payment task can be performed, then the payment operation for the pending payment task is performed. If, based on the second feedback information, it is determined that a payment operation for the pending payment task should not be performed, then the payment operation for the pending payment task is not performed, and the processing operation for that pending payment task is terminated.

[0236] This method effectively prevents duplicate payments, avoids duplicate payments for payment tasks, ensures the payment security of the target, minimizes user interaction, improves user experience, and better meets practical needs.

[0237] It is understandable that, through this method, if it is determined that a payment operation will be performed for the task to be paid, the evaluation information of the execution result of the task to be paid can be obtained through the method described above after the payment operation is performed, and the corresponding operation can be performed based on the evaluation information, which will not be elaborated here.

[0238] Of course, to improve the immediacy of payment operations for pending tasks, payment operations can be directly executed for pending tasks of the second level, or a first prompt message can be sent to the target object, and the processing operation for the pending task can be determined based on the first feedback message to that first prompt message. Furthermore, in conjunction with the related operations following the execution of payment operations for pending tasks, a refund operation can be performed on the amount of payment resources for pending tasks that are duplicate payment tasks; this application does not impose any restrictions on this.

[0239] Figure 5 A detailed flowchart of step S130 in an embodiment of this application is shown. Figure 5 As shown, step S130 may specifically include steps S131 to S139.

[0240] Step S131: Determine if there is duplicate payment for the pending payment task.

[0241] Step S132: Determine whether the task level of the task type to be paid is Level 1. If the task level is determined to be Level 1, proceed to step S133. If the task level is not determined to be Level 1, intercept the payment operation for the task and proceed to step S134.

[0242] Step S133: Execute the payment operation for the task to be paid.

[0243] Step S134: Determine whether the task level of the task type to be paid is Level 3. If the task level is determined to be Level 3, proceed to step S135. If the task level is determined not to be Level 3, proceed to step S138.

[0244] Step S135: Generate a second prompt message based on the task to be paid, and send the second prompt message to the third-party service platform corresponding to the task type.

[0245] Step S136: Based on the second feedback information received from the third-party service platform regarding the second prompt information, determine whether the task to be paid is a duplicate payment task. Specifically, if the second feedback information indicates that the task to be paid is a duplicate payment operation, proceed to step S137. If the second feedback information indicates that the task to be paid is a non-duplicate payment operation, proceed to step S133.

[0246] Step S137: End the processing operation for the pending payment task.

[0247] Step S138: Generate a first prompt message based on the task to be paid, and send the first prompt message to the terminal corresponding to the target object.

[0248] Step S139: Based on the first feedback information received from the target object regarding the first prompt information, determine whether to execute the payment operation for the pending payment task. Specifically, if the first feedback information indicates that the payment operation for the pending payment task should be executed, proceed to step S133. If the first feedback information indicates that the payment operation for the pending payment task should not be executed, proceed to step S137.

[0249] The data processing method in this application embodiment will be described in detail below with an example from a specific application scenario. Figure 6 A flowchart illustrating the implementation of the above method in a specific application scenario of this application is shown. In this application scenario, the above method can be implemented through an application on a terminal device or as a plugin within an application. Figure 6 As shown, the method may include the following steps:

[0250] Step 1: Receive a deduction request (i.e., a payment request for the pending payment task targeting the target entity), and verify the user (i.e., the target entity) or institution (i.e., the third-party service platform)'s permissions based on the deduction request. This deduction request can be initiated based on a user's payment inquiry or a deduction initiated by an institution.

[0251] Step 2: If the user or institution whose authorization for the deduction request has been verified, obtain the user's historical bills (i.e., the aforementioned payment records), the user's actions (i.e., the aforementioned behavioral characteristics of the target object), and business characteristics (i.e., the aforementioned task characteristics of the task to be paid). Based on the user's historical bills, user actions, and business characteristics, perform AI intelligent judgment to determine whether there is a duplicate charge (i.e., determine the probability of duplicate payment for the task to be paid based on the correlation between the task characteristics of the task to be paid and the target object's already paid tasks). If no duplicate charge is determined, proceed to Step 2.1. If a duplicate charge is determined, proceed to Step 2.2.

[0252] Step 2.1: Execute the deduction (that is, perform the payment operation for the task to be paid).

[0253] Step 2.2: Perform risk control interception (that is, determine whether to intercept the payment operation for the payment request for the task to be paid based on the task level of the task type to be paid). Specifically, Step 2.2 may include Step 2.2.1, Step 2.2.2, and Step 2.2.3.

[0254] Step 2.2.1: Interrupt the payment process. This refers to the operation performed on the payment request for the task to be paid when the task type and task level are at level three. Specifically, a second prompt message is generated based on the task to be paid, and this message is sent to the third-party service platform corresponding to the task type, so that the third-party service platform can provide second feedback information in response to the second prompt message. As mentioned above, since the third-party service platform may take a considerable amount of time to provide the second feedback information, this operation can be considered an "interruption of the payment process."

[0255] If, based on the second feedback information, it is determined that the task to be paid is not a duplicate payment task, step 2.1 can be executed. Figure 6 (Not shown in the image). If, based on the second feedback information, it is determined that the task to be paid is a duplicate payment task, the operation on the deduction request can be terminated. Figure 6 (Not shown in the image).

[0256] Step 2.2.2: Notify the user to confirm, that is, the operation performed on the payment request for the task to be paid when the task type of the task to be paid is at the second level. Specifically, a first prompt message is generated according to the task to be paid, and the first prompt message is sent to the terminal corresponding to the target object so that the target object provides a first feedback message in response to the first prompt message.

[0257] If, based on the first feedback information, it is determined that a payment operation will be performed for the task to be paid, step 2.1 can be executed. Figure 6 (Not shown in the image). If, based on the first feedback information, it is determined that no payment operation will be performed for the pending payment task, the operation on the deduction request can be terminated. Figure 6 (Not shown in the image).

[0258] Step 2.2.3: Detection and Reporting. That is, when the task type of the task to be paid is at the first level, the operation performed on the payment request for the task to be paid, after executing step 2.1, sends the information corresponding to the task to be paid to the third-party service platform to obtain the evaluation information of the execution result of the task to be paid.

[0259] Based on the above, after following steps 2.2.1, 2.2.2, and 2.2.3, and confirming that step 2.1 has been executed, evaluation information on the execution result of the task to be paid can be obtained. If the evaluation information determines that the task to be paid is a duplicate payment task, then a refund operation for the amount of payment resources for the task to be paid will be performed. Figure 6 (Not shown in the image).

[0260] This application provides a data processing apparatus. Figure 7 This is a schematic diagram of the structure of a data processing device provided in an embodiment of this application, as shown below. Figure 7 As shown, the data processing device 60 may include: a task feature determination module 601, a probability determination module 602, and a processing module 603, wherein,

[0261] The feature determination module 601 is used to determine the task features of the task to be paid in response to a payment request for a task to be paid for a target object, wherein the task features of the task to be paid include the task type of the task to be paid.

[0262] The probability determination module 602 is used to determine the probability of duplicate payment for a task based on the relationship between the task characteristics of the task to be paid and the paid tasks of the target object.

[0263] The processing module 603 is used to determine whether to block the payment operation for the payment request for the task to be paid, based on the task level of the task type, if it is determined that there is a duplicate payment for the task to be paid.

[0264] Optionally, when determining the probability of duplicate payment for a task based on the association between the task characteristics of the task to be paid and the already paid tasks of the target object, the probability determination module 602 is specifically used for:

[0265] The task features of the task to be paid are input into the pre-trained duplicate payment determination module to determine the probability of duplicate payment for the task to be paid. The duplicate payment determination module is used to extract the correlation between the task features of the task to be paid and the task features of the already paid tasks.

[0266] The duplicate payment determination module is pre-trained based on already paid tasks as training samples.

[0267] Optionally, the duplicate payment determination module is trained in the following way:

[0268] Obtain the training dataset, which contains multiple training samples. Each training sample includes a sample task and a label for that sample task. The label includes whether the sample task is a duplicate payment. The sample task is any one of multiple paid tasks.

[0269] Each sample task is input into the initial neural network model in sequence to obtain the probability of duplicate payment for each sample task;

[0270] Based on the probability of repeated payments and the labeling of each sample task, the loss of the initial neural network model is determined;

[0271] If the loss meets the preset training termination condition, the training ends, and the duplicate payment determination module is obtained;

[0272] If the loss does not meet the preset training termination condition, the model parameters of the initial neural network model are adjusted, and the adjusted initial neural network model is trained again based on the training dataset.

[0273] Optionally, when determining the probability of duplicate payment for a task based on the association between the task characteristics of the task to be paid and the already paid tasks of the target object, the probability determination module 602 is specifically used for:

[0274] Determine the behavioral characteristics of the target object based on the paid tasks;

[0275] Based on the task characteristics of the task to be paid and the behavioral characteristics of the target object, determine whether the task characteristics of the task to be paid match the behavioral characteristics of the target object;

[0276] If the task characteristics of the pending payment task match the behavioral characteristics of the target object, the possibility of duplicate payment is determined as the pending payment task has duplicate payment.

[0277] If the task characteristics of the task to be paid do not match the behavioral characteristics of the target object, the probability of duplicate payment is determined to be that the task to be paid does not have duplicate payment.

[0278] Optionally, when processing module 603 determines whether to intercept the payment operation for the payment request of the task to be paid based on the task level of the task type, it is specifically used for:

[0279] If the task type of the task to be paid is at the first level, execute the payment operation for the task to be paid.

[0280] If the task type of the task to be paid is not at the first level, intercept the payment operation for the task to be paid.

[0281] Among them, the payment priority of the tasks corresponding to the first level is higher than that of the tasks not corresponding to the first level.

[0282] Optionally, after intercepting the payment operation for the task to be paid, the processing module 603 is further configured to:

[0283] If the task type of the task to be paid is at the second level, generate a first prompt message based on the task to be paid and send the first prompt message to the terminal corresponding to the target object;

[0284] In response to a first feedback message received from the target object regarding the first prompt message, it is determined whether to perform a payment operation for the pending payment task, wherein the first feedback message is used to indicate whether to perform a payment operation for the pending payment task.

[0285] Optionally, after intercepting the payment operation for the task to be paid, the processing module 603 is further configured to:

[0286] If the task type of the task to be paid is at level three, generate a second prompt message based on the task to be paid and send the second prompt message to the third-party service platform corresponding to the task type.

[0287] In response to the second feedback information received from the third-party service platform regarding the second prompt information, determine whether the task to be paid is a duplicate payment task;

[0288] If it is determined that the task to be paid is not a duplicate payment task, execute the payment operation for the task to be paid.

[0289] Optionally, after performing the payment operation for the task to be paid, the processing module 603 is further configured to:

[0290] Obtain evaluation information on the execution results of tasks awaiting payment;

[0291] If the assessment information determines that the task to be paid is a duplicate task, then the amount of payment resources for the task to be paid will be refunded.

[0292] The apparatus in this application embodiment can execute the method provided in this application embodiment, and the implementation principle is similar. The actions performed by each module in the apparatus of each embodiment of this application correspond to the steps in the method of each embodiment of this application. For detailed functional descriptions of each module of the apparatus, please refer to the descriptions in the corresponding methods shown above, which will not be repeated here.

[0293] Based on the same principles as the data processing methods and apparatus provided in the embodiments of this application, the embodiments of this application also provide an electronic device (such as a server), which may include a memory, a processor, and a computer program stored in the memory. The processor executes the computer program to implement the steps of the method provided in any optional embodiment of this application.

[0294] Optionally, Figure 8 A schematic diagram of the structure of an electronic device to which this application embodiment applies is shown, such as... Figure 8 As shown, Figure 8 The illustrated electronic device 4000 includes a processor 4001 and a memory 4003. The processor 4001 and the memory 4003 are connected, for example, via a bus 4002. Optionally, the electronic device 4000 may further include a transceiver 4004, which can be used for data interaction between the electronic device and other electronic devices, such as sending and / or receiving data. It should be noted that in practical applications, the transceiver 4004 is not limited to one type, and the structure of the electronic device 4000 does not constitute a limitation on the embodiments of this application.

[0295] Processor 4001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 4001 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0296] Bus 4002 may include a pathway for transmitting information between the aforementioned components. Bus 4002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. Bus 4002 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 8 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0297] The memory 4003 may be ROM (Read Only Memory) or other types of static storage devices capable of storing static information and instructions, RAM (Random Access Memory) or other types of dynamic storage devices capable of storing information and instructions, or EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media, other magnetic storage devices, or any other medium capable of carrying or storing computer programs and capable of being read by a computer, without limitation herein.

[0298] The memory 4003 stores computer programs that execute embodiments of this application, and its execution is controlled by the processor 4001. The processor 4001 executes the computer programs stored in the memory 4003 to implement the steps shown in the foregoing method embodiments.

[0299] This application provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it can implement the steps and corresponding content of the aforementioned method embodiments.

[0300] This application also provides a computer program product, including a computer program that, when executed by a processor, can implement the steps and corresponding content of the aforementioned method embodiments.

[0301] The terms "first," "second," "third," "fourth," "1," "2," etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in a sequence other than that shown in the illustrations or text descriptions.

[0302] It should be understood that although arrows indicate various operation steps in the flowcharts of this application's embodiments, the order in which these steps are implemented is not limited to the order indicated by the arrows. Unless explicitly stated herein, in some implementation scenarios of this application's embodiments, the implementation steps in each flowchart can be executed in other orders as required. Furthermore, some or all steps in each flowchart, based on the actual implementation scenario, may include multiple sub-steps or multiple stages. Some or all of these sub-steps or stages can be executed at the same time, and each sub-step or stage can also be executed at different times. In scenarios where execution times differ, the execution order of these sub-steps or stages can be flexibly configured according to requirements, and this application's embodiments do not limit this.

[0303] The above description is only an optional implementation method for some implementation scenarios of this application. It should be noted that for those skilled in the art, other similar implementation methods based on the technical concept of this application without departing from the technical concept of this application also fall within the protection scope of the embodiments of this application.

Claims

1. A data processing method, characterized by, The method comprises: in response to a payment request for a to-be-paid task of a target object, inputting the to-be-paid task into a trained multi-classification aggregation model to obtain task characteristics of the to-be-paid task, wherein the task characteristics of the to-be-paid task comprise a task type of the to-be-paid task; wherein each classification model in the multi-classification aggregation model is used to determine different task characteristics of the to-be-paid task; the number and types of the classification models are determined based on the types of the task characteristics to be determined; determining a repeated payment possibility of the to-be-paid task based on an association relationship between the task characteristics of the to-be-paid task and paid tasks of the target object; if it is determined that the to-be-paid task has repeated payment, determining a target task level of the task type of the to-be-paid task according to a preset corresponding relationship between a time length consumed by a payment operation and an influence degree of the target object; wherein the preset corresponding relationship is a preset corresponding relationship between a preset task type and a preset task level, which is set according to the influence degree of the target object caused by the time length consumed by a payment operation of a preset payment task; determining whether to intercept a payment operation for the to-be-paid task according to the target task level.

2. The method of claim 1, wherein, The method comprises: inputting the task characteristics of the to-be-paid task into a trained repeated payment determination module to determine the repeated payment possibility of the to-be-paid task, wherein the repeated payment determination module is used to extract an association relationship between the task characteristics of the to-be-paid task and the task characteristics of the paid tasks; wherein the repeated payment determination module is obtained by pre-training based on the paid tasks as training samples.

3. The method of claim 2, wherein, The repeated payment determination module is obtained by the following method: obtaining a training data set, wherein the training data set comprises a plurality of training samples, each of the training samples comprises a sample task and a labeled label of the sample task, the labeled label comprises whether the sample task belongs to repeated payment, and the sample task is any one of the plurality of paid tasks; inputting each of the sample tasks into an initial neural network model in sequence to obtain a repeated payment possibility of each of the sample tasks; determining a loss of the initial neural network model based on the repeated payment possibility of each of the sample tasks and the labeled label; in the case that the loss meets a preset training end condition, ending the training to obtain the repeated payment determination module; in the case that the loss does not meet the preset training end condition, adjusting model parameters of the initial neural network model, and continuing to train the adjusted initial neural network model based on the training data set.

4. The method of claim 1, wherein, The method comprises: determining a behavior characteristic of the target object according to the paid tasks. determining whether the task feature of the to-be-paid task matches the behavior feature of the target object according to the task feature of the to-be-paid task and the behavior feature of the target object; if the task feature of the to-be-paid task matches the behavior feature of the target object, determining that the repeated payment possibility is that the to-be-paid task exists repeated payment; if the task feature of the to-be-paid task does not match the behavior feature of the target object, determining that the repeated payment possibility is that the to-be-paid task does not exist repeated payment.

5. The method of claim 1, wherein, The method further comprises: if the target task level is a first level, performing the payment operation; if the target task level is not the first level, intercepting the payment operation; The payment priority of the to-be-paid task corresponding to the first level is higher than the payment priority of the to-be-paid task corresponding to the level other than the first level.

6. The method of claim 5, wherein, After the payment operation is performed, the method further comprises: obtaining evaluation information of an execution result of the to-be-paid task; if it is determined according to the evaluation information that the to-be-paid task belongs to a repeated payment task, performing a refund operation on the number of payment resources of the to-be-paid task.

7. The method of claim 5, wherein, After the payment operation is intercepted, the method further comprises: if the target task level is a second level, generating first prompt information according to the to-be-paid task and sending the first prompt information to a terminal corresponding to the target object; in response to first feedback information of the target object for the first prompt information, determining whether to perform the payment operation, the first feedback information being used to indicate whether to perform the payment operation.

8. The method of claim 5, wherein, After the payment operation is intercepted, the method further comprises: if the target task level is a third level, generating second prompt information according to the to-be-paid task and sending the second prompt information to a third-party service platform corresponding to the task type; in response to second feedback information of the third-party service platform for the second prompt information, determining whether the to-be-paid task belongs to a repeated payment task; if it is determined that the to-be-paid task does not belong to the repeated payment task, performing the payment operation.

9. A data processing apparatus, characterized by, The device comprises: a task feature determination module, configured to input a to-be-paid task of a target object into a trained multi-classification aggregation model in response to a payment request for the to-be-paid task, to obtain a task feature of the to-be-paid task, the task feature of the to-be-paid task including a task type of the to-be-paid task; wherein each classification model in the multi-classification aggregation model is used to determine different task features of the to-be-paid task; the number and types of the classification models are determined based on the types of the task features to be determined; a repeated payment possibility determination module, configured to determine a repeated payment possibility of the to-be-paid task based on an association relationship between the task feature of the to-be-paid task and a paid task of the target object; and a payment operation determination module, configured to determine whether to intercept a payment operation for the to-be-paid task according to a target task level of the to-be-paid task. The processing module is configured to determine a target task level of the task type of the to-be-paid task according to a preset correspondence between a time length consumed by a payment operation and the target task level, if it is determined that the to-be-paid task has repeated payment; the preset correspondence is a preset correspondence between a preset task type and a preset task level, which is set according to an influence degree of a time length consumed by a payment operation for completing a preset payment task on an object corresponding to the preset payment task. The processing module is further configured to determine whether to intercept a payment operation for the to-be-paid task according to the target task level.

10. The apparatus of claim 9, wherein, In a process in which the possibility determination module determines the repeated payment possibility of the to-be-paid task based on a correlation between a task feature of the to-be-paid task and a paid task of the target object, the possibility determination module is configured to: input the task feature of the to-be-paid task into a trained repeated payment determination module to determine the repeated payment possibility of the to-be-paid task, the repeated payment determination module being configured to extract a correlation between the task feature of the to-be-paid task and a task feature of the paid task; wherein the repeated payment determination module is obtained by pre-training based on the paid task as a training sample.

11. The apparatus of claim 10, wherein, The repeated payment determination module is obtained by the following method: obtain a training data set, the training data set containing a plurality of training samples, each of the training samples including a sample task and a labeled label of the sample task, the labeled label including whether the sample task belongs to repeated payment, the sample task being any one of the plurality of paid tasks; input each of the sample tasks into an initial neural network model in sequence to obtain a repeated payment possibility of each of the sample tasks; determine a loss of the initial neural network model based on the repeated payment possibility of each of the sample tasks and the labeled label; in a case where the loss meets a preset training end condition, end the training to obtain the repeated payment determination module; in a case where the loss does not meet the preset training end condition, adjust model parameters of the initial neural network model, and continue to train the adjusted initial neural network model based on the training data set.

12. The apparatus of claim 9, wherein, In a process in which the possibility determination module determines the repeated payment possibility of the to-be-paid task based on a correlation between a task feature of the to-be-paid task and a paid task of the target object, the possibility determination module is configured to: determine a behavior feature of the target object according to the paid task; determine whether the task feature of the to-be-paid task matches the behavior feature of the target object according to the task feature of the to-be-paid task and the behavior feature of the target object; if the task feature of the to-be-paid task matches the behavior feature of the target object, determine that the repeated payment possibility is that the to-be-paid task has repeated payment; if the task feature of the to-be-paid task does not match the behavior feature of the target object, determine that the repeated payment possibility is that the to-be-paid task does not have repeated payment.

13. The apparatus of claim 9, wherein, In the method, the processing module is configured to: determine, according to the target task level, whether to intercept a payment operation for the to-be-paid task; if the target task level is a first level, execute the payment operation; if the target task level is not the first level, intercept the payment operation; and the payment priority of the to-be-paid task corresponding to the first level is higher than the payment priority of the to-be-paid task not corresponding to the first level. The processing module is further configured to: after executing the payment operation, obtain evaluation information of an execution result of the to-be-paid task; and if it is determined according to the evaluation information that the to-be-paid task belongs to a repeated payment task, perform a refund operation on a payment resource quantity of the to-be-paid task. The processing module is further configured to: if the target task level is a second level, generate first prompt information according to the to-be-paid task, and send the first prompt information to a terminal corresponding to the target object; and in response to first feedback information of the target object for the first prompt information, determine whether to execute the payment operation, the first feedback information being used to indicate whether to execute the payment operation. The processing module is further configured to: if the target task level is a third level, generate second prompt information according to the to-be-paid task, and send the second prompt information to a third-party service platform corresponding to the task type; in response to second feedback information of the third-party service platform for the second prompt information, determine whether the to-be-paid task belongs to a repeated payment task; and if it is determined that the to-be-paid task does not belong to the repeated payment task, execute the payment operation.

14. The apparatus of claim 13, wherein, The processor executes the computer program to implement the steps of the method in any one of claims 1-8. The computer program is executed by the processor to implement the steps of the method in any one of claims 1-8. The computer program is executed by the processor to implement the steps of the method in any one of claims 1-8.

15. The apparatus of claim 13, wherein, ​ ​ ​ 16. The apparatus of claim 13, wherein, ​ ​ ​ ​ 17. An electronic device comprising a memory, a processor, and a computer program stored on the memory, wherein the computer program, when executed by the processor, is arranged to perform the method of any one of claims 1 to 16. ​ 18. A computer readable storage medium having stored thereon a computer program, characterized in that, ​ 19. A computer program product comprising a computer program, characterized in that, ​

Images