Merchant order risk control method and device

Abstract

The invention provides a merchant order risk control method and device, and the method comprises the steps: carrying out the account registration according to a mobile phone number, and enabling the registration not to be allowed if the mobile phone number is a virtual number; if the mobile phone number is not the virtual number, account registration is allowed; acquiring account data when an account creates a purchase order, and judging whether the purchase order is a risk order or not according to the account data; if the purchase order is a risk order, entering a risk prompt page when the account carries out payment, and then carrying out payment after the account confirms; if the purchase order is a normal order, the user directly pays; all newly paid accounts are monitored, and if the account does not use the system function within the set time after payment, the purchase order is processed according to the risk strategy, so that a merchant can conveniently carry out risk control, and the payment account is prevented from being sealed and controlled.

Description

Technical Field

[0001] The present invention relates to the field of Internet technology, and in particular to a method and device for merchant order risk control. Background Art

[0002] Currently, merchants have launched a payment service system, and users can enjoy the functions of the system through online payment. Users only need to scan the payment QR code provided by the merchant to complete the payment directly through payment applications such as Alipay or WeChat. However, some lawless elements take advantage of this convenience to induce users to make involuntary payment operations. This not only damages the rights and interests of users, but may also cause users to report the payment account through the background of the payment channel, which in turn causes the payment account to be blocked. This situation seriously affects the normal trading activities of merchants and brings unnecessary economic losses to merchants. Summary of the invention

[0003] The technical problem to be solved by the present invention is to provide a method and device for merchant order risk control, which is convenient for users to perform risk control and prevent the collection account from being blocked.

[0004] In a first aspect, the present invention provides a method for merchant order risk control, comprising the following steps: Step 1: Register an account based on your mobile phone number. If the mobile phone number is a virtual number, registration is not allowed; if the mobile phone number is not a virtual number, account registration is allowed; Step 2: When an account creates a purchase order, the account data is obtained, and whether the purchase order is a risky order is determined based on the account data; Step 3: If the purchase order is a risky order, the account will enter the risk warning page when making payment, and then make payment after account confirmation; if the purchase order is a normal order, the user will make payment directly; Step 4: Monitor all newly paid accounts. If the account does not use system functions within the set time after payment, the purchase order will be processed according to the risk strategy.

[0005] In a second aspect, the present invention provides a device for merchant order risk control, comprising: The registration module registers an account based on the mobile phone number. If the mobile phone number is a virtual number, registration is not allowed; if the mobile phone number is not a virtual number, account registration is allowed; The risk judgment module obtains account data when an account creates a purchase order, and determines whether the purchase order is a risky order based on the account data; Payment module: if the purchase order is a risky order, the account will enter the risk warning page when making payment, and then make payment after account confirmation; if the purchase order is a normal order, the user will make payment directly; The monitoring module monitors all new paid accounts. If the account does not use system functions within the set time after payment, the purchase order will be processed according to the risk strategy.

[0006] One or more technical solutions provided by the present invention have at least the following technical effects or advantages: Through the method of the present invention, the risks of paying users can be controlled. When it is determined that it is a risky order, it can be processed in time to prevent the merchant's payment account from being blocked. In addition, during the transaction, risk reminders can be given based on risk prediction, so that users can clearly understand the risk situation.

[0007] The above description is only an overview of the technical solution of the present invention. In order to more clearly understand the technical means of the present invention, it can be implemented according to the contents of the specification. In order to make the above and other purposes, features and advantages of the present invention more obvious and easy to understand, the specific implementation methods of the present invention are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] The present invention will be further described below in conjunction with embodiments with reference to the accompanying drawings.

[0009] Figure 1 is a flow chart of the method in Embodiment 1 of the present invention; Figure 2 It is a schematic diagram of the structure of the device in the second embodiment of the present invention. DETAILED DESCRIPTION

[0010] The embodiments of the present application provide a method and device for merchant order risk control, which monitors the entire process of user ordering and performs corresponding monitoring after payment, thereby ensuring that the orders are genuine and reducing the situation where the company's collection account is blocked.

[0011] The technical solution in the embodiment of the present application has the following general idea: Register based on the mobile phone number. If the mobile phone number is a virtual number, registration is not allowed; if the mobile phone number is not a virtual number, registration is allowed; When a user creates an order, a. obtain the user registration time, the IP address of the user creating the order, the browser UserAgent, the device ID, the order type, and the data of the functions used by the user (the function data used by the user in this system before creating an order); b. Conduct risk assessment on user-created orders. If there is a risk, monitor the user during the payment stage (based on the order type. If it is an offline order, it is normal; if it is an online order, continue to judge: Determine whether the user uses the function. If yes, it is normal; if no, continue to judge; Determine the payment amount. If the payment amount is less than the set amount and it is the first payment, it is normal. If the amount is greater than the set amount or it is the second or subsequent payment, risk order monitoring will be performed); User payment, a. If the created order is judged as a risky order, the risk order payment is judged; the IP address of the user's payment order is obtained, and the city where the IP address of the user's order is created is compared with the city where the IP address of the user's payment order belongs. If they are consistent, payment is made directly (WeChat or Alipay payment can be called); If they are inconsistent, the user will be directed to the risk warning page and make the payment after confirmation; b. Risky orders jump to the payment H5 page. If the IP is inconsistent, a risk reminder will be issued. At the same time, an alarm will be sent through DingTalk for monitoring; User is not activated, user is not activated alarm; a. Monitor the use of system functions by all new paying users. If it is found that the system functions have not been used for more than 5 days after payment, the operator will be notified through DingTalk alarm; b. The operator will contact the user to review the account; Risky order processing: once the payment is determined to be a risky order, a refund will be processed in real time (the refund will be returned to the payment account via the original route); b. The account corresponding to the risky order and the IP and device used by the user to create the order will be included in the monitoring; c. If two or more risky orders are found under the same IP or device, access to the IP or device will be restricted.

[0012] Embodiment 1

[0013] like Figure 1 As shown, this embodiment provides a method for merchant order risk control, comprising the following steps: Step 1: Register an account based on your mobile phone number. If the mobile phone number is a virtual number, registration is not allowed; if the mobile phone number is not a virtual number, account registration is allowed; Step 2: When an account creates a purchase order, the account data is obtained, and whether the purchase order is a risky order is determined based on the account data; Step 3: If the purchase order is a risky order, the account will enter the risk warning page when making payment, and then make payment after account confirmation; if the purchase order is a normal order, the user will make payment directly; Step 4: Monitor all newly paid accounts. If the account does not use system functions within the set time after payment, the purchase order will be processed according to the risk strategy.

[0014] In this embodiment, preferably, the step 2 is specifically as follows: when an account creates a purchase order, the account data is obtained, and whether the purchase order is a risky order is determined according to the account data; the account data includes: registration time, IP address of the account creating the purchase order, User Agent of the browser accessing the purchase order, device ID, order type, and function data used by the account; According to the order type, if the order is an offline order, it is a normal order; If the order is an online order, determine whether the function data used by the account is empty. If it is not empty, it is a normal order; if it is empty, determine the payment amount of the purchase order. If the payment amount is less than the first set threshold and the number of payments within the limited time of the account is less than the second set threshold, it is a normal order; if the payment amount is greater than or equal to the first set threshold or the number of payments within the limited time of the account is greater than or equal to the second set threshold, the purchase order is set as a risky order.

[0015] In this embodiment, preferably, the step 3 is specifically as follows: if the purchase order is a risky order, then when making payment, the payer's IP is obtained, and the payer's IP is compared with the city to which the IP of the account creating the purchase order belongs. If they are the same, then jump to the payment H5 page, and the payment H5 page does not include risk warning information, and payment is made after confirmation; if they are different, then jump to the payment H5 page, and the payment H5 page includes risk warning information, and payment is made after confirmation; by setting the risk warning information, the payer can fully understand the risks; If the purchase order is a normal order, payment will be made directly.

[0016] In this embodiment, preferably, the processing of the purchase order according to the risk strategy is specifically as follows: The operator determines whether the purchase order is a risky order based on whether the purchase order is a risky order and the information communicated with the customer. The operator can directly communicate with the user online or by phone through the account information to confirm the risk situation. If the purchase order is confirmed to be a dangerous order, a refund will be processed directly (the refund will be returned to the payment account); the account, the IP address used to create the purchase order, the User Agent used to access the browser, and the device ID will be stored. If there are two or more dangerous orders corresponding to the account, the IP address used to create the purchase order, the User Agent used to access the browser, or the device ID, the access to the account corresponding to the IP address or device ID used to create the purchase order will be restricted; if the purchase order is confirmed not to be a dangerous order, it will not be processed. Through the above methods, the same user can be prevented from making fake orders, thereby preventing and controlling order risks.

[0017] Based on the same inventive concept, the present application also provides a device corresponding to the method in Example 1, see Example 2 for details.

[0018] Embodiment 2

[0019] like Figure 2 As shown, in this embodiment, a device for merchant order risk control is provided, including: The registration module registers an account based on the mobile phone number. If the mobile phone number is a virtual number, registration is not allowed; if the mobile phone number is not a virtual number, account registration is allowed; The risk judgment module obtains account data when an account creates a purchase order, and determines whether the purchase order is a risky order based on the account data; Payment module: if the purchase order is a risky order, the account will enter the risk warning page when making payment, and then make payment after account confirmation; if the purchase order is a normal order, the user will make payment directly; The monitoring module monitors all new paid accounts. If the account does not use system functions within the set time after payment, the purchase order will be processed according to the risk strategy.

[0020] In this embodiment, preferably, the risk judgment module specifically includes: obtaining account data when an account creates a purchase order, and judging whether the purchase order is a risky order according to the account data; the account data includes: registration time, IP address of the account creating the purchase order, User Agent of the browser accessing the browser, device ID, order type, and function data used by the account; order types include online orders and offline orders; According to the order type, if the order is an offline order, it is a normal order; If the order is an online order, determine whether the function data used by the account is empty. If it is not empty, it is a normal order; if it is empty, determine the payment amount of the purchase order. If the payment amount is less than the first set threshold and the number of payments within the limited time of the account is less than the second set threshold, it is a normal order; if the payment amount is greater than or equal to the first set threshold or the number of payments within the limited time of the account is greater than or equal to the second set threshold, the purchase order is set as a risky order.

[0021] In this embodiment, preferably, the payment module is specifically as follows: if the purchase order is a risky order, then when making payment, the payer's IP is obtained, and the payer's IP is compared with the city to which the IP of the account creating the purchase order belongs. If they are the same, then jump to the payment H5 page, and the payment H5 page does not include risk warning information, and payment is made after confirmation; if they are different, then jump to the payment H5 page, and the payment H5 page includes risk warning information, and payment is made after confirmation; by setting the risk warning information, the payer can fully understand the risks; If the purchase order is a normal order, payment will be made directly.

[0022] In this embodiment, preferably, the processing of the purchase order according to the risk strategy is specifically as follows: The operator determines whether the purchase order is a risky order based on whether the purchase order is a risky order and the information communicated with the customer. The operator can directly communicate with the user online or by phone through the account information to confirm the risk situation. If the purchase order is confirmed to be a dangerous order, a refund will be processed directly (the refund will be returned to the payment account); the account, the IP address used to create the purchase order, the User Agent used to access the browser, and the device ID will be stored. If there are two or more dangerous orders corresponding to the account, the IP address used to create the purchase order, the User Agent used to access the browser, or the device ID, the access to the account corresponding to the IP address or device ID used to create the purchase order will be restricted; if the purchase order is confirmed not to be a dangerous order, it will not be processed. Through the above methods, the same user can be prevented from making fake orders, thereby preventing and controlling order risks.

[0023] Since the device introduced in the second embodiment of the present invention is a device used to implement the method of the first embodiment of the present invention, those skilled in the art can understand the specific structure and deformation of the device based on the method introduced in the first embodiment of the present invention, so it is not described here in detail. All devices used in the method of the first embodiment of the present invention belong to the scope of protection of the present invention.

[0024] Although the specific implementation modes of the present invention are described above, those skilled in the art should understand that the specific implementation modes described are only illustrative and are not intended to limit the scope of the present invention. Equivalent modifications and changes made by those skilled in the art in accordance with the spirit of the present invention should be included in the scope of protection of the claims of the present invention.

Claims

1. A method for merchant order risk control, characterized by: The steps include: Step 1: Register an account based on your mobile phone number. If the mobile phone number is a virtual number, registration is not allowed; if the mobile phone number is not a virtual number, account registration is allowed; Step 2: When an account creates a purchase order, the account data is obtained, and whether the purchase order is a risky order is determined based on the account data; The account data includes: registration time, IP address of the account creating the purchase order, User Agent of the access browser, device ID, order type, and data on the functions used by the account; According to the order type, if the order is an offline order, it is a normal order; If the order is an online order, determine whether the account's used function data is empty. If it is not empty, it is a normal order. If it is empty, determine the payment amount of the purchase order. If the payment amount is less than the first set threshold, and the number of payments within the account's limited time is less than the second set threshold, it is a normal order. If the payment amount is greater than or equal to the first set threshold or the number of payments within the account's limited time is greater than or equal to the second set threshold, the purchase order is set as a risky order. Step 3: If the purchase order is a risky order, the account will enter the risk warning page when making payment, and then make payment after account confirmation; if the purchase order is a normal order, the user will make payment directly; Step 4: Monitor all newly paid accounts. If the account does not use system functions within the set time after payment, the purchase order will be processed according to the risk strategy.

2. A method for merchant order risk control according to claim 1, characterized in that: The step 3 is specifically as follows: if the purchase order is a risky order, then when making payment, the payer's IP is obtained, and the payer's IP is compared with the city to which the IP of the account that created the purchase order belongs. If they are the same, the payment page is jumped to the payment H5 page, which does not include risk warning information, and payment is made after confirmation; If they are different, the user will be redirected to the payment H5 page, which includes risk warning information, and payment will be made after confirmation; If the purchase order is a normal order, payment will be made directly.

3. A method for merchant order risk control according to claim 1, characterized in that: The specific processing of the purchase order according to the risk strategy is as follows: The operation staff determines whether the purchase order is a risky order based on whether the purchase order is a risky order and the information communicated with the customer; If the purchase order is confirmed to be a dangerous order, a refund will be processed directly; the account, the IP address used to create the purchase order, the User Agent used to access the browser, and the device ID will be stored. If there are two or more dangerous purchase orders corresponding to the account, the IP address used to create the purchase order, the User Agent used to access the browser, or the device ID, the account corresponding to the IP address or device ID used to create the purchase order will be restricted from accessing the account; If it is confirmed that the purchase order is not a dangerous order, it will not be processed.

4. A device for merchant order risk control, characterized in that: include: The registration module registers an account based on the mobile phone number. If the mobile phone number is a virtual number, registration is not allowed; If the mobile phone number is not a virtual number, account registration is allowed; The risk judgment module obtains account data when an account creates a purchase order, and determines whether the purchase order is a risky order based on the account data; The account data includes: registration time, IP address of the account creating the purchase order, UserAgent of the access browser, device ID, order type, and data on functions used by the account; According to the order type, if the order is an offline order, it is a normal order; If the order is an online order, determine whether the account's used function data is empty. If it is not empty, it is a normal order. If it is empty, determine the payment amount of the purchase order. If the payment amount is less than the first set threshold, and the number of payments within the account's limited time is less than the second set threshold, it is a normal order. If the payment amount is greater than or equal to the first set threshold or the number of payments within the account's limited time is greater than or equal to the second set threshold, the purchase order is set as a risky order. Payment module: if the purchase order is a risky order, the account will enter the risk warning page when making payment, and then make payment after account confirmation; if the purchase order is a normal order, the user will make payment directly; The monitoring module monitors all new paid accounts. If the account does not use system functions within the set time after payment, the purchase order will be processed according to the risk strategy.

5. The device for merchant order risk control according to claim 4, characterized in that: The payment module specifically includes: if the purchase order is a risky order, then when making payment, the payee's IP is obtained, and the payee's IP is compared with the city of the IP used to create the purchase order. If they are the same, the payment module jumps to the payment H5 page, which does not include risk warning information, and makes payment after confirmation; If they are different, the user will be redirected to the payment H5 page, which includes risk warning information, and payment will be made after confirmation; If the purchase order is a normal order, payment will be made directly.

6. The device for merchant order risk control according to claim 4, characterized in that: The specific processing of the purchase order according to the risk strategy is as follows: The operation staff determines whether the purchase order is a risky order based on whether the purchase order is a risky order and the information communicated with the customer; If the purchase order is confirmed to be a dangerous order, a refund will be processed directly; the account, the IP address used to create the purchase order, the User Agent used to access the browser, and the device ID will be stored. If there are two or more dangerous purchase orders corresponding to the account, the IP address used to create the purchase order, the User Agent used to access the browser, or the device ID, the account corresponding to the IP address or device ID used to create the purchase order will be restricted from accessing the account; If it is confirmed that the purchase order is not a dangerous order, it will not be processed.

Images