CN111815331A - A method and device for identifying payment behavior of minors - Google Patents

Abstract

The specification discloses a method and device for identifying the payment behavior of minors. A method for identifying the payment behavior of minors, based on the identification model jointly trained by the business party, the payer and the collaborator to realize the identification of the minors' payment behavior, the business party deploys a first identification sub-model, and the payer deploys a The second identification sub-model includes: in response to a payment request initiated by the user, the business party obtains the user's business characteristics, and inputs the business characteristics into the first identification sub-model to obtain a business identification result; the business party sends the business identification result to Collaborating party; in response to the payment request, the paying party obtains the user’s payment characteristics, and inputs the payment characteristics into the second identification sub-model to obtain the payment identification result; the paying party sends the payment identification result to the collaborating party; the collaborating party identifies the payment according to the business The result and the payment identification result, determine whether the user's payment behavior is a minor's payment behavior.

Description

A method and device for identifying payment behavior of minors

technical field

This specification relates to the field of artificial intelligence, in particular to a method and device for identifying the payment behavior of minors.

Background technique

With the continuous development of the game industry and digital entertainment industry, various activities and gameplays emerge in an endless stream. Some minors may recharge and consume a lot in these activities, which is not conducive to their physical and mental health. In this case, it is necessary for the payment platform to identify the payment behavior initiated by the user. However, related technologies often cannot accurately identify whether the payment behavior is initiated by a minor.

SUMMARY OF THE INVENTION

In view of this, this specification provides a method and device for identifying the payment behavior of minors.

Specifically, this specification is achieved through the following technical solutions:

A method for identifying the payment behavior of minors, which realizes the identification of the payment behavior of minors based on an identification model jointly trained by a business party, a payer and a collaborating party, wherein the business party deploys a first identification sub-model, The payer is deployed with a second identification sub-model, and the method includes:

In response to the payment request initiated by the user, the business party obtains the business characteristics of the user, and inputs the business characteristics into the first identification sub-model to obtain a business identification result;

The business party sends the business identification result to the collaborating party;

In response to the payment request, the payer obtains the user's payment characteristics, and inputs the payment characteristics into the second identification sub-model to obtain a payment identification result;

The paying party sends the payment identification result to the collaborating party;

The collaborating party determines whether the user's payment behavior is a minor's payment behavior according to the service identification result and the payment identification result.

A method for identifying the payment behavior of minors, which realizes the identification of the payment behavior of minors based on an identification model jointly trained by a business party, a payer and a collaborating party, wherein the business party deploys a first identification sub-model, The payer is deployed with a second identification sub-model, the method is applied to the payer, and the method includes:

In response to a payment request initiated by the user, acquiring the payment feature of the user;

Inputting the payment feature into the second identification sub-model to obtain a payment identification result;

Sending the payment identification result to the cooperating party, so that the cooperating party determines whether the user's payment behavior is a minor payment behavior based on the payment identification result and the service identification result sent by the business party;

Wherein, the service identification result is obtained by the service party obtaining the user's service characteristics in response to the payment request, and inputting the service characteristics into the first identification sub-model.

A device for identifying the payment behavior of minors, which realizes the identification of the payment behavior of minors based on an identification model jointly trained by a business party, a payer and a collaborating party, wherein the business party deploys a first identification sub-model, The payer is deployed with a second identification sub-model, the apparatus is applied to the payer, and the apparatus includes:

an acquiring unit, in response to a payment request initiated by the user, acquiring the payment feature of the user;

an input unit, inputting the payment feature into the second identification sub-model to obtain a payment identification result;

a sending unit, sending the payment identification result to the collaborating party, so that the collaborating party determines whether the user's payment behavior is a minor payment behavior based on the payment identification result and the service identification result sent by the business party;

Wherein, the service identification result is obtained by the service party obtaining the user's service characteristics in response to the payment request, and inputting the service characteristics into the first identification sub-model.

A device for identifying the payment behavior of minors, which realizes the identification of the payment behavior of minors based on an identification model jointly trained by a business party, a payer and a collaborating party, wherein the business party deploys a first identification sub-model, The payer is deployed with a second identification sub-model, the apparatus is applied to the payer, and the apparatus includes:

processor;

memory for storing machine-executable instructions;

Wherein, by reading and executing the machine-executable instructions stored in the memory corresponding to the identification logic of the minor's payment behavior, the processor is caused to:

In response to a payment request initiated by the user, acquiring the payment feature of the user;

Inputting the payment feature into the second identification sub-model to obtain a payment identification result;

Sending the payment identification result to the cooperating party, so that the cooperating party determines whether the user's payment behavior is a minor payment behavior based on the payment identification result and the service identification result sent by the business party;

Wherein, the service identification result is obtained by the service party obtaining the user's service characteristics in response to the payment request, and inputting the service characteristics into the first identification sub-model.

An embodiment of this specification realizes that the business party can respond to the payment request initiated by the user, obtain the user's business characteristics and input it into the first identification sub-model, obtain the business identification result and send it to the collaborating party; the payment party can respond to the user For the payment request initiated, the user's payment characteristics are obtained and input into the second identification sub-model, and the payment identification result is obtained and sent to the collaborating party. The collaborating party may determine whether the user's payment behavior is a minor payment behavior based on the service identification result and the payment identification result.

Using the above method, the identification model can be obtained through joint training of the business party and the payer through the data of the business party and the payer, and after receiving the payment request initiated by the user, it is possible to predict whether the user's payment behavior is a minor payment based on the identification model. It solves the problem that the payment behavior of minors cannot be identified in the related technology, or the identification result is inaccurate.

Description of drawings

FIG. 1 is a schematic diagram of an architecture shown in an exemplary embodiment of the present specification;

FIG. 2 is a schematic diagram of a joint training method shown in an exemplary embodiment of the present specification;

Fig. 3 is a schematic diagram of a method for identifying a minor's payment behavior according to an exemplary embodiment of this specification;

FIG. 4 is a schematic diagram of a page shown in an exemplary embodiment of this specification;

FIG. 5 is another schematic diagram of a page shown in an exemplary embodiment of this specification;

FIG. 6 is another schematic diagram of a page shown in an exemplary embodiment of this specification;

FIG. 7 is another schematic diagram of a page shown in an exemplary embodiment of the present specification;

8 is a schematic structural diagram of a device for identifying payment behavior of minors according to an exemplary embodiment of the present specification;

Fig. 9 is a block diagram of a device for identifying a minor's payment behavior according to an exemplary embodiment of the present specification.

Detailed ways

Exemplary embodiments will be described in detail herein, examples of which are illustrated in the accompanying drawings. Where the following description refers to the drawings, the same numerals in different drawings refer to the same or similar elements unless otherwise indicated. The implementations described in the illustrative examples below are not intended to represent all implementations consistent with this specification. Rather, they are merely examples of apparatus and methods consistent with some aspects of this specification as recited in the appended claims.

The terms used in this specification are for the purpose of describing particular embodiments only and are not intended to limit the specification. As used in this specification and the appended claims, the singular forms "a," "the," and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. It will also be understood that the term "and/or" as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

It should be understood that although the terms first, second, third, etc. may be used in this specification to describe various information, such information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, the first information may also be referred to as the second information, and similarly, the second information may also be referred to as the first information, without departing from the scope of the present specification. Depending on the context, the word "if" as used herein can be interpreted as "at the time of" or "when" or "in response to determining."

With the continuous development of technology, people can realize various services through terminal devices, such as watching movies, playing games, buying tickets, paying utility bills, etc. with mobile phones and tablet computers. The relationship between these services and payment The connection is also getting closer.

In real life, minors are likely to use their parents' mobile phones to surf the Internet, play games, etc., so in the process of using mobile phones, minors are likely to have misoperations resulting in unnecessary payment requests, or playing games. Excessive recharge, excessive consumption, etc. during the game. On the one hand, this will bring certain economic losses to their parents; on the other hand, the behavior of indulging in games and excessive consumption is not conducive to the physical and mental health of minors. It is necessary to identify the payment behavior of minors. However, in the related art, when the user-initiated payment behavior is identified, the identification result is often inaccurate.

Taking the game industry as an example, it is generally possible to determine whether a player is a minor through real-name authentication. However, not all game merchants have the user's real-name authentication information, and even if they have the user's real-name authentication information, when minors use their parents' mobile phones to play games, the game accounts are likely to be real-named based on their parents' identities. If it is authenticated, it is very likely that the player currently playing the game is an adult, so it is impossible to identify whether the payment request in the game is initiated by a minor, resulting in an inaccurate identification result.

Based on this, this specification provides a method for identifying the payment behavior of minors.

First, the business parties, payment parties and collaborating parties involved in this specification will be explained. Please refer to FIG. 1. FIG. 1 is a schematic diagram of a structure shown in an exemplary embodiment of the present specification.

The business side in this specification can be a provider of business services. The business side can deploy a server or server cluster as a server, and develop client software that can be loaded in terminal devices, such as APP (Application, application program), and users can Execute business operations in the client, and realize business services through the interaction between the client and the server. For ease of understanding, this specification only provides a schematic description of business parties, such as game providers, ticket service providers, etc., and the specific clients, servers and the relationships between them are not discussed too much.

The payer in this specification can be the party that realizes the payment. Similar to the business side, this specification only describes the business side schematically, such as a third-party payment platform.

To identify the payment behavior of minors, a feasible way is based on the model. The business side can often have the user's business-related data, such as the user's recharge records, consumption records, and browsing records, etc., but the business side may not know whether the user is an adult or a minor, and cannot train the model based on its own data. The user of the payer is likely to be authenticated by real-name identity and can know whether the user is an adult or a minor, but the payer often only has the payment-related data of the user, such as payment amount, payment frequency, payment success rate, etc. These data There is no direct relationship with the data of the business side, and the payer cannot train the model based on the payment-related data it owns to identify the user's behavior on the business side. In this case, the model can be trained by combining the data of the business side and the data of the payer.

However, the payer and the business party probably do not want to reveal their data to each other in the process of model training. In this case, a collaborating party can be added. The collaborating party can be considered as a third party trusted by both the payment party and the business party.

The identification model can be obtained by joint training of the payer, the business party and the collaborating party, and the identification model can be used to identify the payment behavior of minors. After the training is completed, the model held by the business party can be called the first identification sub-model, and the model held by the payer can be called the second identification sub-model. The model structures of the first recognition sub-model and the second recognition sub-model may be the same, and may respectively possess a part of the model parameters of the recognition model.

In this way, during the identification process, the business party can input the business data owned by itself into the first identification sub-model, obtain the business identification result, and send the business identification result to the collaborating party (arrow 1 in FIG. 1 ). ). The payer can input the payment data owned by itself into the second identification sub-model, obtain the payment identification result, and send the service identification result to the cooperating party (arrow 2 in FIG. 1 ). The collaborating parties can summarize the payment identification results and business identification results, and then identify minors' payment behaviors based on the aggregated results. And the collaborating party can also return the identification result to the business party and the paying party (arrow 3 and arrow 4 in Figure 1). Using this method, the payer and the business party can comprehensively identify the payment behavior of minors in combination with the other party's data without revealing their own data.

The following describes the joint training method of the business party, the payer and the collaborating party in this specification.

First, the business side and the service side can respectively determine the business sample users and payment sample users for training the recognition model.

When the business is a game business, the business sample users can be all or some of the player users owned by the game provider, and the business sample features can be the user's account information, such as account ID, account level, account activity, The associated account of the account, etc., may also be the user's behavior information, such as the user's browsing records, historically participated activities, historical recharge records, and so on.

Payment sample users can be all users owned by the payment platform, or a part of users. The payment sample features can be the user's payment information, such as payment amount, payment frequency, payment success rate, biometric verification times, whether there is a minor's biometric verification record, and whether there is a switch from biometric verification to password verification. Among them, the biometrics may include human face, fingerprint, iris, voice, handwriting and so on. Of course, the payment sample feature may also include the user's basic information, such as the user's name, gender, age, address, and so on.

In addition, the payer can also determine whether the user is an adult or a minor based on the user's real-name authentication information, that is, the payer can also have a sample label. For example, if the user is a minor, the sample label is 1; For adults, then the sample label is 0.

Of course, the above examples are only schematic descriptions, and other business sample features and payment sample features can also be obtained in practical situations, which are not specially limited in this specification.

In this embodiment, after the service sample features and payment sample features for training are extracted, in order not to leak these data, the service sample features and payment sample features can also be encrypted, and only the encrypted data is exchanged between the payer and the business party. , only trusted collaborators can process the decrypted data.

The sample data can be encrypted by asymmetric encryption. The collaborating party can distribute its own public key to the business party and the payer, and the business party can use the public key to encrypt to obtain an encrypted service sample and send it to the collaborator; the payer can use the public key to encrypt to obtain an encrypted payment sample, and sent to collaborators. After receiving the encrypted business sample and encrypted payment sample, the collaborator can decrypt it with its own private key.

The encryption algorithm may use the RSA algorithm, and for details, refer to related technologies.

In this embodiment, since the user groups owned by the paying party and the cooperating party are likely to be different, they may have some users owned by both parties, or may each have some users that the other party does not have. For example, a user may have done business on the payment platform and have payment-related business data. However, the user has not played games on a certain game platform, so the user does not have game-related business data. In this case, the collaborating party can also perform sample alignment after receiving the sample users sent by the payer and the business party. The so-called sample alignment can be understood as extracting the overlapping users jointly owned by the payer and the business party, and eliminating the non-overlapping users.

The sample alignment can be performed by the collaborating parties. For example, the collaborating parties can extract common users according to the user's identity information. The sample alignment can also be performed by the business party and the payer. For details, please refer to the relevant technology, which will not be described one by one in this specification.

After the samples are aligned, the model can be trained with these samples. The method for jointly training the recognition model is described below.

The identification model in this embodiment may be a logistic regression model, or may be other models, which are not particularly limited in this specification.

Please refer to FIG. 2 , which is a schematic diagram of a joint training method shown in an exemplary embodiment of the specification. The method shown in FIG. 2 may be used for iterative training until the training requirements are met.

It is worth noting that, in the embodiment shown in FIG. 2 , the business party and the payer have performed sample alignment with each other, so the business samples and payment samples referred to in this embodiment are the samples corresponding to the users jointly owned by both parties. , and these samples are encrypted.

In the process of each iterative training, the business party and the payer can select a part of the samples for this iterative training. For example, the business party and the payer can select business samples and payment samples in the same time period for training in each iteration, so that the user's behavior can be analyzed from the same time period and the accuracy of the model prediction can be improved.

The following is an example of an iterative training.

The method for joint training may include the following steps:

Step 102, the business party trains the first identification sub-model based on the encrypted business sample.

Step 104, the service sends the intermediate result to the payer.

The ultimate purpose of this embodiment is to train an identification model that can identify the payment behavior of minors. The identification model is jointly trained by the payer, the collaborator and the business party, wherein the business party can be trained with the first identifier. model, the payer can be trained with a second identification sub-model. These two sub-models can be understood as "semi-models" of the recognition model, which are respectively used for training to obtain a part of the model parameters of the recognition model. Based on these two sub-models, the prediction function of the recognition model can be realized.

In this embodiment, the business party can first train the first identification sub-model by using the encrypted business samples it owns, and then send the intermediate result to the payer. The intermediate result may be the result predicted by the first identification sub-model in this iterative training.

Step 106, the payer trains the second identification sub-model based on the received intermediate results and the encrypted payment samples owned by the payer.

The payer may input the intermediate results and encrypted payment samples into the second identification sub-model to train the second identification sub-model.

Step 108, the payer calculates the gradient of the second identification sub-model in this iteration.

In this embodiment, the payer can calculate the loss value of this iteration based on the loss function. And the gradient of the second recognition sub-model in this iteration can also be calculated based on the loss function. For the specific loss calculation method and gradient calculation method, refer to the related art, which will not be repeated here in this specification.

Step 110, the payment direction sends the gradient of the second identification sub-model to the collaborating party.

Step 112, the payment direction sends the gradient factor to the business party.

Step 114, the business party calculates the gradient of the first identification sub-model in this iteration based on the gradient factor.

Step 116, the service sends the gradient of the first identification sub-model to the collaborating party.

In this embodiment, the payer may send the gradient factor to the business side. The gradient factor can be understood as a formula for assisting the business party to calculate the gradient of the first identification sub-model.

The business party may calculate the gradient of the first identification sub-model in this iteration based on the gradient factor using the encrypted business sample, and send the gradient to the collaborating party.

Step 118, the cooperating party calculates the total gradient based on the gradient of the first identification sub-model and the gradient of the second identification sub-model.

In this embodiment, after receiving the gradient of the first identification sub-model and the gradient of the second identification sub-model, the cooperating party may calculate the total gradient based on the two gradients.

The method for calculating the total gradient is related to the type of the recognition model. For example, when the recognition model is a logistic regression model, the total gradient can be calculated by a summation method. Certainly, other methods may also be adopted in other embodiments, which are not specially limited in this specification.

Step 120, the cooperative sends the total gradient to the payer.

Step 122, the payer updates the model parameters of the second identification model based on the total gradient.

Step 124, the cooperative direction sends the total gradient to the service party.

Step 126, the business party updates the model parameters of the first recognition model based on the total gradient.

In this embodiment, after the cooperating party calculates and obtains the total gradient, it can decrypt the total gradient, and send the decrypted total gradient to the payer and the business party respectively, and then the payer and the business party can use the decrypted total gradient to determine Update the respective model parameters. The method for updating the model parameters refers to the related art, and details are not described here.

At this point, the iterative training is completed.

In this embodiment, whether the training requirement is met can be judged by whether the loss function converges.

For example, in step 108, the payer may send the loss value to the collaborating party after calculating the loss value of this iteration (the loss value at this time is encrypted). The collaborating party can decrypt the loss value, and then judge whether the decrypted loss value is less than the threshold. If it is less than the threshold, it will converge and meet the training requirements;

Of course, other methods can also be used to judge whether the training requirements are met, such as judging whether the number of times of iterative training has reached the times threshold, etc., which is not specifically limited in this specification.

After clarifying that the paying party, the business party and the collaborating party jointly train the identification model, the following describes a method for identifying the payment behavior of minors provided in this specification.

Please refer to FIG. 3 , which is a schematic diagram of a method for identifying a minor's payment behavior according to an exemplary embodiment of this specification. The method for identifying the payment behavior of minors may include the following steps:

Step 202, in response to the payment request initiated by the user, the business party obtains the business characteristics of the user, and inputs the business characteristics into the first identification sub-model to obtain a business identification result;

Step 204, the service direction sends the service identification result to the cooperating party;

Step 206, the payer obtains the payment feature of the user in response to the payment request, and inputs the payment feature into the second identification sub-model to obtain a payment identification result;

Step 208, sending the payment identification result to the cooperating party;

Step 210, the collaborating party determines whether the user's payment behavior is a minor payment behavior according to the service identification result and the payment identification result;

The above steps are described in detail below.

In this embodiment, a user may initiate a payment request, and the payment request may be a recharge request, a payment request, a shopping consumption request, etc., which are not particularly limited in this specification.

After the business party receives the payment request, it can respond to the payment request, obtain the user's business characteristics, and then input the business characteristics into the first identification sub-model deployed by the business party to obtain the business identification result, and pay The identification result is sent to the collaborating party.

For the specific content of the service feature, reference may be made to the foregoing embodiments, which will not be repeated here. It is worth noting that, because in this embodiment, the business features obtained by the business party are only used for input into the first identification sub-model deployed on the local side, and will not be leaked to the payer, so there is no need to carry out the business features. Instead, the original service characteristics can be directly input into the first identification sub-model.

In this embodiment, the payer can also receive the payment request, and in response to the payment request, obtain the payment characteristics of the user, input the payment characteristics into the second identification sub-model deployed on the payer side, and obtain the payment identification result , and send the payment identification result to the collaborating party.

The payment feature may also refer to the foregoing embodiments, and for the reasons similar to the above, the payment feature may not be encrypted.

In actual situations, the payer may receive a large number of payment requests at the same time, and it is necessary to determine which payment requests require juvenile behavior identification and which requests do not require juvenile behavior identification. In this case, the payment request initiated by the user can also carry the identification of the business party, then the payer can judge whether the identification in the payment request matches the preset identification. If it matches, it means that the payment request is from a specific business party. For example, in the game platform, there is the possibility of minors' payment behavior, and it is necessary to identify the behavior of minors for the request, and then obtain the payment characteristics of the user; if it does not match, it means that the request is a regular payment request, such as shopping initiated by the user Requests, repayment requests, etc., do not need to identify the behavior of minors, and process the payment request according to conventional methods.

In this embodiment, the payment feature acquired by the payer and the service feature acquired by the business party may also belong to the same time period. For example, the payer can obtain the payment features of the user in the last month, and the business party can obtain the service features of the user in the last month. In this way, the user's behavior can be analyzed from the data of the same time period, and a more accurate identification result can be obtained.

In this embodiment, the collaborating party may determine whether the user's payment behavior is a minor's payment behavior based on the received payment identification result and service identification result.

For example, assuming that the recognition model is a logistic regression model, the collaborators can sum the payment recognition results and service recognition results, and determine the user's payment behavior based on the summed results. The summation here may be a direct summation or a weighted summation, etc. The summation method may be determined according to the actual situation, which is not specially limited in this specification.

In this embodiment, assuming that the result obtained by the summation is the score of the minor's payment behavior, it can be determined whether the score is greater than the score threshold, and if it is greater, it indicates that the minor's payment behavior. For example, assuming that the preset score threshold is 0.6, the score obtained by summation is 0.8, and 0.8 is greater than 0.6, indicating that the current user's payment behavior is a minor's payment behavior.

Of course, the above examples are only schematic descriptions, and other methods can also be adopted in practical situations, which are not specially limited in this specification.

It is worth noting that in this embodiment, steps 206-208 are after steps 202-204. In actual situations, steps 206-208 may also be executed before steps 202-204, or may be executed in parallel, which is not specially made in this specification. limit.

As can be seen from the above description, in an embodiment of this specification, the business party can respond to the payment request initiated by the user, obtain the user's business characteristics and input it into the first identification sub-model, obtain the business identification result and send it to the collaboration. The payer can respond to the payment request initiated by the user, obtain the user's payment feature and input it into the second identification sub-model, obtain the payment identification result and send it to the collaborating party. The collaborating party may determine whether the user's payment behavior is a minor payment behavior based on the service identification result and the payment identification result.

Using the above method, the identification model can be obtained through joint training of the business party and the payer through the data of the business party and the payer, and after receiving the payment request initiated by the user, it is possible to predict whether the user's payment behavior is a minor payment based on the identification model. It solves the problem that the payment behavior of minors cannot be identified in related technologies, or the identification results are inaccurate. In addition, the above method can use the data of multiple parties to train the recognition model, so as to obtain a model with better performance and more accurate prediction results, and the original data owned by the payer and the business party themselves will not be leaked during the joint training process, ensuring that data security.

The following describes another method for identifying the payment behavior of minors provided in this specification.

In this embodiment, it is assumed that the business party is the game provider and the payer is a third-party payment platform. The following describes the method for identifying the minors' payment behavior in conjunction with the schematic diagram of the client page of the game provider.

Please refer to FIG. 4 , which is a schematic diagram of a page shown in an exemplary embodiment of this specification.

In this embodiment, the user can open the "wallet" page on the APP developed by the game provider, and the page can display the gold coin balance of the player's account, and can also display several "recharge" buttons with different amounts, as shown in Figure 4 "10 gold coins 1.00 yuan", "60 gold coins 6.00 yuan", "300 gold coins 30.00 yuan". If the user wants to initiate a recharge, they can click on these "recharge" buttons.

Suppose the user clicks the button of "60 gold coins and 6.00 yuan". On the one hand, the game provider can receive the payment request initiated by the user, and then, in response to the payment request, obtain the user's service characteristics, and input the service characteristics into the first In an identification sub-model, the business identification result is obtained, and the business identification result is sent to the cooperating party. For details, refer to the foregoing embodiments.

On the other hand, you can also jump out of the payment page at the bottom of the page. A variety of payment methods can be displayed on the payment page, such as "third-party payment platform payment" and "online bank payment" in Figure 4. Users can choose the payment method they want to recharge. As shown in Figure 4, the current default payment method is "Third-party payment platform payment". If the user confirms that it is correct, he can click the "Confirm Payment" button below.

After the user clicks this button, the cashier page can be displayed to the user, as shown in Figure 5. Several different payment methods can be displayed on the cashier page, such as Huabei payment, account balance payment, and bank card payment. Assuming that the user chooses bank card payment, the verification page can be further displayed to the user.

Referring to Figure 6, the user may be prompted to enter a password on the verification page, and the user's identity can be verified by means of password verification. Of course, other verification methods may also be adopted in other embodiments.

After the user enters the password, the third-party payment platform may receive a payment request initiated by the user, and the payment request may also include the identifier of the game provider. The third-party payment platform can verify the password first. If the verification fails, other subsequent steps below will not be performed, and further steps will be performed only when the verification is passed.

Assuming that the password entered by the user passes the verification, the third-party payment platform can further determine whether the identifier matches the preset identifier according to the identifier of the game provider carried in the payment request. If it matches, the payment feature is acquired, and the payment feature is input into the second identification sub-model to obtain the payment identification result, and then the payment identification result is sent to the collaborating party. For details, refer to the foregoing embodiments.

Similarly, after receiving the payment request initiated by the user, the game provider can also obtain the user's business characteristics, and then input the business characteristics into the first identification sub-model to obtain the business identification result, and send the business identification result to the collaboration. square.

The collaborating party can obtain the result of whether the user's payment behavior is a minor payment based on the payment identification result and the service identification result, and return the result to the third-party payment platform, and the third-party payment platform can perform different payment strategy. In this embodiment, it is assumed that there are 3 payment strategies, corresponding to 3 different identification results:

1. When the identification result is adult payment behavior, process the payment request;

2. When the identification result is a minor's payment behavior, prompt the user to perform biometric verification, and process the payment request if the verification is passed;

3. When the identification result is a suspected minor payment behavior, the payment request is processed and a reminder is output.

The above three payment strategies are described below with a specific example.

In this embodiment, it is assumed that the identification result sent by the collaborating party is that the payment behavior is a score paid by a minor, and the score is 1 when a minor is a minor; the score is 0 when an adult, and the following three score intervals can be set :

When the score is 0~0.5, it is paid for adults;

When the score is 0.5~0.8, it is paid for suspected minors;

When the score is 0.8~1.0, it is paid for minors.

Then, after receiving the points paid by the minors returned by the collaborating party, the third-party payment platform can compare the points with the above interval, and then select a corresponding payment strategy according to the comparison result. Of course, in other embodiments, the collaborating party may also compare the score with the above score range, and directly return the final identification result to the third-party payment platform.

In one case, when the comparison result is that an adult pays, the third-party payment platform can execute the payment request according to a conventional method.

In another case, when the comparison result is suspected to be a minor payment, the payment request can be executed according to the conventional method, and a reminder can also be output on the page where the payment is successful, as shown in the “Xiao Krypton” in Figure 7 Happy, sad, big krypton." Of course, other reminders can also be output, such as: "Healthy games, moderate consumption" (not shown), "You recharge too frequently, stop and rest~" (not shown).

Of course, in addition to the above-mentioned successful payment page, reminders can also be output on other pages, such as the aforementioned verification page, cashier page, etc., which are not specially limited in this specification.

In another case, when the comparison result is that the payment is made by a minor, a biometric verification page may also be displayed to the user, for example, a face recognition page may be displayed to the user. If the user's face-swiping authentication passes, the subsequent relevant steps may be further performed to complete the payment request; if the user's face-swiping authentication fails, the subsequent payment-related steps are not executed.

Using this method, if minors use their parents' mobile phones to recharge the game, and the third-party payment platform on the mobile phone is bound to their parents' accounts, then only the parents' face images can be authenticated by face-swiping. If a minor uses their own face image to swipe their face, the authentication will fail, and subsequent payment steps will not be executed, which is equivalent to intercepting the payment request initiated by the minor from the side, avoiding the need for minors to Indulge in the game for a lot of recharge. Moreover, payment requests initiated by some minors' misoperations can also be avoided.

Of course, in other embodiments, other biometric authentication methods, such as iris authentication, voice authentication, handwriting authentication, etc., may also be adopted.

It is worth noting that all the schematic diagrams of pages shown in this embodiment are schematic descriptions, and other schematic diagrams of pages may also be used in actual situations, which are not specially limited in this specification.

It can be seen from the above description that in an embodiment of this specification, after a user initiates a payment request, the model jointly trained by the business party and the payer can be used to identify whether the payment request is initiated by a minor, so as to improve the reliability of the identification result. accuracy. In addition, different payment strategies can be adopted according to the identification results, so that the payment requests of adults can be processed, and the payment requests of minors can be intercepted, which can prevent minors from being addicted to games to a certain extent. A lot of recharge.

Corresponding to the foregoing embodiments of the method for identifying the payment behavior of minors, the present specification also provides an embodiment of the device for identifying the payment behavior of minors.

The embodiment of the device for identifying the payment behavior of minors in this specification can be applied to the server of the payer. The apparatus embodiment may be implemented by software, or may be implemented by hardware or a combination of software and hardware. Taking software implementation as an example, a device in a logical sense is formed by reading the corresponding computer program instructions in the non-volatile memory into the memory for operation by the processor of the server where it is located. From the perspective of hardware, as shown in FIG. 8 , it is a hardware structure diagram of the server where the device for identifying the payment behavior of minors is located in this specification, except for the processor, memory, network interface, and nonvolatile In addition to the non-volatile storage, the server where the device is located in the embodiment may also include other hardware generally according to the actual function of the server, which will not be repeated here.

Fig. 9 is a block diagram of a device for identifying a minor's payment behavior according to an exemplary embodiment of the present specification.

Please refer to FIG. 9 , the apparatus 900 for identifying the payment behavior of minors can be applied to the server shown in the aforementioned FIG. .

Wherein, the obtaining unit 910, in response to the payment request initiated by the user, obtains the payment feature of the user;

Input unit 920, inputting the payment feature into the second identification sub-model to obtain a payment identification result;

The sending unit 930 sends the payment identification result to the collaborating party, so that the collaborating party determines whether the user's payment behavior is a minor payment behavior based on the payment identification result and the service identification result sent by the business party,

Wherein, the business identification result is obtained by the business party obtaining business features in response to the payment request, and inputting the business features into the first identification sub-model.

Optionally, the payment request carries the identifier of the business party, and the obtaining unit 910:

Judging whether the identity of the business party matches a preset identity;

If there is a match, obtain the payment characteristics of the user.

Optionally, the device further includes:

A receiving unit 940, receiving the identification result of the user's payment behavior returned by the collaborating party;

The executing unit 950 executes a corresponding payment strategy based on the identification result.

Optionally, the execution unit 950:

When the identification result is an adult payment behavior, process the payment request;

When the identification result is a minor payment behavior, prompt the user to perform biometric verification, and process the payment request if the verification is passed;

When the identification result is a suspected minor payment behavior, the payment request is processed and a reminder is output.

Optionally, the service feature and the payment feature belong to the same time period.

For details of the implementation process of the functions and functions of each unit in the above device, please refer to the implementation process of the corresponding steps in the above method, which will not be repeated here.

As for the apparatus embodiments, since they basically correspond to the method embodiments, reference may be made to the partial descriptions of the method embodiments for related parts. The device embodiments described above are only illustrative, wherein the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in One place, or it can be distributed over multiple network elements. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution in this specification. Those of ordinary skill in the art can understand and implement it without creative effort.

The systems, devices, modules or units described in the above embodiments may be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementing device is a computer, which may be in the form of a personal computer, laptop computer, cellular phone, camera phone, smart phone, personal digital assistant, media player, navigation device, email sending and receiving device, game control desktop, tablet, wearable device, or a combination of any of these devices.

Corresponding to the foregoing embodiments of the method for identifying a minor's payment behavior, this specification also provides a device for identifying a minor's payment behavior, the device including: a processor and a memory for storing machine-executable instructions. Among them, the processor and the memory are usually connected to each other by means of an internal bus. In other possible implementations, the device may also include an external interface to enable communication with other devices or components.

In this embodiment, the processor is caused to:

In response to a payment request initiated by the user, acquiring the payment feature of the user;

Inputting the payment feature into the second identification sub-model to obtain a payment identification result;

Sending the payment identification result to the collaborating party, so that the collaborating party determines whether the user's payment behavior is a minor payment behavior based on the payment identification result and the service identification result sent by the business party,

Wherein, the business identification result is obtained by the business party obtaining business features in response to the payment request, and inputting the business features into the first identification sub-model.

Optionally, the payment request carries the identity of the business party, and when acquiring the payment characteristics of the user, the processor is prompted to:

Judging whether the identity of the business party matches a preset identity;

If there is a match, obtain the payment characteristics of the user.

Optionally, the processor is further caused to:

Receive the identification result of the user's payment behavior returned by the collaborator;

Based on the identification result, a corresponding payment strategy is executed.

Optionally, when executing a corresponding payment strategy based on the identification result, the processor is prompted to:

When the identification result is an adult payment behavior, process the payment request;

When the identification result is a minor payment behavior, prompt the user to perform biometric verification, and process the payment request if the verification is passed;

When the identification result is a suspected minor payment behavior, the payment request is processed and a reminder is output.

Optionally, the service feature and the payment feature belong to the same time period.

optional,

The payment features include: payment amount, payment frequency, payment success rate, historical biometric verification times, whether there is a minor biometric verification record, and whether there is a switch from biometric verification to password verification;

The service features include: account level, account activity, recharge records, consumption records and browsing records.

Corresponding to the foregoing embodiments of the method for identifying the payment behavior of minors, this specification also provides a computer-readable storage medium, on which a computer program is stored, and when the program is executed by the processor, the following is realized: step:

In response to a payment request initiated by the user, acquiring the payment feature of the user;

Inputting the payment feature into the second identification sub-model to obtain a payment identification result;

Sending the payment identification result to the collaborating party, so that the collaborating party determines whether the user's payment behavior is a minor payment behavior based on the payment identification result and the service identification result sent by the business party,

Wherein, the business identification result is obtained by the business party obtaining business features in response to the payment request, and inputting the business features into the first identification sub-model.

Optionally, the payment request carries the identifier of the business party, and the acquiring the payment characteristics of the user includes:

Judging whether the identity of the business party matches a preset identity;

If there is a match, obtain the payment characteristics of the user.

Optionally, also include:

Receive the identification result of the user's payment behavior returned by the collaborator;

Based on the identification result, a corresponding payment strategy is executed.

Optionally, executing a corresponding payment strategy based on the identification result, including:

When the identification result is an adult payment behavior, process the payment request;

When the identification result is a minor payment behavior, prompt the user to perform biometric verification, and process the payment request if the verification is passed;

When the identification result is a suspected minor payment behavior, the payment request is processed and a reminder is output.

Optionally, the service feature and the payment feature belong to the same time period.

optional,

The payment features include: payment amount, payment frequency, payment success rate, historical biometric verification times, whether there is a minor biometric verification record, and whether there is a switch from biometric verification to password verification;

The service features include: account level, account activity, recharge records, consumption records and browsing records.

The foregoing describes specific embodiments of the present specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that in the embodiments and still achieve desirable results. Additionally, the processes depicted in the figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

The above descriptions are only preferred embodiments of this specification, and are not intended to limit this specification. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of this specification shall be included in this specification. within the scope of protection.

Claims (17)

1. a method for identifying the payment behavior of minors, realizes the identification of the payment behavior of minors based on the identification model obtained by the joint training of the business party, the payer and the collaborating party, wherein the business party is deployed with the first identifier. model, the payer is deployed with a second identification sub-model, and the method includes: In response to the payment request initiated by the user, the business party obtains the business characteristics of the user, and inputs the business characteristics into the first identification sub-model to obtain a business identification result; The business party sends the business identification result to the collaborating party; In response to the payment request, the payer obtains the user's payment characteristics, and inputs the payment characteristics into the second identification sub-model to obtain a payment identification result; The paying party sends the payment identification result to the collaborating party; The collaborating party determines whether the user's payment behavior is a minor's payment behavior according to the service identification result and the payment identification result. 2. The method according to claim 1, wherein the payment request carries the identification of the business party, and the payment party obtains the payment characteristics of the user, comprising: The payer determines whether the identifier of the business party matches the preset identifier; If there is a match, obtain the payment characteristics of the user. 3. The method of claim 1, further comprising: The collaborating party sends the identification result of the user's payment behavior to the paying party; The payer executes a corresponding payment strategy based on the identification result. 4. The method according to claim 3, wherein the payer executes a corresponding payment strategy based on the identification result, comprising: When the identification result is an adult payment behavior, process the payment request; When the identification result is a minor payment behavior, prompt the user to perform biometric verification, and process the payment request if the verification is passed; When the identification result is a suspected minor payment behavior, the payment request is processed and a reminder is output. 5. The method according to claim 1, wherein the service feature and the payment feature belong to the same time period. 6. The method of claim 1, The payment features include: payment amount, payment frequency, payment success rate, historical biometric verification times, whether there is a minor biometric verification record, and whether there is a switch from biometric verification to password verification; The service features include: account level, account activity, recharge records, consumption records and browsing records. 7. A method for identifying the payment behavior of minors, realizing the identification of the payment behavior of minors based on the identification model obtained by joint training of the business party, the payer and the collaborating party, wherein the business party is deployed with a first identifier. model, the payer is deployed with a second identification sub-model, the method is applied to the payer, and the method includes: In response to a payment request initiated by the user, acquiring the payment feature of the user; Inputting the payment feature into the second identification sub-model to obtain a payment identification result; Sending the payment identification result to the cooperating party, so that the cooperating party determines whether the user's payment behavior is a minor payment behavior based on the payment identification result and the service identification result sent by the business party; Wherein, the service identification result is obtained by the service party obtaining the user's service characteristics in response to the payment request, and inputting the service characteristics into the first identification sub-model. 8. The method according to claim 7, wherein the payment request carries the identification of the business party, and the acquisition of the user's payment characteristics comprises: Judging whether the identity of the business party matches a preset identity; If there is a match, obtain the payment characteristics of the user. 9. The method of claim 7, further comprising: Receive the identification result of the user's payment behavior returned by the collaborator; Based on the identification result, a corresponding payment strategy is executed. 10. The method according to claim 9, wherein, based on the identification result, executing a corresponding payment strategy, comprising: When the identification result is an adult payment behavior, process the payment request; When the identification result is a minor payment behavior, prompt the user to perform biometric verification, and process the payment request if the verification is passed; When the identification result is a suspected minor payment behavior, the payment request is processed and a reminder is output. 11. The method according to claim 7, wherein the service feature and the payment feature belong to the same time period. 12. An identification device for minors' payment behavior, which realizes the identification of minors' payment behavior based on the identification model jointly trained by the business party, the payer and the collaborating party, wherein the business party is deployed with a first identifier. model, the payer is deployed with a second identification sub-model, the device is applied to the payer, and the device includes: an acquiring unit, in response to a payment request initiated by the user, acquiring the payment feature of the user; an input unit, inputting the payment feature into the second identification sub-model to obtain a payment identification result; The sending unit sends the payment identification result to the collaborating party, so that the collaborating party determines whether the user's payment behavior is a minor payment behavior based on the payment identification result and the service identification result sent by the business party; The service identification result is obtained by the service party obtaining the user's service characteristics in response to the payment request, and inputting the service characteristics into the first identification sub-model. 13. The device according to claim 12, wherein the payment request carries the identification of the business party, and the acquisition unit: Judging whether the identity of the business party matches a preset identity; If it matches, obtain the payment characteristics of the user. 14. The apparatus of claim 12, further comprising: a receiving unit, receiving the identification result of the user's payment behavior returned by the collaborating party; The execution unit executes the corresponding payment strategy based on the identification result. 15. The apparatus according to claim 14, the execution unit: When the identification result is an adult payment behavior, process the payment request; When the identification result is a minor payment behavior, prompt the user to perform biometric verification, and process the payment request if the verification is passed; When the identification result is a suspected minor payment behavior, the payment request is processed and a reminder is output. 16. The apparatus according to claim 12, wherein the service feature and the payment feature belong to the same time period. 17. An identification device for minors' payment behavior, which realizes the identification of minors' payment behavior based on the identification model jointly trained by the business party, the payer and the collaborating party, wherein the business party is deployed with a first identifier. model, the payer is deployed with a second identification sub-model, the device is applied to the payer, and the device includes: processor; memory for storing machine-executable instructions; Wherein, by reading and executing the machine-executable instructions stored in the memory corresponding to the identification logic of the minor's payment behavior, the processor is caused to: In response to a payment request initiated by the user, acquiring the payment feature of the user; Inputting the payment feature into the second identification sub-model to obtain a payment identification result; Sending the payment identification result to the cooperating party, so that the cooperating party determines whether the user's payment behavior is a minor payment behavior based on the payment identification result and the service identification result sent by the business party; The service identification result is obtained by the service party obtaining the user's service characteristics in response to the payment request, and inputting the service characteristics into the first identification sub-model.

Images