Payment request processing method, device and equipment

Abstract

The embodiment of the invention provides a payment request processing method, device and equipment. The method can be used in financial or other fields. The method comprises the following steps: determining a risk attribute value according to a received payment request message, generating a risk detection request message comprising the risk attribute value, and sending the risk detection request message to a risk monitoring system; wherein the payment request message is generated by the mobile terminal according to a received payment request of a user, and the risk monitoring system is used for generating a feedback message according to the risk attribute value; determining a target processing mode of the payment request according to locally stored information related to the processing mode in response to detecting that the waiting duration of the waiting feedback message is greater than a waiting duration threshold; wherein the waiting duration threshold value is determined according to a probability density function of the waiting duration, and the probability density function of the waiting duration is determined according to the waiting duration of the historical feedback message; and processing the payment request according to the target processing mode. The method is used for achieving the effect of improving the payment efficiency.

Description

Technical Field

[0001] The present application relates to the financial field, and in particular to a payment request processing method, device and equipment. Background Art

[0002] Online payment provides users with a convenient payment method and is increasingly widely used. In various payment scenarios, such as offline shopping and online shopping, users can initiate online payments through their mobile terminals. However, online payment also has various risks, such as criminals using online payment to commit fraud and steal accounts, so it is necessary to monitor the risks of online payment requests.

[0003] In the related art, after receiving a payment request, the payment system of a bank or other financial institution sends a risk monitoring request for the online payment request to the risk monitoring system, which determines the risk of the online payment and sends risk feedback information to the payment system. The payment system determines whether to continue or terminate the payment request based on the risk feedback information.

[0004] However, due to the influence of network connection or the load of the risk monitoring system, the payment system cannot receive risk feedback information in a timely manner, resulting in the payment system being unable to process payment requests for a long time, resulting in low payment request processing efficiency and poor user experience. Summary of the invention

[0005] The embodiments of the present application provide a payment request processing method, apparatus and device to improve the processing efficiency of payment requests and improve the user experience.

[0006] In a first aspect, an embodiment of the present application provides a payment request processing method, comprising: determining a risk attribute value based on a received payment request message, generating a risk detection request message including the risk attribute value, and sending the risk detection request message to a risk monitoring system; wherein the payment request message is generated by a mobile terminal based on a payment request received from a user, and the risk monitoring system is used to generate a feedback message based on the risk attribute value, and the feedback message is used to determine a processing method for the payment request; in response to detecting that the waiting time for the feedback message is greater than a waiting time threshold, determining a target processing method for the payment request based on locally stored information related to the processing method; wherein the waiting time threshold is determined based on a probability density function of the waiting time, and wherein the probability density function of the waiting time is determined based on the waiting time of historical feedback messages; and processing the payment request according to the target processing method.

[0007] In a possible implementation manner, determining the risk attribute value according to the received payment request message includes: obtaining a preset risk attribute, and determining the risk attribute value according to the preset risk attribute and the payment request message.

[0008] In one possible implementation, the waiting time threshold is determined based on the following steps: obtaining multiple historical payment information, the historical payment information including a historical payment request message, a first moment of sending a historical risk detection request message to the risk monitoring system, and a second moment of receiving a historical feedback message sent by the risk monitoring system; determining the historical waiting time corresponding to each of the multiple historical payment information based on the first moment and the second moment of each of the multiple historical payment information; determining a probability density function of the waiting time based on the multiple historical waiting times; determining the waiting time threshold based on the probability density function of the waiting time and a preset loss probability value, wherein the loss probability value is used to indicate the probability of a feedback message being discarded.

[0009] In a possible implementation, the probability density function of determining the waiting time based on the multiple historical waiting times includes: determining a minimum value and a maximum value from the multiple historical waiting times, and determining the total number of the multiple historical waiting times; determining a first endpoint and a second endpoint based on the minimum value and the maximum value, wherein the first endpoint is less than or equal to the minimum value, and the second endpoint is greater than or equal to the maximum value; dividing the waiting time interval determined by the first endpoint and the second endpoint into a plurality of non-intersecting time sub-intervals, wherein the number of historical waiting times contained in each time sub-interval is greater than a preset number threshold; for each time sub-interval, determining the midpoint of the time sub-interval, and taking the proportion of the number of historical waiting times contained in the time sub-interval in the total number as the probability of the midpoint; performing function fitting based on the midpoints of each time sub-interval and the probabilities corresponding to the midpoints to obtain a first function; and correcting the parameters of the first function based on the integral value of the first function to obtain a probability density function of the waiting time.

[0010] In a possible implementation, the information related to the processing method includes the correspondence between transaction elements and processing methods, and determining the target processing method of the payment request based on the information related to the processing method includes: determining at least one transaction element from the payment request message; determining the target processing method based on the at least one transaction element and the correspondence between the transaction element and the processing method.

[0011] In a possible implementation manner, the locally stored information related to the processing method includes a plurality of historical payment information, wherein the historical payment information includes historical payment request messages, historical feedback messages of the risk monitoring system, and corresponding historical processing methods;

[0012] And determining the target processing method of the payment request according to the locally stored information related to the processing method includes:

[0013] Determining at least one candidate historical payment request message according to the similarity between the payment request message and the plurality of historical payment request messages;

[0014] Aggregating the historical processing methods corresponding to the at least one candidate historical payment request message to obtain the number of historical processing methods corresponding to each of the different historical processing methods;

[0015] The target processing method is determined according to the quantities corresponding to the different historical processing methods.

[0016] In a possible implementation manner, determining at least one candidate historical payment request message according to the similarity between the payment request message and the plurality of historical payment request messages includes:

[0017] The similarity between the payment request message and each of the historical request messages is determined according to the vector corresponding to the payment request message and the vectors corresponding to each of the historical request messages.

[0018] In a second aspect, an embodiment of the present application provides a payment request processing device, comprising: a generation module, configured to determine a risk attribute value based on a received payment request message, generate a risk detection request message including the risk attribute value, and send the risk detection request message to a risk monitoring system; wherein the payment request message is generated by a mobile terminal based on a payment request received from a user, and the risk monitoring system is configured to generate a feedback message based on the risk attribute value, and the feedback message is used to determine a processing method for the payment request; a determination module, configured to determine a target processing method for the payment request based on locally stored information related to the processing method in response to detecting that the waiting time for the feedback message is greater than a waiting time threshold; wherein the waiting time threshold is determined based on a probability density function of the waiting time, and wherein the probability density function of the waiting time is determined based on the waiting time of historical feedback messages; a processing module, configured to process the payment request according to the target processing method.

[0019] In a possible implementation manner, the generation module is further used to: obtain a preset risk attribute, and determine the risk attribute value according to the preset risk attribute and the payment request message.

[0020] In some embodiments, the device also includes a waiting time threshold determination module (not shown in the figure), and the waiting time threshold module is used to: obtain multiple historical payment information, the historical payment information including a historical payment request message, a first moment of sending a historical risk detection request message to the risk monitoring system, and a second moment of receiving a historical feedback message sent by the risk monitoring system; determine the historical waiting time corresponding to each of the multiple historical payment information according to the first moment and the second moment of each of the multiple historical payment information; determine the probability density function of the waiting time according to the multiple historical waiting times; determine the waiting time threshold according to the probability density function of the waiting time and a preset loss probability value, wherein the loss probability value is used to indicate the probability of the feedback message being discarded.

[0021] In some embodiments, the waiting time threshold determination module is further used to: determine a minimum value and a maximum value from the multiple historical waiting times, and determine the total number of the multiple historical waiting times; determine a first endpoint and a second endpoint according to the minimum value and the maximum value, wherein the first endpoint is less than or equal to the minimum value, and the second endpoint is greater than or equal to the maximum value; divide the waiting time interval determined by the first endpoint and the second endpoint into a plurality of non-intersecting time sub-intervals, wherein the number of historical waiting times contained in each time sub-interval is greater than a preset number threshold; for each time sub-interval, determine the midpoint of the time sub-interval, and use the proportion of the number of historical waiting times contained in the time sub-interval in the total number as the probability of the midpoint; perform function fitting based on the midpoints of each time sub-interval and the probabilities corresponding to the midpoints to obtain a first function; and modify the parameters of the first function based on the integral value of the first function to obtain a probability density function of the waiting time.

[0022] In some embodiments, the locally stored information related to the processing method includes the correspondence between transaction elements and processing methods, and the determination module is further used to: determine at least one transaction element from the payment request message; determine the target processing method based on the at least one transaction element and the correspondence between the transaction element and the processing method.

[0023] In some embodiments, the locally stored information related to the processing method includes multiple historical payment information, and the historical payment information includes historical payment request messages, historical feedback messages of the risk monitoring system, and corresponding historical processing methods; the determination module is further used to: determine at least one candidate historical payment request message based on the similarity between the payment request message and the multiple historical payment request messages; aggregate the historical processing methods corresponding to each of the at least one candidate historical payment request message to obtain the number corresponding to each different historical processing method; and determine the target processing method based on the number corresponding to each different historical processing method.

[0024] In some implementations, the determination module is further configured to: determine the similarity between the payment request message and each of the historical request messages according to the vector corresponding to the payment request message and the vectors corresponding to each of the historical request messages.

[0025] In a third aspect, an embodiment of the present application provides a payment request processing device, including: a memory, a processor;

[0026] The memory stores computer-executable instructions;

[0027] The processor executes the computer-executable instructions stored in the memory, so that the processor executes the above first aspect and / or various possible implementations of the first aspect.

[0028] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are executed by a processor, they are used to implement the first aspect above and / or various possible implementations of the first aspect.

[0029] In a fifth aspect, an embodiment of the present application provides a computer program product, including a computer program, which, when executed by a processor, implements the above first aspect and / or various possible implementation methods of the first aspect.

[0030] The payment request processing method, device and equipment provided in the embodiments of the present application, after receiving the payment request message, requests the risk monitoring system to perform risk detection on the payment request message. When the waiting time for the feedback message indicating the risk detection result is longer than the waiting time threshold, the target processing method can be determined according to the locally stored information related to the processing method. The above-mentioned waiting time threshold is determined by the probability density function of the waiting time determined according to the waiting time of multiple historical feedback messages. The above-mentioned waiting time threshold is relatively reasonable, and the feedback message of the risk monitoring system in the normal state will not be missed with a greater probability. If the waiting time is longer than the waiting time threshold, it can be regarded as the communication link with the risk monitoring system or the risk monitoring system is abnormal. There is no need to continue waiting for the feedback message. The target processing method can be determined according to the local information related to the processing method, which can improve the response speed of the payment request, improve the processing efficiency of the payment request, and improve the user experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0032] Figure 1 A schematic diagram of the payment request processing process provided for this application;

[0033] Figure 2 Schematic diagram of the payment request processing method provided for this application Figure 1 ;

[0034] Figure 3 A schematic diagram of the process of determining the waiting time threshold provided for this application;

[0035] Figure 4 Schematic diagram of the payment request processing method provided for this application Figure 2 ;

[0036] Figure 5 A schematic diagram of the structure of the payment request processing device provided by this application;

[0037] Figure 6 A schematic diagram of the structure of the payment request processing device provided for this application.

[0038] The above drawings have shown clear embodiments of the present application, which will be described in more detail later. These drawings and text descriptions are not intended to limit the scope of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0039] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0040] Figure 1 A schematic diagram of the payment request processing process provided for this application, such as Figure 1 As shown, the user can perform a payment operation on the mobile terminal 101, thereby initiating a payment request to the mobile terminal 101. The mobile terminal 101 can generate a payment request message according to the payment request, and send the payment request message to the payment system (for example, running on the server 102). The payment system can send a risk monitoring request to the risk monitoring system (for example, running on the server 103) according to the payment request message. The risk monitoring system can perform risk detection on the payment request message according to the risk monitoring request, and send a feedback message to the payment system according to the risk detection result. The payment system determines the processing method of the payment request according to the feedback message. For example, continue to pay or give up payment.

[0041] In combination with the above scenarios, it can be seen that in the relevant technologies, since the risk payment system needs to send a risk monitoring request to the risk monitoring system through the communication network, and the risk monitoring system needs to send a feedback message to the payment system through the communication network, if the communication network fails during this process, or the risk monitoring system is overloaded, the risk payment system will not be able to receive the feedback message in time, and the payment request will be in a long waiting period and cannot be processed, resulting in low payment request processing efficiency and poor user experience.

[0042] It should be noted that the payment request processing method, device and equipment of the present application can be used in the financial field, and can also be used in any field other than the financial field, such as the source of artificial intelligence technology. The application field of the payment request processing method, device and equipment of the present application is not limited.

[0043] The technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems are described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0044] Figure 2 Schematic diagram of the payment request processing method provided for this application Figure 1 ,like Figure 2 As shown, the method includes:

[0045] S201. Determine a risk attribute value according to a received payment request message, generate a risk detection request message including the risk attribute value, and send the risk detection request message to a risk monitoring system; wherein the payment request message is generated by a mobile terminal according to a payment request received from a user, and the risk monitoring system is used to generate a feedback message according to the risk attribute value, and the feedback message is used to determine a processing method for the payment request.

[0046] The mobile terminal may include a mobile phone, a laptop computer, a digital broadcast receiver, a personal digital assistant (PDA), a tablet computer, etc. The mobile terminal may run a payment application client or a web payment client. A user may initiate a payment request to a target account on the mobile terminal. The payment request may include payment account information and information to be paid. The payment account information includes the first account that initiates the payment request, for example, the user name or account of the account. The information to be paid may include, for example, the payment information that the payment system needs to allow to execute this time, including the payment amount, time, transaction type (transfer or consumption), information of the recipient (including the user name and / or second account corresponding to the recipient), the geographical location of the first account initiating the payment this time, the login IP address and domain name, the login device number of the first account this time, etc.

[0047] The execution subject (eg, a terminal or a server) of the payment request processing method may receive a payment request message sent by a mobile terminal, and the execution subject may determine a risk attribute value from the payment request message.

[0048] As an implementation method, the above step S201 includes: obtaining a preset risk attribute, and determining a risk attribute value according to the preset risk attribute and a payment request message.

[0049] One or more risk attributes may be pre-configured in the above-mentioned execution entity, and then the corresponding value may be determined in the above-mentioned payment request message according to the risk attribute as the risk attribute value. Indicatively, the risk attributes may include, but are not limited to: 1. Geographic location: abnormal geographic location may indicate potential fraud. 2. Device information: requests initiated by unknown or uncommon devices may be considered risks. 3. Transaction amount: abnormally high or low transaction amounts may require additional verification. 4. Transaction frequency: multiple transaction requests in a short period of time may be considered suspicious. 5. Payment method: using uncommon or newly added payment methods may increase risk. 6. User behavior pattern: transaction patterns that are inconsistent with the user's usual behavior may be marked as risks. 7. IP address and domain name: IP addresses and domain names from uncommon or high-risk areas may be considered risks.

[0050] The above-mentioned geographic location, device information, transaction amount, payment method, user behavior pattern, IP address and domain name can be directly obtained from the payment request message. The transaction frequency can be determined based on the historical payment requests of the first account and the current payment request.

[0051] The execution subject may generate a risk detection request message including the risk attribute value, and send the risk detection request message to the risk monitoring system. After sending the risk detection message to the risk monitoring system, the execution subject may process the state of waiting for a feedback message from the risk monitoring system.

[0052] After receiving the risk detection request message, the risk monitoring system can analyze whether the payment request is risky based on the risk attribute value. Usually, the risk monitoring system will send a feedback message to the execution entity based on the risk detection result, and the feedback message indicates whether the payment request is risky.

[0053] However, if there is a fault or blockage in the communication network between the above-mentioned execution entity and the server running the risk monitoring system, or if the above-mentioned risk monitoring system is under heavy load, the risk monitoring system may not be able to receive feedback messages in time, resulting in the payment system being unable to process the payment request in time and the payment request processing efficiency being low.

[0054] S202. In response to detecting that the waiting time for a feedback message is greater than a waiting time threshold, determine a target processing method for the payment request based on locally stored information related to the processing method; wherein the waiting time threshold is determined based on a probability density function of the waiting time, wherein the probability density function of the waiting time is determined based on the waiting time of historical feedback messages.

[0055] After sending the risk monitoring request message to the risk monitoring system, the execution subject periodically detects whether the waiting time is greater than the waiting time threshold while waiting for the feedback message. If it is detected that the waiting time is greater than the waiting time threshold, the target processing method of the payment request can be determined based on the information related to the processing method stored locally. For example, the processing method corresponding to a historical request message with the highest matching degree with the payment request message is used as the target processing method.

[0056] The local storage here refers to storage in the execution subject, or storage in an electronic device or storage medium that is communicatively connected to the execution subject.

[0057] The above-mentioned target processing methods include but are not limited to one or more of the following: allowing transactions, manual review, enhanced verification, limiting transaction amounts, refusing transactions, marking accounts, freezing accounts, sending risk warning information to relevant parties, etc. The above-mentioned multiple processing methods may correspond to different risk control levels, for example, the risk control levels of allowing transactions, manual review, enhanced verification, limiting transaction amounts, refusing transactions, marking accounts, freezing accounts, and sending risk warning information to relevant parties gradually increase. The above-mentioned waiting time threshold is determined by the probability density function of the waiting time. Since the probability density function of the above-mentioned waiting time can be determined based on the waiting time of historical feedback messages, the above-mentioned waiting time threshold can wait for the feedback message of the risk monitoring system within a relatively reasonable waiting time. If the waiting time threshold is exceeded, it can be regarded as that the risk monitoring system will not send a feedback message with a high probability. Therefore, the rationality of the above-mentioned waiting time threshold is relatively high.

[0058] In some implementations, the locally stored information related to the processing method includes a correspondence between transaction elements and the processing method. The above step S203 includes the following sub-steps:

[0059] First, at least one transaction element is determined from the payment request message.

[0060] The above-mentioned transaction elements refer to various information required to constitute a transaction, including one or more of the following: payment account information, amount, recipient account information, transaction date and time, and transaction type.

[0061] Secondly, the target processing method is determined according to the at least one transaction element and the corresponding relationship between the transaction element and the processing method.

[0062] In one example, the correspondence between the transaction elements and the processing methods may include the processing methods corresponding to the combination of multiple transaction elements. Multiple transaction element combinations may be formed according to different values ​​of multiple transaction elements, and each combination corresponds to a processing method. Payment account information a1, amount b1, recipient account information c1, transaction date and time d1, and transaction type e1 are used as combination 1, and the corresponding processing method 1 is set for combination 1. Payment account information a2, amount b2, recipient account information c2, transaction date and time d2, and transaction type e2 may be used as combination 2, and the corresponding processing method 2 is set for combination 2.

[0063] The target processing method can be searched in the above correspondence according to the combination of the values ​​of the at least one corresponding transaction element. In this example, the target processing method can be searched in the above correspondence according to the combination of the values ​​of the at least one corresponding transaction element, and the target processing method can be quickly determined.

[0064] In one example, for each transaction element, a processing method can be set for different values ​​of the transaction element. For example, a corresponding first processing method is set for different payment account information, and a different second processing method is set for different amounts; a different third processing method is set for different recipient account information; a different fourth processing method is set for different transaction dates and times; and a different fifth processing method is set for different transaction types. The above-mentioned first processing method, second processing method, third processing method, fourth processing method and fifth processing method can each include one of the following:

[0065] Allow transactions, manual review, enhanced verification, limit transaction amount, reject transactions, mark accounts, freeze accounts, send risk warning information to relevant parties, etc.

[0066] In this example, the processing methods corresponding to the values ​​of each transaction element determined from the payment request message can be determined respectively. If the processing methods corresponding to the transaction elements are the same, the same processing method is used as the target processing method. If they are different, the processing method with the highest risk control level among the processing methods is used as the target processing method corresponding to the payment request message. This can improve payment security.

[0067] For example, for the payment request message w, the first processing method corresponding to the payment account information w1 determined in the payment request message, the second processing method corresponding to the amount w2, the third processing method corresponding to the recipient account information w3, the fourth processing method corresponding to the transaction date and time w4, and the fifth processing method corresponding to the transaction type w5 are the same. For example, they all indicate allowing the transaction, then the target processing method is to allow the transaction.

[0068] If the first processing method is to allow the transaction, the second processing method is to allow the transaction, the third processing method is to reject the transaction, the fourth processing method is to allow the transaction, and the fifth processing method is manual review, then the processing method corresponding to the payment request message is to reject the transaction.

[0069] In these embodiments, a target processing method is determined by extracting transaction elements from the payment request message and pre-stored correspondences between transaction elements and processing methods, so that a more accurate processing method can be determined.

[0070] S203: Process the payment request according to the target processing method.

[0071] If the target processing method is to allow the transaction, the execution entity will continue to pay. If the target processing method is manual review, the execution entity will send the payment request to the staff and notify the user who initiated the payment request that a manual review will be conducted; if the target processing method is enhanced verification, an enhanced verification request will be initiated to the user. If the target processing method is to reject the transaction, the transaction will be stopped and a prompt message will be sent to the user. If the target processing method is to mark the account, the payment can continue, but the account will be treated as an account that needs to be monitored. If the target processing method is to freeze the account, the payment will be stopped and the account will be frozen. If the target processing method is to send a risk warning message to the relevant party, the payment will be stopped and a risk warning message will be sent to the relevant party. The relevant parties here can be the police, the user of the account, the preset user in the financial institution, etc.

[0072] In this embodiment, after receiving the payment request message, a request is made to the risk monitoring system to perform risk detection on the payment request message. When the waiting time for the feedback message indicating the risk detection result is longer than the waiting time threshold, the target processing method can be determined based on the locally stored information related to the processing method. The above-mentioned waiting time threshold is determined by the probability density function of the waiting time determined based on the waiting time of multiple historical feedback messages. The above-mentioned waiting time threshold is relatively reasonable, and the feedback message of the risk monitoring system in a normal state will not be missed with a greater probability. If the waiting time is longer than the waiting time threshold, it can be regarded as the communication link with the risk monitoring system or the risk monitoring system is abnormal. There is no need to continue waiting for the feedback message. The target processing method can be determined based on the local information related to the processing method, which can improve the response speed of the payment request, improve the processing efficiency of the payment request, and improve the user experience.

[0073] Please refer to Figure 3 , Figure 3 A schematic diagram of a process for determining a waiting time threshold provided by the present disclosure. The specific waiting time threshold is determined based on the following steps:

[0074] S301: Acquire multiple historical payment information, where the historical payment information includes historical payment request messages, the first moment of sending historical risk detection request messages to the risk monitoring system, and the second moment of receiving historical feedback messages sent by the risk monitoring system.

[0075] S302: Determine the historical waiting time corresponding to each of the multiple historical payment information according to the first time and the second time of each of the multiple historical payment information.

[0076] In this embodiment, the execution subject of determining the waiting time threshold may be a terminal or a server. It is understandable that the process of determining the waiting time threshold may be performed before the above step S201.

[0077] The execution subject may obtain multiple historical payment information locally or from an electronic device storing the historical payment information. For each historical payment information, the first moment and the second moment are extracted from the historical payment information, and the time interval between the second moment and the first moment is calculated, and the time interval is used as the waiting time of the historical payment information.

[0078] S303: Determine a probability density function of the waiting time according to multiple historical waiting times.

[0079] The probability density function of the waiting time may be determined according to the distribution of multiple historical waiting times.

[0080] As an implementation method, the above step S303 includes the following steps:

[0081] First, a minimum value and a maximum value are determined from a plurality of historical waiting times, and a total number of the plurality of historical waiting times is determined.

[0082] The above minimum value refers to the shortest historical waiting time among multiple historical waiting times. The maximum value refers to the longest historical waiting time among multiple historical waiting times.

[0083] The above total number can be obtained by counting the number of multiple historical waiting times.

[0084] Second, determining a first endpoint and a second endpoint according to the maximum value and the minimum value, wherein the first endpoint is less than or equal to the minimum value, and the second endpoint is greater than or equal to the maximum value;

[0085] In order to obtain the probability density function of the waiting time, the waiting time intervals into which multiple historical waiting times fall can be found first, and then the probability density function can be determined.

[0086] In one example, any duration less than the minimum value can be used as the first endpoint. Schematically, if the minimum value is 1 second, the first endpoint can be 0.5 seconds or 0 seconds. Any duration greater than the maximum value can be used as the second endpoint. Schematically, if the maximum value is 20 seconds, the second endpoint can be 25 seconds.

[0087] In one example, the minimum value may be used as the first endpoint, and the maximum value may be used as the second endpoint.

[0088] Third, the waiting time interval determined by the first endpoint and the second endpoint is divided into a plurality of mutually non-intersecting time sub-intervals, wherein the number of historical waiting times included in each time sub-interval is greater than a preset number threshold.

[0089] The waiting time interval formed by the first endpoint and the second endpoint may be further divided into a plurality of time sub-intervals.

[0090] When the waiting time interval is divided into multiple time sub-intervals, each time sub-interval can be determined according to the number of historical waiting times included. The number of historical waiting times included in each time sub-interval needs to be greater than a preset number threshold. The above-mentioned preset number threshold can be set according to a specific application scenario, and is limited here. Schematically, the above-mentioned preset number threshold can be 10.

[0091] In one example, the time intervals corresponding to the multiple duration subintervals may be equal; in another example, the time intervals corresponding to the multiple duration subintervals may also be unequal.

[0092] Fourth, for each duration sub-interval, determine the midpoint of the duration sub-interval, and use the proportion of the number of historical waiting times included in the duration sub-interval in the total number as the probability of the midpoint.

[0093] For example, for a duration subinterval (t1, t2], the midpoint of the duration subinterval is (t1+t2) / 2. If the number of historical waiting times in the duration subinterval is 20, the probability corresponding to the midpoint is 20 / N, where N is the total number.

[0094] Fifth, function fitting is performed based on the midpoint of each duration subinterval and the probability corresponding to the midpoint to obtain the first function.

[0095] Through the fourth step, the midpoints of the multiple duration sub-intervals and the probabilities corresponding to the midpoints can be obtained. Taking the duration as the independent variable, the multiple midpoints and the corresponding probabilities are fitted to obtain the first function.

[0096] The first function can be expressed as: p=f(t), where f(t) may include one or more parameters, t represents the independent variable of duration, f() is a first-order or multi-order function with t as the independent variable, and p is the probability density.

[0097] Sixth, according to the integral value of the first function, the parameters of the first function are modified to obtain the probability density function of the waiting time.

[0098] For the first function, one or more parameters in the first function are modified according to the integral value of the probability density function in the full range of the independent variable being 1, so as to obtain the probability density function of the waiting time. The above probability density function of the waiting time is determined from multiple historical waiting times actually generated, so the probability density function can more accurately reflect the distribution characteristics of the actual waiting time for the feedback message. A more accurate waiting time threshold can be determined by the above probability density function.

[0099] S304: Determine a waiting duration threshold according to the probability density function of the waiting duration and a preset loss probability value, where the loss probability value is used to indicate the probability that a feedback message is discarded.

[0100] In one example, the loss probability value can be determined by the proportion of historical payment information that has not received a feedback message, historical payment information that has received a feedback message but has not been used, and all historical payment information generated within a preset time period. For example, if the number of all the above historical payment information is L1, the number of historical payment information that has not received a feedback message is L2, and the number of historical payment information that has received a feedback message but has not been used is L3, then the loss probability value can be determined by (L2 + L3) / L1. In one example, (L2 + L3) / L1 can be used as the loss probability value.

[0101] In one example, the above loss probability value can be set by the user.

[0102] Illustratively, the above preset loss probability value can be, for example, 5%.

[0103] With the probability density function, the preset loss probability value, and the properties of the probability density, the waiting duration threshold is calculated.

[0104] Specifically, the waiting duration threshold Tp can be determined based on the following formula (1):

[0105] P(0 < T ≤ T1) = ∫0 Tp f(t)dt (1);

[0106] where f(t) is the probability density function of the waiting duration. P(0 < T ≤ T1) = 1 - a; a is the preset loss probability value.

[0107] The waiting duration threshold can be calculated through the above formula.

[0108] Since the probability density function of the above waiting duration is determined by historical payment information, the waiting duration threshold obtained through the probability density function of the waiting duration and the preset loss probability value is relatively reasonable and can conform to more application scenarios.

[0109] In some embodiments, the waiting duration threshold can also be corrected. Specifically, the waiting duration threshold can be corrected through the following steps:

[0110] First, determine the mean and variance of the multiple historical waiting durations.

[0111] The above mean can be the statistical mean of the multiple historical waiting durations, and the above mean can be represented as μ.

[0112] The variance of multiple historical waiting times can be calculated according to the following formula (2):

[0113]

[0114] Where N is the total number of historical waiting times. μ is the mean. T i is the i-th historical waiting time. i is an integer greater than or equal to 1 and less than or equal to N. σ 2 is the variance of multiple historical waiting times.

[0115] Second, calculate the product of the variance and the total number of the multiple historical waiting times N×σ 2 .

[0116] Third, a probability value is set, wherein the probability value represents the probability that the acceptable deviation value of the mean exceeds the expected value.

[0117] The probability value can quantify the degree of acceptable mean deviation. This probability value can be set by the user. Schematically, the above probability value can be expressed as α.

[0118] Fourth, calculate the ratio of the product to the probability value, and the square root of the ratio.

[0119] For example, to calculate (N×σ 2 ) / α and

[0120] Fifth, the waiting time threshold is corrected to the sum of the waiting time threshold and the square root.

[0121] Also coming soon As the corrected waiting time threshold, Tp is the waiting time threshold obtained in steps S301 to S303.

[0122] In these optional implementations, by correcting the waiting time threshold obtained in steps S301 to S303, the accuracy of the waiting time threshold can be further improved.

[0123] Please refer to Figure 4 , Figure 4 Schematic diagram of the payment request processing method provided by the present disclosure Figure 2 .like Figure 3 As shown, the method comprises the following steps:

[0124] S401: Determine the risk attribute value according to the received payment request message, generate a risk detection request message including the risk attribute value, and send the risk detection request message to the risk monitoring system; wherein, the payment request message is generated by the mobile terminal according to the payment request received from the user, and the risk monitoring system is used to generate a feedback message according to the risk attribute value, and the feedback message is used to determine the processing method of the payment request.

[0125] The specific implementation of the above step S401 can refer to Figure 2 The description of step S201 is omitted here.

[0126] S402: In response to detecting that the waiting time for the feedback message is greater than the waiting time threshold, obtain historical payment request messages corresponding to multiple historical payment information stored locally; wherein the waiting time threshold is determined according to the probability density function of the waiting time, and the probability density function of the waiting time is determined according to the waiting time of the historical feedback message; the historical payment information includes historical payment request messages, historical feedback messages of the risk monitoring system and corresponding historical processing methods.

[0127] In this embodiment, the execution subject of the payment request processing method may be a terminal or a server. When the execution subject detects that the waiting time for the feedback message from the risk monitoring system is greater than the waiting time threshold, the execution subject may obtain multiple historical payment information locally or in an electronic device or storage medium that is in communication with the execution subject.

[0128] S403: Determine at least one candidate historical payment request message according to the similarity between the payment request message and a plurality of historical payment request messages.

[0129] In one example, the similarity between the payment request message and each historical request message is determined based on the vector corresponding to the payment request message and the vectors corresponding to each historical request message.

[0130] The payment request message and each historical payment request message can be converted into vectors respectively, and the similarity between the payment request message and each historical request message can be calculated according to the vectors corresponding to the payment request message and the multiple historical payment request messages. For example, the payment request message can be vectorized to obtain a first vector, and for any historical request message, the historical request message can be vectorized to obtain a second vector. The Jaccard similarity, cosine similarity, etc. between the first vector and the second vector are calculated to obtain the similarity between the payment request message and the historical payment request message. In this example, by converting the payment request message and the historical payment request message into vectors respectively, and calculating the similarity between the payment request message and the historical payment request message, the similarity between the payment request message and each historical payment request message can be quickly and accurately determined, thereby improving the accuracy of the determined candidate historical payment request message.

[0131] S404: Aggregate the historical processing methods corresponding to at least one candidate historical payment request message to obtain the number of different historical processing methods.

[0132] Specifically, the historical processing methods corresponding to at least one candidate historical payment request may be grouped and counted to obtain the numbers corresponding to different historical processing methods.

[0133] For example, the historical payment request messages A1, A2, A3, A4 and A5 correspond to the processing methods F1, F2, F3, F1 and F1 respectively. After aggregation, the numbers corresponding to the different historical processing methods F1, F2 and F3 are 3, 1 and 1 respectively.

[0134] S405: Determine a target processing method for the payment request according to the respective quantities of different historical processing methods.

[0135] In one example, for each historical processing method, the historical processing method with the largest number of corresponding items may be used as the target processing method.

[0136] In one example, the ratio of the number of each historical processing method to the total number of historical payment request messages can be calculated, and the ratio is used as the proportion of historical processing methods. The historical processing method with the largest proportion is used as the target processing method.

[0137] S406: Process the payment request according to the target processing method.

[0138] The specific implementation of step S406 can refer to Figure 2 The step S203 shown is not repeated here.

[0139] This embodiment describes how to determine the content of the target processing method of a payment request through historical payment information when no feedback message is received from the risk monitoring system after the waiting time is greater than the waiting time threshold, thereby obtaining a more accurate target processing method and improving the processing efficiency of the payment request.

[0140] Figure 5 The structural diagram of the payment request processing device provided by this application is as follows: Figure 5 As shown, the payment request processing device 50 provided in this embodiment includes: a generating module 501, a determining module 502 and a processing module 503, wherein:

[0141] A generating module 501 is used to determine the risk attribute value according to the received payment request message, generate a risk detection request message including the risk attribute value, and send the risk detection request message to the risk monitoring system; wherein the payment request message is generated by the mobile terminal according to the payment request received from the user, and the risk monitoring system is used to generate a feedback message according to the risk attribute value, and the feedback message is used to determine the processing method of the payment request;

[0142] A determination module 502, configured to determine, in response to detecting that the waiting time for the feedback message is greater than a waiting time threshold, a target processing method for the payment request according to locally stored information related to the processing method; wherein the waiting time threshold is determined according to a probability density function of the waiting time, wherein the probability density function of the waiting time is determined according to the waiting time of the historical feedback message;

[0143] The processing module 503 is used to process the payment request according to the target processing mode.

[0144] In some implementations, the generation module 501 is further used to:

[0145] Obtain the preset risk attribute, and determine the risk attribute value based on the preset risk attribute and the payment request message.

[0146] In some implementations, the apparatus 50 further includes a waiting time threshold determination module (not shown in the figure), and the waiting time threshold module is used to:

[0147] Acquire multiple historical payment information, the historical payment information includes historical payment request messages, the first moment of sending historical risk detection request messages to the risk monitoring system, and the second moment of receiving historical feedback messages sent by the risk monitoring system;

[0148] Determine the historical waiting time corresponding to each of the plurality of historical payment information according to the first time and the second time of each of the plurality of historical payment information;

[0149] Determine a probability density function of the waiting time according to a plurality of historical waiting times;

[0150] The waiting time threshold is determined according to a probability density function of the waiting time and a preset loss probability value, wherein the loss probability value is used to indicate the probability of a feedback message being discarded.

[0151] In some implementations, the waiting time threshold determination module is further configured to:

[0152] Determine a minimum value and a maximum value from the plurality of historical waiting times, and determine a total number of the plurality of historical waiting times;

[0153] Determine a first endpoint and a second endpoint according to the minimum value and the maximum value, wherein the first endpoint is less than or equal to the minimum value, and the second endpoint is greater than or equal to the maximum value;

[0154] Dividing the waiting time interval determined by the first endpoint and the second endpoint into a plurality of mutually non-intersecting time sub-intervals, wherein the number of historical waiting times included in each time sub-interval is greater than a preset number threshold;

[0155] For each duration sub-interval, determine the midpoint of the duration sub-interval, and use the proportion of the number of historical waiting times contained in the duration sub-interval in the total number as the probability of the midpoint;

[0156] According to the midpoint of each duration subinterval and the probability corresponding to the midpoint, function fitting is performed to obtain the first function;

[0157] According to the integral value of the first function, the parameters of the first function are modified to obtain a probability density function of the waiting time.

[0158] In some implementations, the locally stored information related to the processing method includes a correspondence between transaction elements and the processing method, and the determination module 502 is further configured to:

[0159] determining at least one transaction element from the payment request message;

[0160] A target processing method is determined according to at least one transaction element and a corresponding relationship between the transaction element and the processing method.

[0161] In some implementations, the locally stored information related to the processing method includes a plurality of historical payment information, the historical payment information includes historical payment request messages, historical feedback messages of the risk monitoring system, and corresponding historical processing methods; the determination module 502 is further used to:

[0162] Determining at least one candidate historical payment request message according to the similarity between the payment request message and a plurality of historical payment request messages;

[0163] Aggregating historical processing methods corresponding to at least one candidate historical payment request message to obtain the number of historical processing methods corresponding to each of the different historical processing methods;

[0164] Determine the target processing method based on the corresponding quantities of different historical processing methods.

[0165] In some implementations, the determination module 502 is further configured to:

[0166] The similarity between the payment request message and each historical request message is determined based on the vector corresponding to the payment request message and the vectors corresponding to each historical request message.

[0167] The payment request processing device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and this embodiment will not be described in detail here.

[0168] Figure 6 A schematic diagram of the structure of the payment request processing device provided in this application. Figure 6 As shown, the payment request processing device 60 provided in this embodiment includes: at least one processor 601 and a memory 602. Optionally, the device 60 also includes a communication component 603. The processor 601, the memory 602 and the communication component 603 are connected via a bus 604.

[0169] In a specific implementation process, at least one processor 601 executes the computer execution instructions stored in the memory 602, so that at least one processor 601 executes the above method.

[0170] The specific implementation process of the processor 601 can be found in the above method embodiment, and its implementation principle and technical effect are similar, so this embodiment will not be repeated here.

[0171] In the above embodiments, it should be understood that the processor may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), etc. A general-purpose processor may be a microprocessor or any conventional processor. The steps of the method disclosed in the invention may be directly implemented as being executed by a hardware processor, or may be executed by a combination of hardware and software modules in the processor.

[0172] The memory may include a high-speed memory (Random Access Memory, RAM), and may also include a non-volatile memory (Non-volatile Memory, NVM), such as at least one disk memory.

[0173] The bus may be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, the bus in the drawings of the present application is not limited to only one bus or one type of bus.

[0174] The present application also provides a computer program product, including a computer program, which implements the above method when executed by a processor.

[0175] The present application also provides a computer-readable storage medium, in which computer-executable instructions are stored. When a processor executes the computer-executable instructions, the above method is implemented.

[0176] The above-mentioned readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk. The readable storage medium can be any available medium that can be accessed by a general or special-purpose computer.

[0177] An exemplary readable storage medium is coupled to a processor so that the processor can read information from the readable storage medium and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can be located in an application specific integrated circuit (Application Specific Integrated Circuits, referred to as: ASIC). Of course, the processor and the readable storage medium can also exist in the device as discrete components.

[0178] The division of units is only a logical function division, and there may be other divisions in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interface, device or unit, which can be electrical, mechanical or other forms.

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

[0180] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

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

[0182] Those skilled in the art can understand that all or part of the steps of implementing the above-mentioned method embodiments can be completed by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, the steps of the above-mentioned method embodiments are executed; and the aforementioned storage medium includes: ROM, RAM, disk or optical disk and other media that can store program codes.

[0183] Finally, it should be noted that those skilled in the art will readily conceive of other embodiments of the present invention after considering the specification and practicing the invention disclosed herein. The present invention is intended to cover any variations, uses or adaptations of the present invention, which follow the general principles of the present invention and include common knowledge or customary technical means in the art not disclosed by the present invention, are not limited to the precise structure described above and shown in the drawings, and may be modified and changed in various ways without departing from the scope thereof. The scope of the present invention is limited only by the appended claims.

Claims

1. A payment request processing method, characterized in that: include: Determine the risk attribute value according to the received payment request message, generate a risk detection request message including the risk attribute value, and send the risk detection request message to the risk monitoring system; wherein the payment request message is generated by the mobile terminal according to the payment request received from the user, and the risk monitoring system is used to generate a feedback message according to the risk attribute value, and the feedback message is used to determine the processing method of the payment request; In response to detecting that the waiting time for the feedback message is greater than a waiting time threshold, determining a target processing method for the payment request according to locally stored information related to the processing method; wherein the waiting time threshold is determined according to a probability density function of the waiting time, wherein the probability density function of the waiting time is determined according to the waiting time of historical feedback messages; The payment request is processed according to the target processing mode.

2. The method according to claim 1, characterized in that Determining the risk attribute value according to the received payment request message includes: Obtain a preset risk attribute, and determine the risk attribute value according to the preset risk attribute and the payment request message.

3. The method according to claim 1, characterized in that The waiting time threshold is determined based on the following steps: Acquire multiple historical payment information, the historical payment information including historical payment request messages, a first time of sending a historical risk detection request message to the risk monitoring system, and a second time of receiving a historical feedback message sent by the risk monitoring system; Determine the historical waiting time corresponding to each of the plurality of historical payment information according to the first time and the second time of each of the plurality of historical payment information; Determine a probability density function of a waiting time according to a plurality of said historical waiting times; The waiting time threshold is determined according to a probability density function of the waiting time and a preset loss probability value, wherein the loss probability value is used to indicate a probability of a feedback message being discarded.

4. The method according to claim 3, characterized in that The probability density function of determining the waiting time according to the plurality of historical waiting times comprises: Determine a minimum value and a maximum value from the plurality of historical waiting times, and determine a total number of the plurality of historical waiting times; Determine a first endpoint and a second endpoint according to the minimum value and the maximum value, wherein the first endpoint is less than or equal to the minimum value, and the second endpoint is greater than or equal to the maximum value; Dividing the waiting time interval determined by the first endpoint and the second endpoint into a plurality of mutually non-intersecting time sub-intervals, wherein the number of historical waiting times included in each time sub-interval is greater than a preset number threshold; For each duration sub-interval, determine the midpoint of the duration sub-interval, and use the proportion of the number of historical waiting times included in the duration sub-interval to the total number as the probability of the midpoint; According to the midpoint of each duration subinterval and the probability corresponding to the midpoint, function fitting is performed to obtain the first function; According to the integral value of the first function, the parameters of the first function are modified to obtain the probability density function of the waiting time.

5. The method according to any one of claims 1 to 4, characterized in that: The information related to the processing method includes a correspondence between transaction elements and processing methods, and the determining of a target processing method of the payment request based on the locally stored information related to the processing method includes: Determining at least one transaction element from the payment request message; The target processing method is determined according to the at least one transaction element and the corresponding relationship between the transaction element and the processing method.

6. The method according to any one of claims 1 to 4, characterized in that The locally stored information related to the processing method includes a plurality of historical payment information, wherein the historical payment information includes historical payment request messages, historical feedback messages of the risk monitoring system, and corresponding historical processing methods; And determining the target processing method of the payment request according to the locally stored information related to the processing method includes: Obtaining historical payment request messages corresponding to the plurality of historical payment information respectively; Determining at least one candidate historical payment request message according to the similarity between the payment request message and the plurality of historical payment request messages; Aggregating the historical processing methods corresponding to the at least one candidate historical payment request message to obtain the number of historical processing methods corresponding to each of the different historical processing methods; The target processing method is determined according to the quantities corresponding to the different historical processing methods.

7. The method according to claim 6, characterized in that The step of determining at least one candidate historical payment request message according to the similarity between the payment request message and the plurality of historical payment request messages comprises: The similarity between the payment request message and each of the historical request messages is determined according to the vector corresponding to the payment request message and the vectors corresponding to each of the historical request messages.

8. A payment request processing device, characterized in that: include: A generation module, used to determine the risk attribute value according to the received payment request message, generate a risk detection request message including the risk attribute value, and send the risk detection request message to the risk monitoring system; wherein the payment request message is generated by the mobile terminal according to the payment request received from the user, and the risk monitoring system is used to generate a feedback message according to the risk attribute value, and the feedback message is used to determine the processing method of the payment request; a determination module, configured to determine, in response to detecting that the waiting time for the feedback message is greater than a waiting time threshold, a target processing method for the payment request according to information related to the processing method stored locally; wherein the waiting time threshold is determined according to a probability density function of the waiting time, wherein the probability density function of the waiting time is determined according to the waiting time of historical feedback messages; A processing module is used to process the payment request according to the target processing method.

9. A payment request processing device, characterized in that: include: Memory, processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory, so that the processor performs the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, which are used to implement the method according to any one of claims 1 to 7 when executed by a processor.

Images