Secure payment method, device and apparatus, and storage medium

Abstract

The present application relates to the technical field of payment security. Disclosed are a secure payment method, device and apparatus, and a storage medium. The method comprises: when it is detected that a payment behavior of a user is a risk payment behavior, sending a confirmation request to a collaborative payer corresponding to the user; receiving first verification information uploaded by the user, wherein the first verification information is obtained by signing user payment information by means of a first collaborative payment key; receiving second verification information fed back by the collaborative payer according to the confirmation request, wherein the second verification information is obtained by signing the user payment information by means of a second collaborative payment key; performing security verification on the payment behavior according to the first verification information and the second verification information; and after the verification is passed, performing secure payment according to the payment behavior.

Description

Secure payment method, device, storage medium and apparatus

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to Chinese Patent Application No. 202310913800.1 filed in China on July 24, 2023, the entire contents of which are incorporated herein by reference. Technical Field

[0003] The present application relates to the field of payment security technology, and in particular to a secure payment method, device, storage medium and apparatus. Background Art

[0004] With the rapid development of technology and the improvement of people's living standards, mobile payment has gradually become an indispensable transaction method for modern people. While this payment method is becoming increasingly popular, it also brings some hidden dangers to our personal property and life, and breeds many payment scams.

[0005] However, most of the anti-fraud methods in related technologies protect users from aspects such as publicity and filtering, and cannot prevent users from being deceived at the source, resulting in poor anti-fraud effects.

[0006] Summary of the Invention

[0007] The main purpose of this application is to provide a secure payment method, equipment, storage medium and device, aiming to solve the technical problem that most anti-fraud methods in related technologies protect users from publicity, filtering and other aspects, but cannot prevent users from being deceived from the root, resulting in poor anti-fraud effect.

[0008] To achieve the above objectives, the present application provides a secure payment method, which includes the following steps:

[0009] When detecting that the user's payment behavior is a risky payment behavior, sending a confirmation request to the co-payer corresponding to the user;

[0010] Receiving first verification information uploaded by the user, where the first verification information is obtained by signing the user's payment information using a first collaborative payment key;

[0011] receiving second verification information fed back by the collaborative payer in response to the confirmation request, where the second verification information is obtained by signing the user payment information using a second collaborative payment key;

[0012] Performing security verification on the payment behavior according to the first verification information and the second verification information;

[0013] After verification is passed, secure payment is performed according to the payment behavior.

[0014] Optionally, the secure payment method further includes:

[0015] When a user's payment behavior is detected, determine whether the merchant type the user is currently paying to is the designated payment type corresponding to the user's age;

[0016] If so, obtaining a base amount for the specified payment type, and determining a credit limit threshold based on a ratio between the base amount and a credit limit threshold for the specified payment type, where the credit limit threshold ratio is predetermined based on the user's basic information, balance information, and user operations;

[0017] Determining whether the payment amount of the payment behavior exceeds the limit threshold;

[0018] Based on the judgment result, it is detected whether the payment behavior of the user is a risky payment behavior.

[0019] Optionally, the secure payment method further includes:

[0020] Calculate the basic security level coefficient of the specified payment type corresponding to the user's age based on the user's basic information and a preset security factor model;

[0021] Determining the user's basic security amount based on the user's balance information;

[0022] Calculate the amount threshold ratio of the specified payment type corresponding to the user's age based on the basic security level coefficient and the basic security amount;

[0023] The credit limit threshold ratio is adjusted according to user operations.

[0024] Optionally, adjusting the credit limit threshold ratio according to a user operation includes:

[0025] When the user operation is to lower the credit limit threshold ratio, adjusting the credit limit threshold ratio according to the user operation;

[0026] When the user operation is to increase the credit limit threshold ratio, a confirmation message is sent to the co-payer corresponding to the user;

[0027] When the collaborative payer is a single person, the credit limit threshold ratio is adjusted based on the confirmation operation fed back by the collaborative payer;

[0028] When there are multiple collaborative payers, a target collaborative payer is determined according to the collaborative levels of the multiple collaborative payments, and the amount threshold ratio is adjusted based on the confirmation operation fed back by the target collaborative payer.

[0029] Optionally, the secure payment method further includes:

[0030] The user payment information is signed using a collaborative payment key based on an improved Schnorr algorithm (a digital signature algorithm), wherein the improved Schnorr algorithm adds a random number on the basis of the Schnorr algorithm, and the collaborative payment key includes a first collaborative payment key and a second collaborative payment key.

[0031] Optionally, the secure payment method further includes:

[0032] After detecting that the user has enabled the secure payment function, a normal payment key and a collaborative payment key are generated based on the user information. The normal payment key is used to sign and verify the user's payment information when the user's payment behavior is a normal payment behavior. The collaborative payment key includes a first collaborative payment key and a second collaborative payment key. The first collaborative payment key is stored in the user terminal.

[0033] The collaborative payer corresponding to the user is set according to the setting information of the user, and the second collaborative payment key is sent to the collaborative payer.

[0034] Optionally, when detecting that the user's payment behavior is a risky payment behavior, sending a confirmation request to the co-payer corresponding to the user includes:

[0035] When a user's payment behavior is detected as a risky payment behavior, the corresponding co-payer of the user is determined based on the payment scenario and the co-payer's collaboration level in different scenarios. The collaboration level is determined based on the basic information of the user, the basic information of the co-payer, and the degree of interaction between the user and the co-payer.

[0036] Send a confirmation request to the co-payer corresponding to the user.

[0037] Optionally, when detecting that the user's payment behavior is a risky payment behavior, sending a confirmation request to the co-payer corresponding to the user includes:

[0038] When detecting that a user's payment behavior is a risky payment behavior, obtaining the payment account corresponding to the payment behavior;

[0039] The co-payer corresponding to the user is determined according to the payment account, and a confirmation request is sent to the co-payer corresponding to the user.

[0040] In addition, to achieve the above-mentioned purpose, the present application also proposes a secure payment device, which includes a memory, a processor, and a secure payment program stored on the memory and executable on the processor, wherein the secure payment program is configured to implement the secure payment method described above.

[0041] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, on which a secure payment program is stored. When the secure payment program is executed by a processor, the secure payment method as described above is implemented.

[0042] In addition, to achieve the above-mentioned purpose, the present application also proposes a secure payment device, which includes: a request collaboration module, an information receiving module, a security verification module and a secure payment module;

[0043] The request coordination module is configured to send a confirmation request to the coordinated payer corresponding to the user when detecting that the user's payment behavior is a risky payment behavior;

[0044] The information receiving module is configured to receive first verification information uploaded by the user, where the first verification information is obtained by signing the user's payment information using the first collaborative payment key;

[0045] The information receiving module is further configured to receive second verification information fed back by the collaborative payer in response to the confirmation request, where the second verification information is obtained by signing the user payment information using a second collaborative payment key;

[0046] The security verification module is used to perform security verification on the payment behavior based on the first verification information and the second verification information;

[0047] The secure payment module is used to perform secure payment according to the payment behavior after verification.

[0048] In the present application, it is disclosed that when it is detected that the user's payment behavior is a risky payment behavior, a confirmation request is sent to the collaborative payer corresponding to the user, the first verification information uploaded by the user is received, the first verification information is obtained by signing the user's payment information through the first collaborative payment key, the second verification information fed back by the collaborative payer according to the confirmation request is received, the second verification information is obtained by signing the user's payment information through the second collaborative payment key, the payment behavior is securely verified according to the first verification information and the second verification information, and after the verification is passed, a secure payment is made according to the payment behavior; since the present application completes the payment process under the supervision of the collaborative payer corresponding to the user when it is detected that the user's payment behavior is a risky payment behavior, it can prevent the user from being deceived from the root, and thus can effectively reduce the occurrence of users transferring money due to being deceived, effectively improve the security level of user payments, and protect the safety of users' personal assets. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] FIG1 is a schematic diagram of the structure of a secure payment device in a hardware operating environment according to an embodiment of the present application;

[0050] FIG2 is a flow chart of a first embodiment of a secure payment method provided by an embodiment of the present application;

[0051] FIG3 is a flow chart of a second embodiment of a secure payment method provided in an embodiment of the present application;

[0052] FIG4 is a flow chart of a third embodiment of a secure payment method provided in an embodiment of the present application;

[0053] FIG5 is a flow chart of a fourth embodiment of a secure payment method provided in an embodiment of the present application;

[0054] FIG6 is a structural block diagram of the first embodiment of the secure payment device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0055] It should be understood that the specific embodiments described herein are only used to explain the present application and are not intended to limit the present application.

[0056] Refer to Figure 1, which is a schematic diagram of the structure of a secure payment device in the hardware operating environment involved in the embodiment of the present application.

[0057] As shown in Figure 1, the secure payment device may include: a processor 1001, such as a central processing unit (CPU), a communication bus 1002, a user interface 1003, a network interface 1004, and a memory 1005. The communication bus 1002 is used to implement connection and communication between these components. The user interface 1003 may include a display screen (Display). Optionally, the user interface 1003 may also include a standard wired interface or a wireless interface. The wired interface of the user interface 1003 may be a USB interface in this application. The network interface 1004 may optionally include a standard wired interface or a wireless interface (such as a wireless fidelity (Wi-Fi) interface). The memory 1005 may be a high-speed random access memory (RAM) memory or a stable memory (NVM), such as a disk memory. The memory 1005 may also be a storage device independent of the aforementioned processor 1001.

[0058] Those skilled in the art will understand that the structure shown in FIG1 does not constitute a limitation on the secure payment device, and may include more or fewer components than shown, or a combination of certain components, or a different arrangement of components.

[0059] As shown in FIG. 1 , the memory 1005 , which is identified as a computer storage medium, may include an operating system, a network communication module, a user interface module, and a secure payment program.

[0060] In the secure payment device shown in Figure 1, the network interface 1004 is mainly used to connect to the background server and communicate data with the background server; the user interface 1003 is mainly used to connect to the user device; the secure payment device calls the secure payment program stored in the memory 1005 through the processor 1001, and executes the secure payment method provided in the embodiment of the present application.

[0061] Based on the above hardware structure, a secure payment method provided in an embodiment of the present application is proposed.

[0062] Refer to Figure 2, which is a flow chart of the first embodiment of the secure payment method provided by the embodiment of the present application, and proposes the first embodiment of the secure payment method provided by the embodiment of the present application.

[0063] With the rapid development of technology and the improvement of people's living standards, mobile payment has gradually become an indispensable transaction method for modern people. While this payment method is becoming increasingly popular, it also brings some hidden dangers to our personal property and life, and breeds many payment scams.

[0064] There are two common solutions to this problem:

[0065] Option 1: Popular knowledge about common fraud information; Option 2: National anti-fraud application (Application, App).

[0066] However, the above solutions also have the following problems:

[0067] Option 1: There are many types of scams, and the ability to popularize anti-fraud information is limited. Many people still suffer from frauds of varying degrees, resulting in serious property losses, and the possibility of recovering the money is extremely small.

[0068] Solution 2: Problem 1: After installing the National Anti-Fraud App, some fraudulent calls will be filtered, but it is not comprehensive and there are still omissions; Problem 2: The National Anti-Fraud App can only monitor fraudulent calls, but for other types of fraud such as SMS fraud and WeChat, the monitoring intensity or scope is still relatively small.

[0069] Regardless of the type of scam, the final result is the user's payment action. Therefore, in order to prevent users from being deceived at the source, this embodiment proposes a safe payment method. When it is detected that the user's payment behavior is a risky payment behavior, the payment process is completed under the supervision of the user's corresponding collaborative payer, thereby preventing users from being deceived at the source, and effectively reducing the occurrence of users transferring money due to being deceived, effectively improving the security level of user payments, and protecting the safety of users' personal assets.

[0070] In a first embodiment, the secure payment method includes the following steps:

[0071] Step S10: When it is detected that the user's payment behavior is a risky payment behavior, a confirmation request is sent to the co-payer corresponding to the user.

[0072] It should be understood that the execution subject of the method of this embodiment can be a secure payment device with data processing, network communication and program running functions, for example, a terminal device such as a server, or other electronic device that can achieve the same or similar functions. This embodiment does not impose any restrictions on this.

[0073] It is understood that the user's corresponding co-payer can be pre-set by the user. For example, it is understood that when the user chooses to activate the secure payment function, the user terminal can jump to the co-payer addition interface. The user can add the co-payer's relevant information on this interface, such as name, gender, mobile phone number, payment app account, etc.

[0074] Step S20: Receive the first verification information uploaded by the user, where the first verification information is obtained by signing the user's payment information using the first collaborative payment key.

[0075] It should be noted that when a user chooses to activate the secure payment function, the server will generate a collaborative payment key based on the user's information. The collaborative payment key consists of two pairs of public and private keys. The private keys in these two pairs are used to sign the user's payment information when the user makes a payment. The server can then use the public key in these two pairs to verify the authenticity and legitimacy of the payment information and signature. Once the verification is successful, the user's payment process is completed. This payment verification process for these two pairs of public and private keys is implemented based on the Schnorr algorithm.

[0076] Furthermore, in order to improve security based on the Schnorr algorithm, the secure payment method further includes:

[0077] The user payment information is signed using a collaborative payment key based on the improved Schnorr algorithm, wherein the improved Schnorr algorithm adds a random number on the basis of the Schnorr algorithm, and the collaborative payment key includes a first collaborative payment key and a second collaborative payment key.

[0078] It should be understood that in order to improve security based on the Schnorr algorithm, this embodiment improves the Schnorr algorithm by adding a random number to the Schnorr algorithm. The specific process is as follows:

[0079] Note: Lowercase letters represent numbers. Some algebraic operations are performed using points on the ellipse, with uppercase letters representing these points. On secp256k1, the private key is simply a scalar integer value 256 between 0 and ~2. We have a special point on the secp256k1 curve called G, which acts as the "origin." The public key is calculated by adding G to itself on the curve, Kn times. This is the definition of scalar multiplication, written as: Pn = Kn.G;

[0080] 1. Generate a secret one-time number, the random number r;

[0081] 2. Create a public key from a random number, i.e. R = rG;

[0082] 3. Send the above information to user 2, recipient-message (m), R and public key 1 (P = kG);

[0083] 4. The actual signature history is created by hashing a combination of public information. At this point, a challenge e is created, e = H(R||page||m). The hash function is chosen so that e has the same range as the private key. The signature is constructed using the private information, s = r + ke.

[0084] 5. User 2 obtains the information m, R, P and hash function H, but does not know the private key k and random number r. Based on this information, user 2 performs signature verification, sG=(r+ke)G, and multiplies the right side to get: sG=rG+(KG)e. Substituting R=rG and P=kG, the calculation is: sG=R=Pe. Given user 2's s, G, R, P, and e, user 2's s, G, R, P, and e can be calculated, so sG=R+Pe can be calculated to verify whether the equation holds.

[0085] Step S30: receiving the second verification information fed back by the collaborative payer according to the confirmation request, wherein the second verification information is obtained by signing the user payment information using the second collaborative payment key.

[0086] It is understandable that, by the same token, the payment verification process of the second collaborative payment key can be implemented based on the Schnorr algorithm or the improved Schnorr algorithm, and this embodiment does not impose any restrictions on this.

[0087] Step S40: Perform security verification on the payment behavior according to the first verification information and the second verification information.

[0088] It should be understood that the collaborative payment key consists of two pairs of public and private keys. The private keys in both pairs are used to sign the user's payment information when the user makes a payment. The server can then use the public keys in the two pairs to verify the authenticity and legitimacy of the payment information and signature. Once the verification is successful, the user's payment process is completed. This payment verification process for these two pairs of public and private keys is implemented based on the Schnorr algorithm.

[0089] Step S50: After the verification is passed, a secure payment is performed according to the payment behavior.

[0090] It should be understood that after the verification is passed, it means that the user's payment behavior has been approved by the co-payer. Therefore, safe payment can be made based on the payment behavior.

[0091] In this embodiment, it is disclosed that when it is detected that the user's payment behavior is a risky payment behavior, a confirmation request is sent to the collaborative payer corresponding to the user, the first verification information uploaded by the user is received, the first verification information is obtained by signing the user's payment information through the first collaborative payment key, the second verification information fed back by the collaborative payer according to the confirmation request is received, the second verification information is obtained by signing the user's payment information through the second collaborative payment key, the payment behavior is securely verified based on the first verification information and the second verification information, and after the verification is passed, a secure payment is made based on the payment behavior; because this embodiment completes the payment process under the supervision of the collaborative payer corresponding to the user when it is detected that the user's payment behavior is a risky payment behavior, it can prevent the user from being deceived from the root, and thus can effectively reduce the occurrence of users transferring money due to being deceived, effectively improve the security level of user payments, and protect the safety of users' personal assets.

[0092] Refer to Figure 3, which is a flow chart of the second embodiment of the secure payment method of the present application. Based on the first embodiment shown in Figure 2 above, the second embodiment of the secure payment method of the present application is proposed.

[0093] In the second embodiment, before step S10, the method further includes:

[0094] Step S01: When a user's payment behavior is detected, it is determined whether the merchant type to which the user is currently paying is a designated payment type corresponding to the user's age.

[0095] It should be understood that in order to improve the accuracy of risky payment behavior detection, in this embodiment, whether the user's payment behavior is a risky payment behavior is detected based on whether the payment amount of the payment behavior exceeds the limit threshold.

[0096] It should be noted that the designated payment type corresponding to the user's age can be pre-set. For example, if the user is over 50 years old, the designated payment type corresponding to this age is health care products, medicines, etc.; if the user is between 18 and 25 years old, the designated payment type corresponding to this age is job-seeking related, non-public school related, etc. This embodiment does not impose any restrictions on this.

[0097] Step S02: If yes, obtain the base amount of the specified payment type, and determine the limit threshold according to the base amount and the limit threshold ratio of the specified payment type, wherein the limit threshold ratio is predetermined according to the user's basic information, balance information and user operation.

[0098] It should be noted that the benchmark amount is determined based on the average payment amount of the user's risk-free designated payment type.

[0099] It is understandable that determining the credit limit threshold according to the ratio of the base amount and the credit limit threshold of the specified payment type may be to calculate the product of the base amount and the credit limit threshold ratio of the specified payment type to obtain the credit limit threshold.

[0100] Furthermore, in order to improve the accuracy of the credit limit threshold ratio, the secure payment method further includes:

[0101] Based on the user's basic information and the preset safety factor model, the basic security level coefficient of the specified payment type corresponding to the user's age is calculated; based on the user's balance information, the user's basic security amount is determined; based on the basic security level coefficient and the basic security amount, the credit limit threshold ratio of the specified payment type corresponding to the user's age is calculated; and the credit limit threshold ratio is adjusted according to user operations.

[0102] In a specific implementation, for example, after generating two key pairs, the server will obtain the user's basic information, such as age, gender, education level, permanent address, and the types of merchants that the user frequently consumes, and determine the user's basic security level coefficient for the specified payment type corresponding to his or her age based on these basic information. Then, based on the user's current account balance information, including the balance of the savings card and the remaining credit card amount information, the user's basic security amount is determined. Then, the product of the user's basic security level coefficient and the user's basic security amount is used to determine the recommended amount threshold ratio for the specified payment type corresponding to the user's age, and displayed to the user through the terminal.

[0103] Furthermore, in order to prevent users from circumventing secure payment by raising the limit threshold ratio and to improve the security of secure payment, in this embodiment, when the user operation is to lower the limit threshold ratio, the limit threshold ratio is adjusted according to the user operation; when the user operation is to increase the limit threshold ratio, a confirmation message is sent to the collaborative payer corresponding to the user; when there is a single collaborative payer, the limit threshold ratio is adjusted based on the confirmation operation feedback from the collaborative payer; when there are multiple collaborative payers, the target collaborative payer is determined according to the collaborative levels of the multiple collaborative payments, and the limit threshold ratio is adjusted based on the confirmation operation feedback from the target collaborative payer.

[0104] In a specific implementation, for example, after viewing the recommended threshold ratio for a specific payment type corresponding to their age, a user can adjust the threshold ratio. It should be noted that if the user lowers the threshold ratio, the adjustment is successful. If the user raises the threshold ratio and the increased ratio exceeds the specified ratio, the server will first send a corresponding confirmation message to the co-payer. The user can only successfully adjust the threshold ratio after the co-payer confirms it. If there are multiple co-payers, the adjustment can only be successful after the confirmation of the highest-level co-payer.

[0105] The calculation process of the basic safety level coefficient (hereinafter referred to as the safety coefficient) is as follows:

[0106] The safety factor calculation requires obtaining several key parameters as shown in Table 1. These parameters are used to calculate the risk values ​​corresponding to different transaction types.

[0107] Table 1

[0108] Parameter Description:

[0109] The above characteristics are important indicators for calculating the safety factor. Different safety levels are divided according to their different groups, and the weights of each indicator are different. The larger the final calculated result value, the greater the final safety factor result.

[0110] The specific implementation method is as follows:

[0111] 1. Establish a structural model:

[0112] It is generally divided into three levels, namely the target level, the criteria level and the execution level. For ease of understanding, they are organized into the following table. A represents the target level, N represents the criteria level and P represents the execution level, as shown in Table 2:

[0113] Table 2

[0114] 2. Constructing a judgment matrix

[0115] By assigning weights to each indicator data, each indicator is compared pairwise, using a relative scale to minimize the difficulty of comparing factors of different natures and improve accuracy. In the indicator weight setting, the larger the number, the more important the row factor is compared to the column factor. The maximum weight is 3, indicating extreme importance, the minimum weight is 1, indicating equal importance, and the reciprocal indicates relative unimportance, with 1 / 3 being the least important. The comparison judgment matrix is ​​shown in Table 3:

[0116] Table 3

[0117] 3. Calculate the relative weight of each layer, taking the above matrix as an example:

[0118] (1) Normalize the element A by column: Right now

[0119] The judgment matrix of AN is obtained as:

[0120] (2) Add the AN matrix row by row: After calculation, we can get:

[0121] h1=0.535+0.571+0.5=1.606

[0122] h2=0.263+0.286+0.333=0.882

[0123] h3=0.182+0.153+0.167=0.502

[0124] (3) Calculate the weight vector: The eigenvector of the AN judgment matrix can be obtained:

[0125] The final value is:

[0126] 4. Perform consistency check on the obtained results:

[0127] (1) Calculate the maximum eigenvalue of the judgment matrix:

[0128] (2) Calculate the consistency index:

[0129] Calculation can be obtained:

[0130] Among them: RI represents the average random consistency. It can be seen from the table that if CR < 0.1, the matrix is ​​judged to be consistent, that is, the matrix indicator setting is legal and can be used for calculation.

[0131] 5. By setting and calculating the indicator parameters, the result is the final safety factor. The higher the coefficient value, the greater the risk and the lower the safety factor. If the critical value is reached, the collaborative payment mode is triggered.

[0132] Step S03: Determine whether the payment amount of the payment behavior exceeds the limit threshold.

[0133] It is understandable that determining whether the payment amount of the payment behavior exceeds the limit threshold may be determining whether the payment amount of the payment behavior is greater than the limit threshold.

[0134] Step S04: Detecting whether the user's payment behavior is a risky payment behavior based on the judgment result.

[0135] It should be understood that detecting whether the user's payment behavior is a risky payment behavior based on the judgment result can be when the payment amount of the payment behavior exceeds the limit threshold, determining that the user's payment behavior is a risky payment behavior; specifically, it can also be determined whether it is a medium- or high-risk payment behavior, or a low-risk payment behavior based on the excess amount.

[0136] In a specific implementation, for example, when a user payment is detected, the backend will determine whether the merchant type the user is currently paying to is the corresponding designated payment type. If so, it will obtain the benchmark amount for the designated payment type corresponding to the user's age. The benchmark amount is determined based on the average of the user's risk-free payment amounts for the designated payment type. The backend will then determine whether the payment amount has exceeded the product of the threshold ratio of the designated payment type corresponding to the user's age and the corresponding benchmark amount. If it has exceeded the threshold ratio by a significant amount, the backend will instruct the user terminal to sign the user's payment information with a collaborative payment key pair and send a confirmation request to the corresponding highest-level collaborative payer. The payment will be completed after the highest-level collaborative payer confirms the payment. If it has exceeded the threshold ratio by a small amount, the backend will instruct the user terminal to sign the user's payment information with a collaborative payment key pair and send a confirmation request to all corresponding collaborative payers at all levels. The payment will be completed after confirmation by any collaborative payer at any level. If it has not exceeded the threshold ratio by a significant amount, the backend will instruct the user terminal to sign and verify the user's payment information with a standard payment key pair.

[0137] This embodiment detects whether the user's payment behavior is a risky payment behavior based on whether the payment amount of the payment behavior exceeds the limit threshold, thereby improving the accuracy of risky payment behavior detection.

[0138] Referring to Figure 4, which is a flow chart of a third embodiment of a secure payment method provided by an embodiment of the present application, a third embodiment of a secure payment method provided by an embodiment of the present application is proposed based on the above embodiments.

[0139] In a third embodiment, the secure payment method further includes:

[0140] Step S01': After detecting that the user has turned on the secure payment function, a normal payment key and a collaborative payment key are generated based on the user information. The normal payment key is used to sign and verify the user's payment information when the user's payment behavior is a normal payment behavior. The collaborative payment key includes a first collaborative payment key and a second collaborative payment key. The first collaborative payment key is stored in the user terminal.

[0141] It should be understood that payment apps provide users with a secure payment feature, which can be enabled by clicking a corresponding button on the app. Once enabled, the payment app can provide an additional layer of security after the user enters their payment password if their payment is risky, further ensuring the security of their account.

[0142] In a specific implementation, for example, when a user sets a payment password, the user terminal can detect whether the user has enabled the secure payment function. If not, the user can be asked whether to enable the secure payment function. Of course, when asking, relevant information about the secure payment function will be provided to help the user understand the specific content of the secure payment function.

[0143] It is understandable that when a user chooses to activate the secure payment function, the server will generate two key pairs (i.e., a normal payment key and a collaborative payment key) based on the user information for payment verification. The normal payment key includes a pair of public and private keys. The private key in this key pair is used to sign the user's payment information when the user pays. Then, the server can use the public key to verify the authenticity and legitimacy of the payment information and signature, and complete the user's payment process after the verification is passed.

[0144] The collaborative payment key consists of two pairs of public and private keys. The private keys in both pairs are used to sign the user's payment information when making a payment. The server can then use the public key in the two pairs to verify the authenticity and legitimacy of the payment information and signature. Once the verification is successful, the user's payment process is completed. This payment verification process for these two pairs of public and private keys is implemented based on the Schnorr algorithm.

[0145] Step S02': setting the collaborative payer corresponding to the user according to the setting information of the user, and sending the second collaborative payment key to the collaborative payer.

[0146] It should be understood that when a user chooses to activate the secure payment function, the user terminal may jump to the interface for adding a co-payer. On this interface, the user can add relevant information of the co-payer, such as name, gender, mobile phone number, payment app account, etc.

[0147] It is understandable that after the user sets up a collaborative payer, the server sends one of the two pairs of public and private keys generated to the collaborative payer.

[0148] In this embodiment, when the server sends one of the two pairs of public and private keys to the collaborative payer, the collaborative payer can see the corresponding collaborative key pair function reminder on his or her payment APP account. The collaborative payer knows from the reminder that he or she has become the user's collaborative payer.

[0149] It should be understood that users can also set up multiple collaborative payers. If the payment APP is bound to multiple bank cards, corresponding collaborative payers can also be set for each bank card. The collaborative payers set for different bank cards can also be the same.

[0150] Furthermore, in order to achieve separate security protection for each payment account, in this embodiment, different co-payers may be determined according to different payment accounts. Step S10 includes:

[0151] When it is detected that the user's payment behavior is a risky payment behavior, the payment account corresponding to the payment behavior is obtained, the co-payer corresponding to the user is determined based on the payment account, and a confirmation request is sent to the co-payer corresponding to the user.

[0152] It is understood that determining the user's corresponding co-payer based on the payment account may mean using the co-payer corresponding to the payment account as the user's corresponding co-payer. The co-payer corresponding to the payment account may be pre-set by the user. For example, if the payment app is bound to multiple bank cards, the user can set a corresponding co-payer for each bank card.

[0153] After detecting that the user has turned on the secure payment function, this embodiment generates a normal payment key and a collaborative payment key, and sends the collaborative payment key to the collaborative payer set by the user, so that the two keys can be generated in advance to realize subsequent payment modes, thereby effectively improving the security level of the user's payment.

[0154] Referring to Figure 5, which is a flowchart of a fourth embodiment of the secure payment method of the present application, a fourth embodiment of the secure payment method of the present application is proposed based on the above embodiments.

[0155] In the fourth embodiment, step S10 includes:

[0156] Step S101: When it is detected that the user's payment behavior is a risky payment behavior, the collaborative payer corresponding to the user is determined based on the payment scenario and the collaborative level of the collaborative payer in different scenarios. The collaborative level is determined based on the basic information of the user, the basic information of the collaborative payer, and the degree of interaction between the user and the collaborative payer.

[0157] It is understandable that when a user sets up multiple collaborative payers, the server will determine the collaborative level of the collaborative payer in different scenarios based on the user's basic information, the basic information of the collaborative payer, and the degree of interaction between the user and the collaborative payer.

[0158] For ease of understanding, the following examples are provided, but are not intended to limit this solution. The specific steps are as follows:

[0159] When determining the level of the collaborative payer, the user's age range will be determined first, such as over 50 years old, 25 to 50 years old, 18 to 25 years old, and the degree of interaction between the user and the collaborative payer will be determined. When judging the degree of interaction, it will be determined based on the amount, number of times, and merchant type of the user's interactions with the collaborative payer. Interactions include collaborative payment interactions, social interactions, and bill payment interactions.

[0160] After determining the age range of the user and the degree of interaction between the user and the collaborative payer, if the user is over 50 years old, in the payment scenario of the specified payment type (including health products and medicines) corresponding to that age, the level of the collaborative payer with a similar age will be set to a lower level, and the level of the collaborative payer with a large age difference and younger than the user's age and a higher degree of interaction will be set to a higher level; in other types of payment scenarios, such as the purchase of household appliances, the level of the collaborative payer with a similar age and a higher degree of interaction will be set to a higher level.

[0161] If the user is between 18 and 25 years old, in the payment scenarios of the designated payment types corresponding to that age (including job-seeking related, non-public college related, etc.), the level of the co-payer with a large age difference and older than the user's age and a higher degree of interaction will be set to a higher level; in other types of payment scenarios, such as payment scenarios for daily necessities, the level of the co-payer with a similar age and a higher degree of interaction will be set to a higher level.

[0162] If the user is between 25 and 50 years old, the user's gender will be further obtained. When the user is a female, the level of the opposite-sex co-payer with a similar age and a high degree of interaction will be set to a higher level under the payment scenario of the specified payment type (including beauty, cosmetics, etc.) corresponding to the gender; when the user is a male, the level of the opposite-sex co-payer with a similar age and a high degree of interaction will be set to a higher level under the payment scenario of the specified payment type (such as games, live broadcast rewards) corresponding to the gender.

[0163] In a specific implementation, for example, when a user sets multiple collaborative payers, when the user's payment risk is relatively high, if a high-level collaborative payer does not confirm, a low-level collaborative payer cannot complete the payment even if it confirms.

[0164] Step S102: Send a confirmation request to the co-payer corresponding to the user.

[0165] It can be understood that when it is detected that the user's payment behavior is a medium- or high-risk payment behavior, the server sends a confirmation request to the collaborative payer with the highest collaboration level in the payment scenario, and completes the payment after the highest-level collaborative payer confirms; when it is detected that the user's payment behavior is a low-risk payment behavior, the server sends a confirmation request to all levels of collaborative payers in the payment scenario, and completes the payment after confirmation by any level of collaborative payer.

[0166] This embodiment divides collaborative payers into different collaborative levels and determines the collaborative payer corresponding to the user according to the payment scenario, thereby achieving hierarchical management of collaborative payers and further improving the security of user payments.

[0167] In addition, an embodiment of the present application further provides a storage medium, on which a secure payment program is stored. When the secure payment program is executed by a processor, the secure payment method described above is implemented.

[0168] In addition, referring to FIG6 , an embodiment of the present application further provides a secure payment device, the secure payment device comprising: a request collaboration module 10 , an information receiving module 20 , a security verification module 30 , and a secure payment module 40 ;

[0169] The request coordination module 10 is configured to send a confirmation request to the coordinated payer corresponding to the user when detecting that the user's payment behavior is a risky payment behavior.

[0170] It is understood that the user's corresponding co-payer can be pre-set by the user. For example, it is understood that when the user chooses to activate the secure payment function, the user terminal can jump to the co-payer addition interface. The user can add the co-payer's relevant information on this interface, such as name, gender, mobile phone number, payment app account, etc.

[0171] The information receiving module 20 is used to receive the first verification information uploaded by the user, where the first verification information is obtained by signing the user's payment information using the first collaborative payment key.

[0172] It should be noted that when a user chooses to activate the secure payment function, the server will generate a collaborative payment key based on the user's information. The collaborative payment key consists of two pairs of public and private keys. The private keys in these two pairs are used to sign the user's payment information when the user makes a payment. The server can then use the public key in these two pairs to verify the authenticity and legitimacy of the payment information and signature. Once the verification is successful, the user's payment process is completed. This payment verification process for these two pairs of public and private keys is implemented based on the Schnorr algorithm.

[0173] Furthermore, in order to improve security based on the Schnorr algorithm, it also includes:

[0174] The user payment information is signed using a collaborative payment key based on the improved Schnorr algorithm, wherein the improved Schnorr algorithm adds a random number on the basis of the Schnorr algorithm, and the collaborative payment key includes a first collaborative payment key and a second collaborative payment key.

[0175] It should be understood that in order to improve security based on the Schnorr algorithm, this embodiment improves the Schnorr algorithm by adding a random number to the Schnorr algorithm. The specific process is as follows:

[0176] Note: Lowercase letters represent numbers. Some algebraic operations are performed using points on the ellipse, with uppercase letters representing these points. On secp256k1, the private key is simply a scalar integer value 256 between 0 and ~2. We have a special point on the secp256k1 curve called G, which acts as the "origin." The public key is calculated by adding G to itself on the curve, Kn times. This is the definition of scalar multiplication, written as: Pn = Kn.G;

[0177] 1. Generate a secret one-time number, the random number r;

[0178] 2. Create a public key from a random number, i.e. R = rG;

[0179] 3. Send the above information to user 2, recipient-message (m), R and public key 1 (P = kG);

[0180] 4. The actual signature history is created by hashing a combination of public information. At this point, a challenge e is created, e = H(R||page||m). The hash function is chosen so that e has the same range as the private key. The signature is constructed using the private information, s = r + ke.

[0181] 5. User 2 obtains the information m, R, P and hash function H, but does not know the private key k and random number r. Based on this information, user 2 performs signature verification, sG=(r+ke)G, and multiplies the right side to get: sG=rG+(KG)e. Substituting R=rG and P=kG, the calculation is: sG=R=Pe. Given user 2's s, G, R, P, and e, user 2's s, G, R, P, and e can be calculated, so sG=R+Pe can be calculated to verify whether the equation holds.

[0182] The information receiving module 20 is configured to receive second verification information fed back by the collaborative payer in response to the confirmation request, where the second verification information is obtained by signing the user payment information using a second collaborative payment key.

[0183] It is understandable that, by the same token, the payment verification process of the second collaborative payment key can be implemented based on the Schnorr algorithm or the improved Schnorr algorithm, and this embodiment does not impose any restrictions on this.

[0184] The security verification module 30 is used to perform security verification on the payment behavior according to the first verification information and the second verification information.

[0185] It should be understood that the collaborative payment key consists of two pairs of public and private keys. The private keys in both pairs are used to sign the user's payment information when the user makes a payment. The server can then use the public keys in the two pairs to verify the authenticity and legitimacy of the payment information and signature. Once the verification is successful, the user's payment process is completed. This payment verification process for these two pairs of public and private keys is implemented based on the Schnorr algorithm.

[0186] The secure payment module 40 is used to perform secure payment according to the payment behavior after verification.

[0187] It should be understood that after the verification is passed, it means that the user's payment behavior has been approved by the co-payer. Therefore, safe payment can be made based on the payment behavior.

[0188] In this embodiment, it is disclosed that when it is detected that the user's payment behavior is a risky payment behavior, a confirmation request is sent to the collaborative payer corresponding to the user, the first verification information uploaded by the user is received, the first verification information is obtained by signing the user's payment information through the first collaborative payment key, the second verification information fed back by the collaborative payer according to the confirmation request is received, the second verification information is obtained by signing the user's payment information through the second collaborative payment key, the payment behavior is securely verified based on the first verification information and the second verification information, and after the verification is passed, a secure payment is made based on the payment behavior; because this embodiment completes the payment process under the supervision of the collaborative payer corresponding to the user when it is detected that the user's payment behavior is a risky payment behavior, it can prevent the user from being deceived from the root, and thus can effectively reduce the occurrence of users transferring money due to being deceived, effectively improve the security level of user payments, and protect the safety of users' personal assets.

[0189] In one embodiment, the secure payment device further comprises: a risk determination module;

[0190] The risk judgment module is used to determine whether the merchant type of the user's current payment is the specified payment type corresponding to the user's age when the user's payment behavior is detected. If so, the base amount of the specified payment type is obtained, and the limit threshold is determined based on the base amount and the limit threshold ratio of the specified payment type. The limit threshold ratio is predetermined based on the user's basic information, balance information and user operation. It is determined whether the payment amount of the payment behavior exceeds the limit threshold, and whether the user's payment behavior is a risky payment behavior is detected based on the judgment result.

[0191] In one embodiment, the secure payment device further includes: a limit setting module;

[0192] The credit limit setting module is used to calculate the basic security level coefficient of the specified payment type corresponding to the user's age based on the user's basic information and a preset safety factor model, determine the user's basic security amount based on the user's balance information, calculate the credit limit threshold ratio of the specified payment type corresponding to the user's age based on the basic security level coefficient and the basic security amount, and adjust the credit limit threshold ratio according to user operations.

[0193] In one embodiment, the limit setting module is further used to adjust the limit threshold ratio according to the user operation when the user operation is to lower the limit threshold ratio; when the user operation is to increase the limit threshold ratio, send a confirmation message to the collaborative payer corresponding to the user; when the collaborative payer is a single, adjust the limit threshold ratio based on the confirmation operation feedback from the collaborative payer; when there are multiple collaborative payers, determine the target collaborative payer according to the collaborative levels of multiple collaborative payments, and adjust the limit threshold ratio based on the confirmation operation feedback from the target collaborative payer.

[0194] In one embodiment, the secure payment device further comprises: an information encryption module;

[0195] The information encryption module is used to sign user payment information using a collaborative payment key based on an improved Schnorr algorithm, wherein the improved Schnorr algorithm adds a random number on the basis of the Schnorr algorithm, and the collaborative payment key includes a first collaborative payment key and a second collaborative payment key.

[0196] In one embodiment, the secure payment device further comprises: a key sending module;

[0197] The key sending module is used to generate a normal payment key and a collaborative payment key based on user information after detecting that the user has turned on the secure payment function. The normal payment key is used to sign and verify the user's payment information when the user's payment behavior is a normal payment behavior. The collaborative payment key includes a first collaborative payment key and a second collaborative payment key. The first collaborative payment key is stored in the user terminal. The collaborative payer corresponding to the user is set according to the user's setting information, and the second collaborative payment key is sent to the collaborative payer.

[0198] In one embodiment, the request collaboration module 10 is further used to determine the collaborative payer corresponding to the user based on the payment scenario and the collaboration level of the collaborative payer in different scenarios when it is detected that the user's payment behavior is a risky payment behavior. The collaboration level is determined based on the basic information of the user, the basic information of the collaborative payer, and the degree of interaction between the user and the collaborative payer, and a confirmation request is sent to the collaborative payer corresponding to the user.

[0199] In one embodiment, the request collaboration module 10 is also used to obtain the payment account corresponding to the payment behavior when it is detected that the user's payment behavior is a risky payment behavior, determine the collaborative payer corresponding to the user based on the payment account, and send a confirmation request to the collaborative payer corresponding to the user.

[0200] It should be noted that in the technical solutions of this specification, the operations on the data involved comply with relevant regulations and do not violate public order and good morals. For example, operations on data are performed under the premise of obtaining user authorization. In this article, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or system that includes a series of elements includes not only those elements, but also other elements that are not explicitly listed, or also includes elements that are inherent to such a process, method, article or system. In the absence of further restrictions, an element defined by the sentence "comprises a..." does not exclude the presence of other identical elements in the process, method, article or system that includes the element.

[0201] The serial numbers of the above-mentioned embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0202] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus the necessary general hardware platform, and of course can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present application, or the part that contributes to the relevant technology, can be embodied in the form of a software product, which is stored in a storage medium (such as a read-only memory image (ROM) / random access memory (RAM), a magnetic disk, or an optical disk), and includes a number of instructions for enabling a terminal device (which can be a mobile phone, a computer, a server, an air conditioner, or a network device, etc.) to execute the methods described in each embodiment of the present application.

[0203] The above are only preferred embodiments of the present application and do not limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made using the contents of the present application specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present application.

Claims

1. A secure payment method, comprising: When it is detected that the payment behavior of the user is a risky payment behavior, a confirmation request is sent to the co-payer corresponding to the user; Receiving first verification information uploaded by the user, where the first verification information is obtained by signing the user's payment information using a first collaborative payment key; Receiving second verification information fed back by the collaborative payer according to the confirmation request, wherein the second verification information is obtained by signing the user payment information using a second collaborative payment key; Performing security verification on the payment behavior according to the first verification information and the second verification information; After the verification is passed, a secure payment is made according to the payment behavior.

2. The secure payment method according to claim 1, wherein: The secure payment method further comprises: When the user's payment behavior is detected, it is determined whether the merchant type currently paid by the user is the designated payment type corresponding to the user's age; If yes, then obtaining a base amount of the specified payment type, and determining a credit limit according to a ratio of the base amount to a credit limit of the specified payment type, wherein the credit limit ratio is predetermined according to the basic information, balance information, and user operation of the user; Determining whether the payment amount of the payment behavior exceeds the limit threshold; Whether the payment behavior of the user is a risky payment behavior is detected based on the judgment result.

3. The secure payment method according to claim 2, wherein: The secure payment method further comprises: Calculate the basic level of security precautions for the specified payment type corresponding to the user's age based on the user's basic information and a preset security factor model; Determine the user's basic security amount according to the user's balance information; Calculate the amount threshold ratio of the specified payment type corresponding to the user's age according to the basic security level coefficient and the basic security amount; The credit limit threshold ratio is adjusted according to user operations.

4. The secure payment method according to claim 3, wherein: The adjusting the credit limit threshold ratio according to the user operation includes: When the user operation is to lower the credit limit threshold ratio, adjusting the credit limit threshold ratio according to the user operation; When the user operation is to increase the credit limit threshold ratio, a confirmation message is sent to the co-payer corresponding to the user; When the cooperative payer is a single person, the credit limit threshold ratio is adjusted based on the confirmation operation fed back by the cooperative payer; When there are multiple collaborative payers, a target collaborative payer is determined according to the collaborative levels of the multiple collaborative payments. The amount threshold ratio is adjusted based on the confirmation operation fed back by the target collaborative payer.

5. The secure payment method according to any one of claims 1 to 4, wherein: The secure payment method further comprises: The user payment information is signed by a collaborative payment key based on the improved Schnorr algorithm, wherein the improved Schnorr algorithm adds a random number on the basis of the Schnorr algorithm, and the collaborative payment key includes a first collaborative payment key and a second collaborative payment key.

6. The secure payment method according to any one of claims 1 to 4, wherein: The secure payment method further comprises: After detecting that the user has turned on the secure payment function, a common payment key and a collaborative payment key are generated according to the user information. The common payment key is used to sign and verify the user's payment information when the user's payment behavior is a common payment behavior. The collaborative payment key includes a first collaborative payment key and a second collaborative payment key. The first collaborative payment key is stored in the user terminal. The collaborative payer corresponding to the user is set according to the setting information of the user, and the second collaborative payment key is sent to the collaborative payer.

7. The secure payment method according to any one of claims 1 to 4, wherein: When detecting that the payment behavior of the user is a risky payment behavior, sending a confirmation request to the co-payer corresponding to the user includes: When it is detected that the payment behavior of the user is a risky payment behavior, the collaborative payer corresponding to the user is determined according to the payment scenarios and the collaborative levels of the collaborative payers in different scenarios, wherein the collaborative level is determined according to the basic information of the user, the basic information of the collaborative payer, and the degree of interaction between the user and the collaborative payer; A confirmation request is sent to the co-payer corresponding to the user.

8. The secure payment method according to any one of claims 1 to 4, wherein: When detecting that the payment behavior of the user is a risky payment behavior, sending a confirmation request to the co-payer corresponding to the user includes: When detecting that the user's payment behavior is a risky payment behavior, obtaining the payment account corresponding to the payment behavior; The co-payer corresponding to the user is determined according to the payment account, and a confirmation request is sent to the co-payer corresponding to the user.

9. A secure payment device, comprising: A memory, a processor, and a secure payment program stored in the memory and executable on the processor, wherein the secure payment program implements the secure payment method according to any one of claims 1 to 8 when executed by the processor.

10. A storage medium having a secure payment program stored thereon, wherein the secure payment program, when executed by a processor, implements the secure payment method according to any one of claims 1 to 8.

11. A secure payment device, comprising: Request coordination module, information receiving module, security verification module and secure payment module; The request coordination module is used to send a confirmation request to the coordinated payer corresponding to the user when detecting that the user's payment behavior is a risky payment behavior; The information receiving module is used to receive the first verification information uploaded by the user. The user's payment information is signed by using the first collaborative payment key; The information receiving module is further used to receive second verification information fed back by the collaborative payer according to the confirmation request, where the second verification information is obtained by signing the user payment information with a second collaborative payment key; The security verification module is used to perform security verification on the payment behavior according to the first verification information and the second verification information; The secure payment module is used to perform secure payment according to the payment behavior after verification.

Images