Method and device for determining payment risk, electronic equipment, storage medium and product
Patent Information
- Application Number
- CN202510361832.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-03-25
- Publication Date
- 2026-09-29
AI Technical Summary
但是,目前对支付操作进行风险评估的评估准确性还有待提高
[0028]在本公开中,在检测到第一应用上的支付操作之后,可以获取支付操作对应的支付信息、第一应用的历史运行信息、第二应用的历史运行信息等。由于第二应用和第一应用为终端设备上的同类型应用。因此,第一应用的第一历史运行信息以及第二应用的第二历史运行信息可以在一定程度上反映出用户在历史时间对第一应用甚至第一应用的同类型应用的使用习惯,进而可以反映出用户在第一应用上进行支付的概率。基于此,通过支付信息并结合与第一应用的第一历史运行信息和/或第二应用的第二历史运行信息,对第一应用上的支付操作进行风险评估,可以提高得到的支付风险评估结果的准确性。
Smart Images

Figure CN122840952A_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to the field of electronic equipment technology, and in particular to a method, apparatus, electronic device, storage medium, and product for determining payment risk. Background Technology
[0002] With the rise of e-commerce, more and more users are accustomed to making online payments for transportation costs, purchased goods, and other items through applications on their mobile devices. However, before making online payments, users need to activate online payment services, which carries the risk of their payment accounts being stolen, potentially leading to financial losses.
[0003] Therefore, if a terminal device detects a user's payment operation, it can assess the risk of the payment operation through either a terminal device or a server device equipped with a risk assessment system, and refuse to process payments that pose a risk. However, the accuracy of current risk assessment methods for payment operations still needs improvement. Summary of the Invention
[0004] To overcome the problems existing in related technologies, this disclosure provides a method, apparatus, electronic storage medium and product for determining payment risk, which can improve the accuracy of risk assessment for payment operations.
[0005] According to a first aspect of the present disclosure, a method for determining payment risk is provided. The method includes: in response to triggering a payment operation of a first application, obtaining payment information corresponding to the payment operation; determining a payment risk assessment result of the payment operation based on the payment information and risk assessment reference information; wherein the risk assessment reference information includes first historical operation information related to the first application and / or second historical operation information related to a second application, and the first application and the second application are applications of the same type; displaying a payment result of the payment operation based on the payment risk assessment result; the payment result is used to indicate whether the payment for the transaction corresponding to the payment operation was successfully completed.
[0006] In some embodiments, based on the payment risk assessment result, displaying the payment result of the payment operation includes: displaying a payment interface in response to the payment risk assessment result indicating that there is no risk in the payment operation; wherein the payment interface is used for the user to enter a payment password or for the user to trigger the display of a payment password input interface; and displaying a payment result indicating successful payment in response to obtaining the payment password.
[0007] In some embodiments, displaying the payment result of a payment operation based on the payment risk assessment result further includes: outputting a prompt message in response to the payment risk assessment result indicating that the payment operation has a risk; wherein the prompt message is used to indicate that the transaction corresponding to the payment operation is prohibited from being paid.
[0008] In some embodiments, determining the payment risk assessment result of a payment operation based on payment information and risk assessment reference information includes: determining the security level of a first application based on the risk assessment reference information, wherein the security level is used to indicate the probability that the payment operation has a payment risk; and determining the payment risk assessment result based on the payment information and the security level.
[0009] In some embodiments, the first historical running information includes the number of times the first application was launched and / or the runtime of the first application in a historical time period, and the second historical running information includes the number of times the second application was launched and / or the runtime of the second application in a historical time period; wherein, determining the security level of the first application based on risk assessment reference information includes: determining the security value of the first application based on the number of launches and / or the runtime of the first application; and determining the security level based on the security value.
[0010] In some embodiments, the first historical running information includes the installation time of the first application and / or the most recent running duration of the first application; wherein, determining the security level of the first application based on risk assessment reference information includes: determining the first interval duration between the installation time of the first application and the current time; and determining the security level of the first application based on the first interval duration and / or the most recent running duration of the first application.
[0011] In some embodiments, a payment risk assessment result is determined based on payment information and security level, including at least one of the following: in response to the existence of multiple payment information, and the number of payment information that meets preset conditions among the multiple payment information reaches a first quantity threshold, it is determined that the payment operation has a risk; in response to the security level not reaching the level threshold, it is determined that the payment operation has a risk.
[0012] In some embodiments, determining the payment risk assessment result based on payment information and security level further includes: in response to the fact that the number of payment information meeting preset conditions has not reached a first quantity threshold and the security level has reached a level threshold, determining the payment risk assessment result through a risk assessment model based on the payment information and security level.
[0013] In some embodiments, the method further includes: obtaining payment results; and training a risk assessment model based on payment information, security level, and payment results.
[0014] According to a second aspect of the present disclosure, a payment risk determination apparatus is provided. The apparatus includes: a first acquisition module configured to acquire payment information corresponding to a payment operation triggered by a first application; a determination module configured to determine a payment risk assessment result of the payment operation based on the payment information and risk assessment reference information; wherein the risk assessment reference information includes first historical operation information related to the first application and / or second historical operation information related to a second application, and the first application and the second application are applications of the same type; and a display module configured to display the payment result of the payment operation based on the payment risk assessment result; the payment result is used to indicate whether the payment for the transaction corresponding to the payment operation was successfully completed.
[0015] In some embodiments, the display module is configured to: display a payment interface in response to a payment risk assessment result indicating that the payment operation has no risk; wherein the payment interface is used for the user to enter a payment password or for the user to trigger the display of a payment password input interface; and display a payment result indicating successful payment in response to obtaining the payment password.
[0016] In some embodiments, the display module is configured to: output a prompt message in response to a payment risk assessment result indicating that a payment operation is at risk; wherein the prompt message is used to indicate that the transaction corresponding to the payment operation is prohibited from being paid.
[0017] In some embodiments, the determining module is configured to: determine the security level of a first application based on risk assessment reference information, wherein the security level is used to indicate the probability that a payment operation has a payment risk; and determine the payment risk assessment result based on payment information and the security level.
[0018] In some embodiments, the first historical running information includes the number of times a first application was launched and / or the duration of its runtime in a historical period, and the second historical running information includes the number of times a second application was launched and / or the duration of its runtime in a historical period; wherein, the determining module is configured to: determine the security value of the first application based on the number of launches and / or the duration of its runtime; and determine the security level based on the security value.
[0019] In some embodiments, the first historical running information includes the installation time of the first application and / or the most recent running time of the first application; wherein the determining module is configured to: determine the first interval duration between the installation time of the first application and the current time; and determine the security level of the first application based on the first interval duration and / or the most recent running time of the first application.
[0020] In some embodiments, the determining module is configured to: determine that a payment operation is risky in response to the fact that there are multiple payment information items and the number of payment information items that meet preset conditions among the multiple payment information items reaches a first quantity threshold; or determine that a payment operation is risky in response to the fact that the security level does not reach a level threshold.
[0021] In some embodiments, the determining module is configured to: in response to the fact that the number of payment information that meets preset conditions has not reached a first quantity threshold and the security level has reached a level threshold, determine the payment risk assessment result based on the payment information and the security level through a risk assessment model.
[0022] In some embodiments, the device further includes: a second acquisition module configured to acquire payment results; and to train a risk assessment model based on payment information, security level, and payment results.
[0023] According to a third aspect of the present disclosure, an electronic device is provided, comprising:
[0024] A processor; a memory for storing computer programs or instructions; wherein the processor executes the computer programs or instructions to implement the steps of the method described in the first aspect above.
[0025] According to a fourth aspect of the present disclosure, a non-transitory computer-readable storage medium is provided, which stores executable instructions or a computer program that, when executed by a processor, implements the steps of the method described in the first aspect.
[0026] According to a fifth aspect of the present disclosure, a computer program product is provided, including a computer program or instructions, which, when executed by a processor, implement the steps of the method described in the first aspect above.
[0027] The technical solutions provided by the embodiments of this disclosure may include the following beneficial effects:
[0028] In this disclosure, after detecting a payment operation on a first application, payment information corresponding to the payment operation, historical operation information of the first application, and historical operation information of a second application can be obtained. Since the second application and the first application are of the same type on the terminal device, the first historical operation information of the first application and the second historical operation information of the second application can, to some extent, reflect the user's usage habits of the first application and even similar applications over a historical period, thus reflecting the probability of the user making a payment on the first application. Based on this, by combining payment information with the first historical operation information of the first application and / or the second historical operation information of the second application to conduct a risk assessment of the payment operation on the first application, the accuracy of the obtained payment risk assessment results can be improved.
[0029] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description
[0030] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.
[0031] Figure 1 This is a schematic diagram illustrating an application scenario of a method for determining payment risk according to an exemplary embodiment.
[0032] Figure 2 This is a flowchart illustrating a method for determining payment risk according to an exemplary embodiment.
[0033] Figure 3 This is a schematic diagram illustrating a first application according to an exemplary embodiment.
[0034] Figure 4 This is a schematic diagram illustrating a security level of a first application according to an exemplary embodiment.
[0035] Figure 5 This is a flowchart illustrating a method for determining payment risk according to another exemplary embodiment.
[0036] Figure 6 This is a schematic diagram illustrating a payment system according to an exemplary embodiment.
[0037] Figure 7 This is a block diagram illustrating a payment risk determination device according to an exemplary embodiment.
[0038] Figure 8 This is a structural block diagram of a terminal device according to an exemplary embodiment.
[0039] Figure 9 This is a block diagram illustrating a server device according to an exemplary embodiment. Detailed Implementation
[0040] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.
[0041] Before introducing the embodiments of this disclosure, the application scenarios of these embodiments will be described first, as follows:
[0042] With the rise of e-commerce, more and more users are accustomed to making online payments for transportation costs, purchased goods, and other items through applications on their mobile devices. However, before making online payments, users need to activate online payment services, which carries the risk of their payment accounts being stolen, potentially leading to financial losses.
[0043] Therefore, if a terminal device detects a user's payment operation, it can assess the risk of the payment operation through either a terminal device or a server device equipped with a risk assessment system, and refuse to process payments that pose a risk. However, the accuracy of current risk assessment methods for payment operations still needs improvement.
[0044] For example, Figure 1 This is a schematic diagram illustrating an application scenario of a method for determining payment risk according to an exemplary embodiment. For example... Figure 1 As shown, a user can operate terminal device 101 to launch a first application 1011 on terminal device 101 and purchase goods on the first application 1011. Upon detecting an order for goods 1012 on the first application, terminal device 101 can send a payment request to server device 102, which is equipped with a risk assessment system 1021. Based on this, server device 102 can receive the payment request from terminal device 101 and determine whether the payment operation corresponding to the payment request involves payment risk. If server device 102 determines that the payment operation corresponding to the payment request involves payment risk, it can refuse to process the transaction corresponding to the payment request. This reduces the risk of user financial loss due to the theft of the user's payment account.
[0045] To address the aforementioned issues, this disclosure provides a method for determining payment risk. Figure 2 This is a flowchart illustrating a method for determining payment risk according to an exemplary embodiment. The method for determining payment risk provided in this disclosure can be executed by a terminal device or jointly by a terminal device and a server device. For example, the terminal device may include a mobile terminal and a fixed terminal. The mobile terminal may include: a mobile phone, tablet computer, laptop computer, vehicle-mounted terminal, and wearable electronic device, etc. The fixed terminal may include a desktop computer, all-in-one computer, etc. For example, the server device includes, but is not limited to: a single server or a server cluster. In the following, the terminal device will be used as the execution subject, referring to... Figure 2 The steps shown illustrate a method for determining payment risk provided by embodiments of this disclosure. The method includes:
[0046] In step 201, in response to triggering the payment operation of the first application, the payment information corresponding to the payment operation is obtained.
[0047] Understandably, the terminal device has a first application installed. Based on this, if the terminal device detects a payment operation on the first application, it can obtain the payment information corresponding to that payment operation.
[0048] In some embodiments, the first application can be any application on the terminal device that is capable of making online payments.
[0049] For example, Figure 3 This is a schematic diagram illustrating a first application (APP) according to an exemplary embodiment. For example... Figure 3 As shown, the first application can be a shopping app, a gaming app, a social app, etc.
[0050] In some embodiments, payment operations include, but are not limited to: order placement, fund transfer, and scanning of a QR code for payment.
[0051] In some embodiments, the goods purchased during the ordering process can be physical goods or virtual goods, and this disclosure does not limit this.
[0052] In some embodiments, the payment information includes, but is not limited to: the account information of the user account logged in on the first application when the payment operation is triggered, the historical payment information of the user account logged in on the first application when the payment operation is triggered, the Internet Protocol (IP) address of the network currently connected to the first device, the device identifier of the first device, the payment amount of the payment operation, the relevant information of the goods paid for by the payment operation, the system address of the first device, and the delivery address of the goods paid for by the payment operation.
[0053] In some embodiments, the user account's historical payment information includes, but is not limited to: the number of transactions by the user account in a first time period and the transaction amount of the user account in a second time period.
[0054] In some embodiments, the first time period can be 10 minutes prior to the current time. For example, when the current time is 15:30, the first time period can be the period between 15:20 and 15:30.
[0055] In some embodiments, the second time period can be 7 days prior to the current time.
[0056] In some embodiments, after receiving payment information, the terminal device may also send a payment request to the server device, and include the payment information in the payment request.
[0057] In step 202, the payment risk assessment result of the payment operation is determined based on the payment information and risk assessment reference information.
[0058] Understandably, after detecting a payment operation or obtaining payment information, the terminal device can also acquire risk assessment reference information and, based on the obtained payment information and risk assessment reference information, assess the payment risk of the payment operation. At this point, the terminal device can obtain a payment risk assessment result for the payment operation. This payment risk assessment result is used to indicate whether there is any payment risk in the payment operation.
[0059] In some embodiments, the risk assessment reference information includes first historical operating information related to a first application and / or second historical operating information related to a second application.
[0060] In some embodiments, the first historical running information includes, but is not limited to, the number of times the first application was run in a historical period, its running duration, installation time, and other information.
[0061] In some embodiments, the second historical running information includes, but is not limited to, information such as the number of times the second application was run in a historical period, the runtime, and the installation time.
[0062] In some embodiments, the second historical running information may be at least partially the same as the first historical running information.
[0063] In some embodiments, the second application is an application of the same type as the first application installed on the terminal device.
[0064] For example, the second application can be an application with the same functionality as the first application. For instance, if the first application is a shopping application, the second application can include at least one other shopping application installed on the terminal device besides the first application. If the first application is a game application, the second application can be at least one other game application installed on the terminal device besides the first application. If the first application is a social application, the second application can be at least one other social application installed on the terminal device besides the first application.
[0065] In some embodiments, the payment risk assessment result may include a first assessment result and a second assessment result. The first assessment result indicates that a payment operation carries payment risk. The second assessment result indicates that a payment operation does not carry payment risk.
[0066] In some embodiments, the terminal device can perform risk assessments on payment operations using payment information and risk assessment reference information respectively, and generate a first assessment result if either the payment information or the risk assessment reference information determines that the payment operation has payment risk. The terminal device can also generate a second assessment result if both the payment information and the risk assessment reference information determine that the payment operation does not have payment risk.
[0067] In some embodiments, the terminal device may also input payment information and risk assessment reference information into a trained risk assessment model, and use the risk assessment model to assess the risk of the payment operation to obtain the payment risk assessment result output by the risk assessment model.
[0068] In some embodiments, the terminal device may also input the payment information and risk assessment reference information into a risk assessment model to perform a risk assessment on the payment operation if it is determined through payment information and / or through risk assessment reference information that the payment operation does not have payment risk.
[0069] In some embodiments, when the terminal device sends a payment request to the server device based on a detected payment operation, step 202 described above can also be performed by the server device. That is, the server device can receive the payment request sent by the terminal device and obtain risk assessment reference information after receiving the payment request. Then, the terminal device can determine the payment risk assessment result of the payment operation based on the payment information carried in the payment request and the obtained risk assessment reference information.
[0070] It should be noted that the process by which the server device determines the payment risk assessment result of the payment operation based on payment information and risk assessment reference information can be referred to the process by which the terminal device determines the payment risk assessment result of the payment operation based on payment information and risk assessment reference information. This embodiment will not be repeated here.
[0071] In some embodiments, the risk assessment model may be deployed on a server-side device or a terminal device, and this disclosure does not limit this.
[0072] In step 203, the payment result of the payment operation is displayed based on the payment risk assessment results.
[0073] In some embodiments, the payment result is used to indicate whether the payment for the transaction corresponding to the payment operation was successfully completed.
[0074] Understandably, after receiving the payment risk assessment result, the terminal device can determine whether a payment operation carries any risk. If the terminal device determines that the payment operation does not carry any risk, it can proceed with the payment and display a successful payment result. If the terminal device determines that the payment operation carries a risk based on the payment risk assessment result, it can refuse to proceed with the payment and display a failed payment result.
[0075] In some embodiments, if the terminal device determines that there is no risk in the payment operation based on the payment risk assessment result, it may prompt the user to enter a payment password. After obtaining the payment password, the terminal device sends the payment password to the server device, enabling the server device to send a payment request carrying the payment password to the payment device. The payment device can then process the payment for the transaction based on the payment password. After processing the payment for the transaction based on the payment password, the payment device may send a first notification message to the server device. Based on this, the server device may send a second notification message to the terminal device based on the first notification message to notify the terminal device that the transaction corresponding to the payment operation has been successfully paid. Upon receiving the second notification message, the terminal device may display a successful payment result.
[0076] In some embodiments, if the step of determining the payment risk assessment result of a payment operation based on payment information and risk assessment reference information is performed by the server-side device, then after obtaining the payment risk assessment result, the server-side device determines whether there is a payment risk in the payment operation. If it determines that there is no payment risk, it sends a third notification message to the terminal device, allowing the terminal device to prompt the user to enter a payment password based on the third notification message. The terminal device can then send the payment password to the server-side device. After receiving the payment password, the server-side device can send a payment request carrying the payment password to the payment device, allowing the payment device to make payment for the transaction corresponding to the payment operation based on the payment password. After making payment for the transaction corresponding to the payment operation based on the payment password, the payment device can send a first notification message to the server-side device. Based on this, the server-side device can send a second notification message to the terminal device based on the first notification message to notify the terminal device that the transaction corresponding to the payment operation has been successfully paid. Based on this, the terminal device can display a successful payment result after receiving the second notification message.
[0077] In some embodiments, the payment device can be a server-side device of a financial institution such as a bank.
[0078] For example, the payment device can be a server-side device used to manage users' bank cards, e-wallets, etc.
[0079] In this embodiment, after detecting a payment operation on the first application, payment information corresponding to the payment operation, historical operation information of the first application, and historical operation information of the second application can be obtained. Since the second application and the first application are of the same type on the terminal device, the first historical operation information of the first application and the second historical operation information of the second application can, to some extent, reflect the user's usage habits of the first application and even similar applications over a historical period, thereby reflecting the probability of the user making a payment on the first application. Based on this, by combining payment information with the first historical operation information of the first application and / or the second historical operation information of the second application to conduct a risk assessment of the payment operation on the first application, the accuracy of the obtained payment risk assessment results can be improved.
[0080] In some embodiments, step 203 includes: displaying a payment interface in response to a payment risk assessment result indicating that there is no risk in the payment operation; and displaying a payment result indicating successful payment in response to obtaining a payment password.
[0081] Understandably, after receiving the payment risk assessment results, the terminal device can determine whether a payment operation carries any risk. If the terminal device determines that there is no payment risk, it can display a payment interface so that the user can enter their payment password. After receiving the entered payment password, the terminal device can display a successful payment result.
[0082] In some embodiments, the payment interface is used for users to enter payment passwords or for users to trigger the display of the payment password input interface.
[0083] For example, the payment interface includes, but is not limited to, a password input interface and an interface with preset controls. The preset controls are used to display the password payment interface upon user intervention.
[0084] In some embodiments, if the terminal device determines that there is no payment risk in the payment operation, it may display a password input interface and obtain the payment password entered by the user on the password input interface. The terminal device can then send the payment password to the server device.
[0085] In some embodiments, if the terminal device determines that there is no payment risk in the payment operation, it may display an interface with preset controls. Then, if the terminal device detects a triggering operation on a preset control on the interface with preset controls, it may display a password input interface. The terminal device may then obtain the payment password entered by the user on the password input interface and send the payment password to the server device.
[0086] In some embodiments, if the step of determining the payment risk assessment result of a payment operation based on payment information and risk assessment reference information is performed by the server device, then after obtaining the payment risk assessment result, if the server device determines that there is no payment risk in the transaction corresponding to the payment operation, it can send a third notification message to the terminal device, enabling the terminal device to display the payment interface based on the third notification message. Subsequently, the server device can receive the payment password sent by the terminal device and send a payment request carrying the payment password to the payment device.
[0087] In some embodiments, step 203 further includes: in response to a payment risk assessment result indicating that a payment operation is at risk, outputting a prompt message; wherein the prompt message is used to indicate that the transaction corresponding to the payment operation is prohibited from being paid.
[0088] Understandably, if a terminal device determines that a payment operation carries a risk based on the payment risk assessment results, it can output a prompt message to inform the user that the transaction corresponding to the current payment operation is prohibited from payment due to the risk.
[0089] In some embodiments, if the step of determining the payment risk assessment result of a payment operation based on payment information and risk assessment reference information is performed by the server-side device, then after obtaining the payment risk assessment result, the server-side device can determine whether the payment operation carries a payment risk based on the payment risk assessment result. If the terminal device determines that the payment operation carries a payment risk, it can send a fourth notification message to notify the terminal device of the payment risk. Based on this, the terminal device can output a prompt message after receiving the fourth notification message.
[0090] In some embodiments, the prompt message can be any type of prompt message, and this disclosure does not limit this.
[0091] For example, the prompts include, but are not limited to, text-based prompts and voice-based prompts.
[0092] The following embodiments can be executed by a terminal device or a server device. In the following text, the implementation process of the following embodiments will be described using a terminal device as an example.
[0093] In some embodiments, step 202 includes: determining the security level of the first application based on risk assessment reference information; and determining the payment risk assessment result based on payment information and the security level. The security level indicates the probability that a payment operation carries a payment risk.
[0094] Understandably, after receiving risk assessment reference information, the terminal device can determine the security level of the first application based on this information, thereby indicating the probability of payment risk in payment operations within that application. After obtaining the security level of the first application, the terminal device can then perform a risk assessment on the payment operation based on both the security level and the payment information to obtain the payment risk assessment result.
[0095] In some embodiments, the level of security is negatively correlated with the magnitude of payment risk in a payment operation.
[0096] In some embodiments, if the risk assessment reference information obtained by the terminal device is first historical operation information, the terminal device can determine the security level of the first application based on the first historical operation information. If the risk assessment reference information obtained by the terminal device is second historical operation information, the terminal device can determine the security level of the first application based on the second historical operation information. If the risk assessment reference information obtained by the terminal device includes both first historical operation information and second historical operation information, the terminal device can determine the security level of the first application based on both the first historical operation information and the second historical operation information.
[0097] In some embodiments, the terminal device may perform risk assessments on the payment operation based on payment information and the security level of the first application, and generate a first assessment result if the payment information indicates that the payment operation has a payment risk and / or the security level of the first application indicates that the payment operation has a payment risk. The terminal device may also generate a second assessment result if both the payment operation and the security level of the first application indicate that the payment operation has no payment risk.
[0098] In some embodiments, the terminal device may also input payment information and the security level of the first application into a trained risk assessment model, and perform a risk assessment on the payment operation through the risk assessment model to obtain the payment risk assessment result output by the risk assessment model.
[0099] In some embodiments, the terminal device may further input the payment information and the security level of the first application into a risk assessment model if it is determined through the payment information that there is no payment risk in the payment operation and through the security level of the first application that there is no payment risk in the payment operation, so as to further assess the risk of the payment operation through the risk assessment model.
[0100] In this embodiment, determining the security level of the first application based on risk assessment reference information enables the quantification of this information. Therefore, compared to directly assessing the risk of a payment operation based on payment information and the security level of the first application using a risk assessment model, this method reduces the amount of data the risk assessment model needs to process and improves its efficiency.
[0101] In some embodiments, the first historical running information includes the number of times a first application was launched and / or its runtime during a historical period, and the second historical running information includes the number of times a second application was launched and / or its runtime during a historical period. Determining the security level of the first application based on risk assessment reference information includes: determining a security value for the first application based on the number of launches and / or its runtime; and determining a security level based on the security value.
[0102] Understandably, the first historical running information obtained by the terminal device can be at least one of the number of times the first application was launched and the runtime of the first application during a historical period. The second historical running information obtained by the terminal device can be at least one of the number of times the second application was launched and the runtime of the second application during a historical period. Based on this, the terminal device can determine the security value of the first application based on at least one of the number of times the first application was launched and the runtime of the first application during a historical period, the number of times the second application was launched and the runtime of the second application during a historical period.
[0103] In some embodiments, the terminal device may further determine a first security value based on the number of times the first application was launched and the number of times the second application was launched during a historical period, and determine a second security value based on the runtime of the first application and the runtime of the second application during a historical period. Then, the terminal device may use the first security value, the second security value, or a weighted average of the first and second security values as the security value of the first application.
[0104] In some embodiments, the magnitude of the first security value is positively correlated with the number of times the first application was launched in a historical period and the number of times the second application was launched in a historical period.
[0105] In some embodiments, the magnitude of the second security value is positively correlated with the runtime of the first application during historical time and the runtime of the second application during historical time.
[0106] In some embodiments, a higher security value indicates a lower payment risk for the payment operation.
[0107] For ease of explanation, the first application and the second application will be collectively referred to as the first type of application in the following description.
[0108] In some embodiments, the terminal device may first calculate the average total number of launches of the first type of application per day over a historical period, and determine a first security value based on the obtained average total number of launches.
[0109] For example, when the first type of application includes application A (first application), application B (second application), and application C (second application), the terminal device can calculate the average total number of times application A, application B, and application C are launched per day over a historical period.
[0110] For example, a terminal device can obtain the total number of times application A, application B, and application C are launched over N days, and then divide the total number of launches by N to obtain the average total number of launches per day over N days. N is an integer greater than 0.
[0111] In some embodiments, the terminal device may first calculate the average total runtime of the first type of application over a historical period of time, and determine a second security value based on the obtained average total runtime.
[0112] For example, when the first type of application includes application A (first application), application B (second application), and application C (second application), the terminal device can calculate the average total runtime of application A, application B, and application C over a historical period of time.
[0113] For example, a terminal device can obtain the total runtime of application A, application B, and application C over N days, and divide the total runtime by N to obtain the average total runtime of application A, application B, and application C per day over N days.
[0114] In some embodiments, the terminal device may use the average total number of launches of the first type of application per day over a historical period as a first security value. The terminal device may use the average total runtime of the first type of application per day over a historical period as a second security value.
[0115] In some embodiments, the number of times the terminal device calculates the first security value can also be the number of times the first type of application is launched within multiple time periods in history.
[0116] It should be noted that the method for determining the average total number of launches per day for the first type of application within each time period can refer to the method for determining the average total number of launches per day described above, and will not be repeated here in this embodiment.
[0117] In some embodiments, the runtime of the terminal device for calculating the second security value may also be the runtime of the first type of application over multiple time periods in history.
[0118] It should be noted that the method for determining the average total runtime of the first type of application within each time period can refer to the method for determining the average total runtime of each day described above, and will not be repeated here in this disclosure.
[0119] It should be noted that the specific number of time periods and the start and end times of each time period can be set as needed, and this embodiment does not limit this.
[0120] For example, multiple time periods may include a second time period, a third time period, and a fourth time period. The third time period may be 30 days prior to the current time, and the fourth time period may be 60 days prior to the current time.
[0121] In some embodiments, the terminal device may calculate the first security value using the following formula (1):
[0122] S1 = 0.95 7×A +0.95 7×B +0.95 7×C (1);
[0123] Wherein, S1 is the first security value, A is the average total number of times the first type of application is launched per day in the second time period, B is the average total number of times the first type of application is launched per day in the third time period, and C is the average total number of times the first type of application is launched per day in the fourth time period.
[0124] In some embodiments, the terminal device may determine the second security value using the following formula (2):
[0125] S1 = 0.95 7×C +0.95 7×D +0.95 7×E (2);
[0126] Wherein, S1 is the first safety value, C is the average total runtime of the first type of application per day in the second time period, D is the average total runtime of the first type of application per day in the third time period, and E is the average total runtime of the first type of application per day in the fourth time period.
[0127] In some embodiments, the terminal device may store a first mapping relationship, wherein the first mapping relationship is a mapping relationship between security value ranges and security levels, and each security value range corresponds to a security level. Based on this, after obtaining the security value of the first application, the terminal device can determine the security value range in which the security value of the first application lies, and determine the security level corresponding to the security value range in which the security value of the first application lies as the security level of the first application.
[0128] In some embodiments, after obtaining the security value of the first application, the terminal device can further normalize the security value of the first application to obtain a normalized security value. Then, the terminal device can determine the security level of the first application based on the normalized security value.
[0129] In some embodiments, Figure 4 This is a schematic diagram illustrating a security level for a first application according to an exemplary embodiment. The first mapping relationship may include 10 security levels. Figure 4 The diagram illustrates the security level of a first application determined by the method provided in this disclosure embodiment in several scenarios involving payment operations initiated by different types of first applications on a terminal device.
[0130] It should be noted that the implementation method of determining the security level of the first application based on the normalized security value can refer to the above-described implementation method of determining the security level of the first application based on the security value of the first application, and this disclosure embodiment does not limit it.
[0131] In some embodiments, the first historical running information includes the installation time of the first application and / or the most recent running time of the first application; determining the security level of the first application based on risk assessment reference information includes: determining the first interval duration between the installation time of the first application and the current time; and determining the security level of the first application based on the first interval duration and / or the most recent running time of the first application.
[0132] Understandably, the first historical operation information obtained by the terminal device can be at least one of the installation time of the first application on the terminal device and the runtime of the first application's most recent execution on the terminal device. If the first historical operation information is the installation time of the first application on the terminal device, the terminal device can determine the first interval between the installation time of the first application on the terminal device and the current time. Then, the terminal device can determine the security level of the first application based on the obtained first interval. The level of security is positively correlated with the length of the first interval. If the first historical operation information is the runtime of the first application's most recent execution on the terminal device, the terminal device can determine the security level of the first application based on the runtime of the most recent execution. The level of security is negatively correlated with the runtime of the most recent execution. If the first historical operation information obtained by the terminal device includes both the first interval and the runtime of the first application's most recent execution, then the terminal device can determine one security level based on the first interval and another security level based on the runtime of the most recent execution. In this case, the terminal device can obtain two security levels.
[0133] In some embodiments, the terminal device may store a second mapping relationship. The second mapping relationship is a mapping relationship between the interval duration range and the security level. Based on this, after obtaining the first interval duration, the terminal device can find the interval duration range in the second mapping relationship where the first interval duration falls, and use the security level corresponding to the interval duration range where the first interval duration falls as the security level of the first application.
[0134] For example, the second mapping relationship may include: a first security level corresponding to a first interval duration range, a second security level corresponding to a second interval duration range, and a third security level corresponding to a third interval duration range. Based on this, if the terminal device determines that the first interval duration between the installation time of the first application on the terminal device and the current time falls within the second interval duration range, then the second security level can be determined as the security level of the first application. The upper limit of the first interval duration range is less than the lower limit of the second interval duration range, and the upper limit of the second interval duration range is greater than the lower limit of the third interval duration range. The security of the third security level is greater than the security of the second security level, and the security of the second security level is greater than the security of the first security level.
[0135] For example, the first interval duration is greater than or equal to 0 hours and less than 72 hours, the second interval duration is greater than or equal to 72 hours and less than 168 hours, and the third interval duration is greater than or equal to 168 hours.
[0136] In some embodiments, the terminal device may also store a third mapping relationship. The third mapping relationship is a mapping relationship between runtime range and security level. Based on this, after obtaining the most recent runtime of the first application, the terminal device can find the runtime range of the most recent runtime from the third mapping relationship, and use the security level corresponding to the runtime range as the security level of the first application.
[0137] For example, the third mapping relationship may include: a third security level corresponding to a first runtime range, a second security level corresponding to a second runtime range, and a first security level corresponding to a third runtime range. Based on this, if the terminal device determines that the most recent runtime of the first application falls within the first runtime range, it can determine the third security level corresponding to the first runtime range as the security level of the first application. The upper limit of the first runtime range is less than the lower limit of the second runtime range, and the upper limit of the second runtime range is greater than the lower limit of the third runtime range.
[0138] For example, the first runtime range is greater than or equal to 0 hours and less than 24 hours, the second runtime range is greater than or equal to 24 hours and less than 72 hours, and the third runtime range is greater than or equal to 72 hours.
[0139] In this embodiment of the disclosure, considering user operations on applications on a terminal device, users operate the applications according to their needs and do not keep an application running continuously. However, operating an application via a script can keep the application running for a long time. Therefore, if the runtime of the first application is too long, it may be that a script is controlling the first application, and payment operations initiated by a script-controlled first application generally carry a higher risk. Therefore, when determining whether a payment operation initiated by the first application carries a payment risk, referring to the runtime of the first application can further improve the accuracy of risk assessment.
[0140] Furthermore, considering that a short interval between the installation time of the first application on the terminal device and the current time indicates that the first application is newly installed on the terminal device, and users typically have lower trust in new and secure applications, the likelihood of a user placing an order through a newly installed application is usually relatively low. Therefore, when determining whether a payment operation initiated based on the first application poses a payment risk, referring to the shortest interval between the installation time of the first application on the terminal device and the current time can further improve the accuracy of risk assessment.
[0141] In some embodiments, a payment risk assessment result is determined based on payment information and security level, including at least one of the following: in response to the existence of multiple payment information, and the number of payment information that meets preset conditions among the multiple payment information reaches a first quantity threshold, it is determined that the payment operation has a risk; in response to the security level not reaching the level threshold, it is determined that the payment operation has a risk.
[0142] Understandably, a terminal device can receive multiple payment information entries. Based on this, the terminal device can determine the number of payment entries that meet preset conditions. If the number of payment entries meeting the preset conditions reaches a preset quantity, the terminal device can determine that the payment operation initiated through the first application carries a payment risk. Furthermore, after determining the security level of the first application based on the above steps, the terminal device can also determine whether the security level reaches a certain threshold. If the terminal device determines that the security level of the first application does not reach the threshold, it can also determine that the payment operation initiated through the first application carries a payment risk.
[0143] In some embodiments, when the payment information includes the account information of the user account logged in on the first application when the payment operation is triggered, and the payment amount of the payment operation, the terminal device can determine whether the user account is a newly registered account based on the account information of the initiating user account. If the user account logged in on the first application when the payment operation is triggered is a newly registered account, the terminal device can further determine whether the payment amount is greater than a first amount threshold. If the payment amount is greater than the first amount threshold, the terminal device can determine that the user account and the payment amount meet preset conditions. If the user account logged in on the first application when the payment operation is triggered is not a newly registered account and / or the payment amount is less than or equal to the first amount threshold, the terminal device can determine that the user account logged in on the first application when the payment operation is triggered does not meet preset conditions.
[0144] In some embodiments, the terminal device can obtain the registration time of the user account logged in on the first application when the payment operation is triggered, and determine a second interval between the registration time of the user account and the current time. If the second interval is less than or equal to a duration threshold, the terminal device can determine that the user account is a newly registered account.
[0145] In some embodiments, the duration threshold and the first amount threshold can be determined as needed, and this disclosure does not limit them.
[0146] For example, the duration threshold can be any duration from 1 minute to 7 days. For example, 1 minute, 5 minutes, 1 hour, 1 day, 3 days, 5 days, 7 days, etc.
[0147] For example, the first amount threshold can be any amount between 5,000 yuan and 50,000 yuan. For example, 5,000 yuan, 10,000 yuan, 15,000 yuan, 30,000 yuan, 50,000 yuan, etc.
[0148] In some embodiments, the terminal device may also determine whether the user account is a newly registered account based on the historical payment records of the user account logged in on the first application when the payment operation is triggered. For example, if the number of historical payment records of the user account is less than or equal to a second quantity threshold, the terminal device may determine that the user account is a newly registered account.
[0149] In some embodiments, the size of the second quantity threshold can also be determined as needed, and this disclosure does not limit this.
[0150] For example, the second quantity threshold can be any value from 2 to 20. For example, the second quantity threshold can be 2, 3, 5, 8, 10, 15, 18, 20, etc.
[0151] It should be noted that the above is only an example of how to determine whether the user account initiating the payment operation is a newly registered account, and does not constitute a limitation on the method of determining whether the user account initiating the payment operation is a newly registered account.
[0152] In some embodiments, if the payment information is the account information of a user account logged in on the first application when the payment operation is triggered, and the number of transactions within a first time period, the terminal device can determine whether the number of transactions for that user account within the first time period has reached a preset number. If the number of transactions for that user account within the first time period has reached the preset number, the terminal device can determine that the number of transactions for that user account within the first time period meets a preset condition. If the number of transactions for that user account within the first time period has not reached the preset number, the terminal device can determine that the number of transactions for that user account within the first time period does not meet the preset condition.
[0153] In some embodiments, if the payment information is the transaction amount of a user account logged in on the first application during a second time period when the payment operation is triggered, the terminal device can determine whether the transaction amount of the user account during the second time period reaches a second amount threshold. If the transaction amount of the user account during the second time period has reached the second amount threshold, the terminal device can determine that the transaction amount of the user account during the second time period meets a preset condition. If the transaction amount of the user account during the second time period has not reached the second amount threshold, the terminal device can determine that the transaction amount of the user account during the second time period does not meet the preset condition.
[0154] In some embodiments, when the payment information consists of the system address of the terminal device and the delivery address of the goods for which payment is requested, the terminal device can determine whether the system address and the delivery address are located in the same country. If the terminal device determines that the system address and the delivery address are located in different countries, it determines that the system address and the delivery address meet a preset condition. If the terminal device determines that the system address and the delivery address are located in different countries, it determines that the system address and the delivery address do not meet the preset condition.
[0155] In some embodiments, the system address of the terminal device can be the country information set by the user in the operating system of the terminal device.
[0156] In some embodiments, the first quantity threshold can be an integer greater than or equal to 1 and less than the total number of payment information.
[0157] In some embodiments, the level threshold may need to be set, but this disclosure does not limit this.
[0158] For example, the level threshold can be any value from level five to level ten. For instance, the level threshold can be level five, level six, level eight, level ten, etc.
[0159] In some embodiments, when multiple security levels are determined, the terminal device can determine whether each security level reaches a corresponding level threshold. If the number of security levels reaching the level threshold is less than a third quantity threshold, the terminal device determines that the payment operation initiated through the first application has a payment risk. If the number of security levels reaching the level threshold is greater than or equal to the third quantity threshold, the terminal device determines that the payment operation initiated through the first application does not have a payment risk.
[0160] For example, the multiple security levels may include one or more security levels determined based on first historical operational information, and one or more security levels determined based on second historical operational information.
[0161] For example, if the first historical running information is the installation time and / or the most recent runtime of the first application, the security level threshold can be level three. Based on this, if the first interval is less than 168 hours, it is determined that the security level of the first application has not reached the security level threshold; if the first interval is greater than or equal to 168 hours, it is determined that the security level of the first application has reached the security level threshold. If the most recent runtime of the first application is greater than or equal to 24 hours, it is determined that the security level of the first application has not reached the security level threshold; if the most recent runtime of the first application is less than 24 hours, it is determined that the security level of the first application has reached the security level threshold.
[0162] In some embodiments, determining the payment risk assessment result based on payment information and security level further includes: in response to the fact that the number of payment information meeting preset conditions has not reached a first quantity threshold and the security level has reached a level threshold, determining the payment risk assessment result through a risk assessment model based on the payment information and security level.
[0163] Understandably, if the number of payment information items meeting the preset conditions does not reach the first quantity threshold, and the security level of the first application has reached the level threshold, the terminal device can input the payment information and security level into the risk assessment model to conduct a risk assessment of the payment operation. At this time, the terminal device can obtain the payment risk assessment result output by the risk assessment model.
[0164] In some embodiments, if the number of payment information that meets the preset conditions does not reach the first quantity threshold, and the security level of the first application has reached the level threshold, the terminal device may also input the payment information and risk assessment reference information into the risk assessment model to conduct risk assessment on the payment operation through the risk assessment model, and the terminal device may also obtain the payment risk assessment result output by the risk assessment model.
[0165] In some embodiments, when there are multiple security levels, if the number of payment information that meets the preset conditions does not reach the first quantity threshold, but the number of security levels that reach the level threshold is greater than or equal to the third quantity threshold, the payment information and risk assessment reference information can be input into the risk assessment model to conduct a security assessment of the payment operation through the risk assessment model, and the terminal device can also obtain the payment risk assessment result output by the risk assessment model.
[0166] In some embodiments, when there are multiple security levels, if the number of payment information that meets the preset conditions does not reach the first quantity threshold, but the number of security levels that reach the level threshold is greater than or equal to the third quantity threshold, the terminal device can also input the payment information and the security level of the first application into the risk assessment model, so as to conduct a security assessment of the payment operation through the risk assessment model, and the terminal device can also obtain the payment risk assessment result output by the risk assessment model.
[0167] In some embodiments, the method further includes: obtaining payment results; and training a risk assessment model based on payment information, security level, and payment results.
[0168] Understandably, the terminal device can also obtain the payment result from the payment device's processing of the payment operation. After obtaining the payment result, the terminal device can also train a risk assessment model based on the payment result, combined with payment information and security level.
[0169] In some embodiments, the terminal device can train the risk assessment model based on payment information, security level, and payment result according to a preset period.
[0170] In some embodiments, when performing risk assessment, if the terminal device inputs payment information and risk assessment reference information into the risk assessment model, the terminal device can train the risk assessment model based on the payment result, payment information, and risk assessment reference information after obtaining the payment result.
[0171] In some embodiments, when performing risk assessment, if the terminal device inputs payment information and security level into the risk assessment model, the terminal device can train the risk assessment model based on the payment result, payment information, and security level after obtaining the payment result.
[0172] In this embodiment of the disclosure, the terminal device trains the risk assessment model according to a preset period based on the payment information corresponding to the payment operation, the security level (or risk assessment reference information) corresponding to the payment operation, and the payment result corresponding to the payment operation, which can improve the accuracy of the risk assessment model in judging the payment risk of the payment operation.
[0173] Figure 5 This is a flowchart illustrating a method for determining payment risk according to another exemplary embodiment. Figure 6 This is a schematic diagram illustrating a payment system according to an exemplary embodiment. In the following text, it will be combined with... Figure 5 and Figure 6 Yes, taking the interaction between terminal devices and server devices as an example, the method for determining payment risk provided in the above embodiments will be further described as follows:
[0174] In step 501, in response to the terminal device 101 detecting a payment operation on the first application 1011, the terminal device initiates a payment request to the server device 102 and carries payment information in the payment request.
[0175] In step 502, the server device 102 determines whether the payment information meets the corresponding preset conditions.
[0176] In step 503, the server device 102 retrieves data from the system layer of the terminal device 101. Figure 5 Obtain risk assessment reference information from Android system 1013.
[0177] In step 504, the server device 102 determines the security level of the first application based on the obtained risk assessment reference information.
[0178] In step 505, the server device 102 determines, through the rule matching module 1022, whether the security level of the first application has reached the level threshold, and whether the number of payment information that meets the preset conditions has reached the first quantity threshold.
[0179] In step 506, in response to the fact that the number of payment information that meets the preset conditions has not reached the first quantity threshold and the security level of the first application has reached the level threshold, the server device can input the payment information and security level into the model recognition module 1023, so as to perform risk assessment on the payment operation through the risk assessment model in the model recognition module 1023, so as to obtain the payment risk assessment result.
[0180] In step 507, if the payment risk assessment result indicates that there is no payment risk in the payment operation, the server device 102 can initiate a deduction request to the payment device 103.
[0181] In step 508, the server device 102 receives the payment result returned by the payment device 103.
[0182] In step 509, the server device 102 sends the payment result to the terminal device 101.
[0183] The payment process is now complete.
[0184] Figure 6 The terminal device or server device shown also includes a rule configuration module 1024 and a model training module 1025. The rule configuration module 1024 is used to modify the level threshold, first quantity threshold, etc., stored in the rule matching module; the model training module 1025 is used to train the risk assessment model based on the payment result, security level, and payment information.
[0185] Figure 7 This is a block diagram illustrating a payment risk determination device according to an exemplary embodiment. Figure 7 As shown, the device includes: a first acquisition module 701, configured to acquire payment information corresponding to the payment operation in response to triggering a payment operation of a first application; a determination module 702, configured to determine the payment risk assessment result of the payment operation based on the payment information and risk assessment reference information; wherein the risk assessment reference information includes first historical operation information related to the first application and / or second historical operation information related to the second application, and the first application and the second application are applications of the same type; and a display module 703, configured to display the payment result of the payment operation based on the payment risk assessment result; the payment result is used to indicate whether the payment for the transaction corresponding to the payment operation was successfully completed.
[0186] In some embodiments, the display module 703 is configured to: display a payment interface in response to a payment risk assessment result indicating that there is no risk in the payment operation; wherein the payment interface is used for the user to enter a payment password or for the user to trigger the display of a payment password input interface; and display a payment result indicating successful payment in response to obtaining the payment password.
[0187] In some embodiments, the display module 703 is configured to output a prompt message in response to a payment risk assessment result indicating that a payment operation is at risk; wherein the prompt message is used to indicate that the transaction corresponding to the payment operation is prohibited from being paid.
[0188] In some embodiments, the determining module 702 is configured to: determine the security level of a first application based on risk assessment reference information, wherein the security level is used to indicate the probability that a payment operation has a payment risk; and determine the payment risk assessment result based on the payment information and the security level.
[0189] In some embodiments, the first historical running information includes the number of times the first application was launched and / or the runtime of the first application in a historical time period, and the second historical running information includes the number of times the second application was launched and / or the runtime of the second application in a historical time period; wherein, the determining module 702 is configured to: determine the security value of the first application based on the number of launches and / or the runtime; and determine the security level based on the security value.
[0190] In some embodiments, the first historical running information includes the installation time of the first application and / or the most recent running duration of the first application; wherein, the determining module 702 is configured to: determine the first interval duration between the installation time of the first application and the current time; and determine the security level of the first application based on the first interval duration and / or the most recent running duration of the first application.
[0191] In some embodiments, the determining module 702 is configured to: determine that a payment operation is risky in response to the fact that there are multiple payment information and the number of payment information that meets preset conditions among the multiple payment information reaches a first quantity threshold; or determine that a payment operation is risky in response to the fact that the security level does not reach a level threshold.
[0192] In some embodiments, the determining module 702 is configured to: in response to the fact that the number of payment information that meets preset conditions has not reached a first quantity threshold and the security level has reached a level threshold, determine the payment risk assessment result based on the payment information and the security level through a risk assessment model.
[0193] In some embodiments, the apparatus further includes: a second acquisition module configured to acquire a payment result; and to train a risk assessment model based on payment information, security level, and payment result. The specific manner in which each module performs its operations has been described in detail in the embodiments relating to the method, and will not be elaborated upon here.
[0194] Figure 8 This is a structural block diagram illustrating a terminal device 800 according to an exemplary embodiment. Exemplarily, the terminal device 800 can be the terminal device in the above embodiments. For example, the terminal device 800 can be a mobile phone, tablet computer, smartwatch, in-vehicle device, or other communication device.
[0195] Reference Figure 8 The terminal device 800 may include one or more of the following components: processing component 802, memory 804, power supply component 806, multimedia component 808, audio component 810, input / output (I / O) interface 812, sensor component 814, and communication component 816.
[0196] Processing component 802 typically controls the overall operation of terminal device 800, such as operations associated with at least one of display, telephone call, data communication, camera operation, and recording operation. Processing component 802 may include one or more processors 820 to execute instructions to complete all or part of the steps of the methods performed by the terminal device described above. Furthermore, processing component 802 may include one or more modules to facilitate interaction between processing component 802 and other components. For example, processing component 802 may include a multimedia module to facilitate interaction between multimedia component 808 and processing component 802.
[0197] Memory 804 is configured to store various types of data to support operation on terminal device 800. Examples of such data include at least one of the following: instructions for any application or method operating on terminal device 800, contact data, phonebook data, messages, pictures, and videos. Memory 804 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 storage, flash memory, magnetic disk, or optical disk.
[0198] Power supply component 806 provides power to various components of terminal device 800. Power supply component 806 may include at least one of the following: a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to terminal device 800.
[0199] Multimedia component 808 includes a screen that provides an output interface between terminal device 800 and the user. In some embodiments, the screen may include a Liquid Crystal Display (LCD) and a Touch Panel (TP). If the screen includes a Touch Panel, the screen may be implemented as a touchscreen to receive input signals from the user. The Touch Panel includes one or more touch sensors to sense touches, swipes, and gestures on the Touch Panel. The touch sensors may sense not only the boundaries of touch or swipe actions but also the duration and pressure associated with the touch or swipe operation. In some embodiments, multimedia component 808 includes a front-facing camera and / or a rear-facing camera. When terminal device 800 is in an operating mode, such as a shooting mode or video mode, the front-facing camera and / or rear-facing camera may receive external multimedia data. Each front-facing camera and rear-facing camera may be a fixed optical lens system or have focal length and optical zoom capabilities.
[0200] Audio component 810 is configured to output and / or input audio signals. For example, audio component 810 includes a microphone (MIC) configured to receive external audio signals when terminal device 800 is in an operating mode, such as call mode, recording mode, and voice recognition mode. The received audio signals may be further stored in memory 804 or transmitted via communication component 816. In some embodiments, audio component 810 also includes a speaker for outputting audio signals.
[0201] I / O interface 812 provides an interface between processing component 802 and peripheral interface modules, such as keyboards, click wheels, and buttons. These buttons may include, but are not limited to, home buttons, volume buttons, power buttons, and lock buttons.
[0202] Sensor assembly 814 includes one or more sensors for providing state assessments of various aspects of terminal device 800. For example, sensor assembly 814 can detect the on / off state of terminal device 800, the relative positioning of components such as the display and keypad of terminal device 800, changes in position of terminal device 800 or one of its components, the presence or absence of user contact with terminal device 800, orientation or acceleration / deceleration of terminal device 800, and temperature changes of terminal device 800. Sensor assembly 814 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. Sensor assembly 814 may also include an optical sensor, such as a complementary metal-oxide-semiconductor (CMOS) or charge-coupled device (CCD) image sensor, for use in imaging applications. In some embodiments, sensor assembly 814 may also include, but is not limited to, at least one of the following: an accelerometer, a gyroscope, a magnetometer, a pressure sensor, and a temperature sensor.
[0203] Communication component 816 is configured to facilitate wired or wireless communication between terminal device 800 and other devices. Terminal device 800 can access wireless networks based on communication standards, such as Wi-Fi, 4G, 5G, or combinations thereof. In one exemplary embodiment, communication component 816 receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, communication component 816 also includes a Near Field Communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on Radio Frequency Identification (RFID), Infrared Data Association (IrDA), Ultra Wide Band (UWB), Bluetooth (BT), and other technologies.
[0204] In an exemplary embodiment, the terminal device 800 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components.
[0205] A non-transitory computer-readable storage medium, when the instructions in the storage medium are executed by a processor of a terminal device, enables the terminal device to perform any of the payment risk determination methods described in the embodiments of this disclosure. For example, the method includes:
[0206] In response to triggering a payment operation in the first application, the system obtains the payment information corresponding to the payment operation; based on the payment information and risk assessment reference information, it determines the payment risk assessment result of the payment operation; wherein, the risk assessment reference information includes first historical operation information related to the first application and / or second historical operation information related to the second application, and the first application and the second application are applications of the same type; based on the payment risk assessment result, the system displays the payment result of the payment operation; the payment result is used to indicate whether the payment for the transaction corresponding to the payment operation was successfully completed.
[0207] Figure 9 This is a block diagram illustrating a server-side device 900 according to another exemplary embodiment. For example, the server-side device 900 may be provided as a server. (Refer to...) Figure 9 The server-side device 900 includes a processing component 922, which further includes one or more processors, and memory resources represented by a memory 932 for storing instructions, such as application programs, that can be executed by the processing component 922. The application programs stored in the memory 932 may include one or more modules, each corresponding to a set of instructions. Furthermore, the processing component 922 is configured to execute instructions to perform the steps performed by the server-side device in the aforementioned method for determining payment risk.
[0208] The server device 900 may also include a power supply component 926 configured to perform power management of the server device 900, a wired or wireless network interface 950 configured to connect the server device 900 to a network, and an input / output (I / O) interface 958. The server device 900 can operate an operating system stored in memory 932, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, or similar.
[0209] This disclosure provides a computer program product comprising a computer program or executable instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer program or executable instructions from the computer-readable storage medium and executes the computer program or executable instructions, causing the computer device to perform any of the payment risk determination methods described in this disclosure.
[0210] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the claims.
[0211] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.
Claims
1. A method for determining payment risk, characterized in that, The method includes: In response to triggering a payment operation in the first application, obtain the payment information corresponding to the payment operation; Based on the payment information and risk assessment reference information, the payment risk assessment result of the payment operation is determined; wherein, the risk assessment reference information includes first historical operation information related to a first application and / or second historical operation information related to a second application, and the first application and the second application are applications of the same type; Based on the payment risk assessment results, the payment result of the payment operation is displayed; the payment result is used to indicate whether the payment for the transaction corresponding to the payment operation was successfully completed.
2. The method according to claim 1, characterized in that, The payment result of the payment operation, based on the payment risk assessment result, is displayed, including: In response to the payment risk assessment result indicating that the payment operation is risk-free, a payment interface is displayed; wherein, the payment interface is used for the user to enter a payment password or for the user to trigger the display of a payment password input interface; In response to obtaining the payment password, a payment result indicating successful payment is displayed.
3. The method according to claim 2, characterized in that, The step of displaying the payment result of the payment operation based on the payment risk assessment result also includes: In response to the payment risk assessment result indicating that the payment operation is risky, a prompt message is output; The notification message is used to indicate that the transaction corresponding to the payment operation is prohibited from being paid.
4. The method according to any one of claims 1 to 3, characterized in that, The process of determining the payment risk assessment result of the payment operation based on the payment information and risk assessment reference information includes: Based on the risk assessment reference information, the security level of the first application is determined, wherein the security level is used to indicate the probability that the payment operation has a payment risk; Based on the payment information and the security level, the payment risk assessment result is determined.
5. The method according to claim 4, characterized in that, The first historical running information includes the number of times the first application was launched and / or the runtime of the first application in a historical time period, and the second historical running information includes the number of times the second application was launched and / or the runtime of the second application in a historical time period. The step of determining the security level of the first application based on the risk assessment reference information includes: The security value of the first application is determined based on the number of launches and / or runtime. The security level is determined based on the security value.
6. The method according to claim 4, characterized in that, The first historical running information includes the installation time of the first application and / or the most recent running duration of the first application; The step of determining the security level of the first application based on the risk assessment reference information includes: Determine the duration of the first interval between the installation time of the first application and the current time; The security level of the first application is determined based on the first interval duration and / or the most recent runtime of the first application.
7. The method according to claim 4, characterized in that, The determination of the payment risk assessment result based on the payment information and the security level includes at least one of the following: If the number of payment information is multiple, and the number of payment information that meets the preset conditions among the multiple payment information reaches a first quantity threshold, it is determined that the payment operation is risky; If the security level does not reach the threshold, it is determined that the payment operation poses a risk.
8. The method according to claim 7, characterized in that, The step of determining the payment risk assessment result based on the payment information and the security level further includes: In response to the fact that the number of payment information that meets the preset conditions does not reach a first quantity threshold and the security level has reached a level threshold, the payment risk assessment result is determined by a risk assessment model based on the payment information and the security level.
9. The method according to claim 8, characterized in that, The method further includes: Obtain the payment result; The risk assessment model is trained based on the payment information, the security level, and the payment result.
10. A device for determining payment risk, characterized in that, The device includes: The first acquisition module is configured to acquire payment information corresponding to the payment operation in response to the payment operation triggered by the first application. The determination module is configured to determine the payment risk assessment result of the payment operation based on the payment information and risk assessment reference information; wherein, the risk assessment reference information includes first historical operation information related to a first application and / or second historical operation information related to a second application, and the first application and the second application are applications of the same type; The display module is configured to display the payment result of the payment operation based on the payment risk assessment result; the payment result is used to indicate whether the payment for the transaction corresponding to the payment operation was successfully completed.
11. An electronic device, characterized in that, include: processor; Memory used to store computer programs or instructions; The processor executes the computer program or instructions to implement the steps of the method according to any one of claims 1 to 9.
12. A non-transitory computer-readable storage medium storing a computer program or instructions, characterized in that, When the computer program or instructions in the storage medium are executed by a processor, the steps of the method according to any one of claims 1 to 9 are implemented.
13. A computer program product, comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by a processor, they implement the steps of the method according to any one of claims 1 to 9.