WO2020057305A1

WO2020057305A1 - Method and device for identifying risky merchant

Info

Publication number: WO2020057305A1
Application number: PCT/CN2019/100950
Authority: WO
Inventors: 陈帅
Original assignee: 阿里巴巴集团控股有限公司
Priority date: 2018-09-20
Filing date: 2019-08-16
Publication date: 2020-03-26
Also published as: TW202013282A; CN109272336A

Abstract

The present application provides a method for identifying a risky merchant. After a code-scanning payment operation initiated by a user is received, it is determined whether a code scanning interface selected by the user is an in-person scanning interface. If the code scanning interface selected by the user is not an in-person scanning interface, a current transaction is marked as a risky transaction after payment succeeds. A transaction result is uploaded to a server, such that the server calculates the ratio of the number of risky transactions completed by a merchant under test within a preset time period to the total number of transactions completed by the merchant. It is then determined, according to whether the ratio is greater than a first threshold, whether the merchant is a risky merchant. In the present application, a code scanning path selected by a user on a client is identified, so as to recognize whether the user has performed scanning in person, thereby resolving the issues of monitoring difficulties and recognition delays in the prior art caused by the channels and timing of cash flow.

Description

Method and device for discovering risk merchants

Technical field

This specification relates to the field of Internet technologies, and in particular, to a method and device for discovering risky merchants.

Background technique

With the popularity of electronic payment, more and more offline merchants will provide users with electronic payment channels. Users can scan payment codes provided by merchants through payment software such as Alipay for offline payment.

Among them, in order to attract users to make offline payments, electronic payment software sometimes invests event funds to carry out preferential activities. For participating merchants, users can get discounts on the amount of money when paying. Faced with a large amount of activity funds, there are illegal merchants colluding with black users to make false transactions, and then arbitrage from them. For example: In the event that the merchant is over 20 minus 5 blocks, an illegal merchant summons a group of users through the network, and then sends the payment code to the user remotely. After the user receives the payment code through the network, he pays 20 yuan by scanning the code to get 5 The actual deduction is 15 yuan. After receiving 20 yuan, the merchant will return the user's principal 15 yuan and divide the marketing funds 5 yuan with the user.

In the prior art, cheating merchants are usually identified through a funding link: Since in the cheating arbitrage collusion between merchants and users, merchants often return funds to users after obtaining funds, they can be identified by tracking the flow of funds. The disadvantage of this method is that the channel of funds between the merchant and the user may be different and difficult to monitor. In addition, some merchants choose to return in weekly or monthly invoicing instead of returning after each transaction, making the identification have a large lag.

Summary of the Invention

In view of the above technical problems, the embodiments of the present specification provide a method and a device for discovering risky merchants. The technical solution is as follows:

According to a first aspect of the embodiments of the present specification, a risk merchant discovery method is provided and applied to a client. The method includes:

After receiving the code scanning payment operation initiated by the user, determine whether the code scanning interface selected by the user is a face-to-face scanning interface, wherein different code-scanning interfaces are used to identify pictures from different sources, and the face-to-face scanning interface is used to make The client device recognizes nearby pictures through the image acquisition module;

If the code scanning interface selected by the user is not a face-to-face scanning interface, after the payment is successful, the transaction is marked as a risky transaction;

Upload the transaction results to the server, so that the server calculates the ratio of the number of risky transactions completed to the total number of transactions completed by the merchant under test within a preset period of time, and determines whether the merchant under test is risky based on whether the ratio is greater than a first threshold Merchants.

According to a second aspect of the embodiments of the present specification, a risk merchant discovery method is provided and applied to a server. The method includes:

Receive the transaction result information uploaded by the client;

Calculating, according to the transaction result information, whether the ratio of the number of risky transactions completed to the total number of transactions completed by the merchant to be tested within a preset time period is greater than a first threshold;

According to the calculation result, it is determined whether the business to be tested is a risk business.

According to a third aspect of the embodiments of the present specification, a risk merchant discovery method is provided, and the method includes:

After receiving the code scanning payment operation initiated by the user, the client determines whether the code scanning interface selected by the user is a face-to-face scanning interface, wherein different code-scanning interfaces are used to identify pictures from different sources, and the face-to-face scanning interface is used for For the client device to identify nearby pictures through the image acquisition module;

If the code scanning interface selected by the user is not a face-to-face scanning interface, after the payment is successful, the client marks the transaction as a risk transaction and uploads the transaction result to the server;

The server calculates, based on the transaction result information, whether the ratio of the number of risky transactions completed to the total number of completed transactions within a preset period of time by the merchant to be tested is greater than a first threshold;

The server determines whether the business to be tested is a risk business according to the calculation result.

According to a fourth aspect of the embodiments of the present specification, a risk merchant discovery device is provided and applied to a client. The device includes:

Scanning code detection module: It is used to determine whether the scanning interface selected by the user is a face-to-face scanning interface after receiving a scanning payment operation initiated by a user. Among them, different scanning interfaces are used to identify pictures from different sources. The face-to-face scanning interface is used to enable the client device to identify nearby pictures through the image acquisition module;

Risk marking module: used to mark the transaction as a risk transaction after the payment is successful when the code scanning interface selected by the user is not a face-to-face scanning interface;

Result uploading module: used to upload transaction results to the server, so that the server calculates the ratio of the number of risky transactions completed to the total number of transactions completed by the merchant under test within a preset time period, and determines the ratio based on whether the ratio is greater than a first threshold Whether the business to be tested is a risk business.

According to a fifth aspect of the embodiments of the present specification, a risk merchant discovery device is provided and applied to a server. The device includes:

Result receiving module: used to receive the transaction result information uploaded by the client;

A risk statistics module, configured to calculate, based on the transaction result information, whether the ratio of the number of risk transactions completed to the total number of transactions completed by the merchant to be tested within a preset time period is greater than a first threshold;

Risk determination module: used to determine whether the business to be tested is a risk business according to the calculation result.

According to a sixth aspect of the embodiments of the present specification, there is provided a computer device including a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein when the processor executes the program, a computer program is implemented. A risky merchant discovery method applied to a client, the method includes:

According to a seventh aspect of the embodiments of the present specification, there is provided a computer device including a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor implements a program when the program is executed. A risk merchant discovery method applied to a server, the method includes:

Receive the transaction result information uploaded by the client;

The technical solution provided in the embodiment of the present specification provides a risky merchant discovery method. After a client receives a code scanning payment operation initiated by a user, if the code scanning interface selected by the user is not a face-to-face scanning interface, the payment is successful. Then, mark this transaction as a risk transaction; upload the transaction results to the server, so that the server calculates the ratio of the number of risky transactions completed to the total number of transactions completed by the merchant under test within a preset time period, according to whether the ratio is greater than The preset threshold determines whether the merchant to be tested is a risk merchant.

The method provided in this specification identifies whether the user is scanning in person by distinguishing the scanning path selected by the user on the client, thereby avoiding the difficulty and delay in identification caused by the channel and time of the flow of funds in the prior art.

It should be understood that the above general description and the following detailed description are merely exemplary and explanatory, and should not limit the embodiments of the present specification.

In addition, any one of the embodiments in this specification does not need to achieve all the effects described above.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to more clearly explain the embodiments of the present specification or the technical solutions in the prior art, the drawings used in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings in the following description are merely These are some of the embodiments described in the embodiments of this specification. For those of ordinary skill in the art, other drawings can be obtained based on these drawings.

FIG. 1 is a flowchart of a risk merchant discovery method according to an exemplary embodiment of the present specification; FIG.

FIG. 2-3 is a schematic diagram of a non-face-to-face interface shown in an exemplary embodiment of the present specification;

FIG. 4 is another flowchart of a risk merchant discovery method according to an exemplary embodiment of the present specification; FIG.

5 is a schematic diagram of a risk merchant discovery method shown in an exemplary embodiment of the present specification;

FIG. 6 is a flowchart of a risk merchant discovery method executed on a client side according to an exemplary embodiment of the present specification; FIG.

FIG. 7 is a flowchart of a risk merchant discovery method executed on a server according to an exemplary embodiment of the present specification; FIG.

FIG. 8 is a schematic diagram of a risk merchant discovery device on a client side according to an exemplary embodiment of the present specification; FIG.

FIG. 9 is a schematic diagram of a risk merchant discovery device on a server, according to an exemplary embodiment of the present specification;

Fig. 10 is a schematic structural diagram of a computer device according to an exemplary embodiment of the present specification.

detailed description

Exemplary embodiments will be described in detail herein, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with this specification. Rather, they are merely examples of devices and methods consistent with certain aspects of the specification, as detailed in the appended claims.

The terminology used in this specification is for the purpose of describing particular embodiments only and is 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 indicates otherwise. It should also be understood that the term "and / or" as used herein refers to and includes any or 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, the 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, without departing from the scope of this specification, 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. Depending on the context, the word "if" as used herein can be interpreted as "at" or "when" or "in response to determination".

Among them, in order to attract users to make offline payments, electronic payment software sometimes invests event funds to carry out preferential activities. For participating merchants, users can get discounts on the amount of money when paying. Faced with a large amount of activity funds, there are illegal merchants colluding with black users to make false transactions, and then arbitrage from them. For example: In the event that the merchant is over 20 minus 5 blocks, an illegal merchant summons a group of users through the network, and then sends the payment code to the user. The user pays 20 yuan by scanning the code to get a 5 yuan deduction, and the actual expenditure is 15 yuan. After getting 20 yuan, the user's principal of 15 yuan will be returned and 5 yuan of marketing funds will be divided with the user.

In view of the above problems, an embodiment of the present specification provides a risk merchant discovery method and a risk merchant discovery device for performing the method. The risk merchant discovery involved in this embodiment is described in detail below. See FIG. The method can include the following steps:

S101. The client receives a scan code payment operation initiated by a user.

S102. Determine whether the code scanning interface selected by the user is a face-to-face scanning interface. If it is a face-to-face scanning interface, perform step S103. If it is not a face-to-face scanning interface, do not operate.

Among them, different code scanning interfaces are used to identify pictures from different sources, and the face-to-face scanning interface is used to enable a client device to identify nearby pictures through an image acquisition module;

In the normal offline code scanning payment operation, the user usually scans the payment code provided by the merchant directly through the image acquisition module (camera, etc.) of the mobile device, and then completes the payment operation.

When risky merchants want to illegally collect activity funds, they usually do not use offline code scanning to pay, and users do not need to appear in merchant stores. Instead, the payment code is sent or displayed via the network to users who assist in drawing funds for the event. For example, the merchant can send the payment code to other users through a single person or group, or the merchant displays the payment code in a public forum (Weibo, Post Bar, etc.), and the user completes the transaction through the screenshot and the merchant's request to return paragraph.

It can be understood that after the user obtains the payment code remotely, the direct recognition of the payment code is usually not performed, and the general electronic payment software usually provides some non-face-scanned payment code identification methods.

Take the electronic payment software Alipay wallet as an example, referring to Figure 2 and Figure 3, there are currently three payment code identification methods in the Alipay wallet APP:

1) Open the Alipay wallet-> enter "Scan"-> point the mobile phone camera at the payment code to scan the code;

2) Open Alipay Wallet-> Enter "Scan"-> Click "Album" button-> Select the payment code picture from the album to identify the payment code;

3) Click and hold the payment code picture (the merchant sends the payment code to the user through the Alipay social channel, or displays it to the user at a forum, etc.)-> click "ID code in the picture" to identify the payment code.

Taking the above identification method as an example, the user usually chooses the second or third method to identify the payment code when assisting in collecting funds for the activity, that is, the user's operation interface is the “photo album” in FIG. 2 and the “photo album” in FIG. 3 "Identify the QR code in the picture". In addition, the non-face-to-face scanning interface is not limited to the examples. As long as the user does not use the client device to identify nearby pictures through the image acquisition module, it can be determined as a non-face-to-face scanning.

S103, if the code scanning interface selected by the user is not a face-to-face scanning interface, after the payment is successful, the client marks the transaction as a risk transaction and uploads the transaction result to the server;

Taking the three payment code identification methods of the Alipay wallet above as examples, if the code scanning interface selected by the user is "album" or "two-dimensional code in the identification picture", after the corresponding transaction is successful, the transaction is marked as Risky trading.

Upload the transaction information to the server, and the transaction information may include a merchant who conducts a transaction with the user. Suspect marks on the transaction, the time of the transaction, etc. At this time, it is uncertain whether the transaction was used to illegally apply activity funds. It must be further determined whether the merchant has a large number of transactions similar to the above, with suspected illegal application of activity funds.

S104. The server calculates, based on the transaction result information, whether the ratio of the number of risky transactions completed to the total number of transactions completed by the merchant to be tested within a preset time period is greater than a first threshold;

After the server receives the transaction result information from each client, the server accumulates the transaction result information under the corresponding merchant information, and statistics the transaction information of different merchants to determine the number of risky transactions completed by the merchant within the preset time period and the total Whether the ratio of the number of transactions is greater than a first threshold.

S105: The server determines whether the merchant to be tested is a risk merchant according to the calculation result.

It can be understood that if the ratio of the number of risky transactions to the total number of transactions is greater than the first threshold value, it means that the merchant has a high probability of completing a large number of non-face-to-face transactions with the user, and it can be judged that the merchant is likely to carry out activity funds.

An embodiment of the present specification also provides a more specific risk merchant discovery method. As shown in FIG. 4, the method may include the following steps:

S401, the client monitors different code scanning interfaces provided to the user for code scanning payment;

S402. After the user operates one of the different code scanning interfaces, the client determines whether the code scanning interface operated by the user is a face-to-face scanning interface. If the face-to-face scanning interface is performed, step S403 is performed. If it is not the face-to-face scanning interface, no operation is performed. ;

S403: If the interface operated by the user is a non-face-to-face scanning interface, record the interface operation time of the user;

S404. Record the time when the code scanning payment event occurs when the first code scanning payment event occurs after the interface operation ends;

S405. Calculate a time difference between the interface operation time and the time when the scan code payment event occurs;

S406. Determine whether the time difference is greater than a preset time. If the time difference is greater than the preset time, step S407 is performed. If the time difference is not greater than the preset time, no operation is performed.

Specifically, the scan code button suspected of cheating in the client can be uniquely identified by an ID. Taking FIG. 2 and FIG. 3 as examples, the keys suspected of cheating are as shown in FIG. 2 and FIG. 3, and the identification positions "album" and "identification QR code" in the figure.

After the user clicks on the identification case, the user operation is recorded, and the record contains the unique identification of the button and the time CTi of the click. When the code scanning payment event is initiated, the time PT of the code scanning event is recorded. And according to the time difference ti = PT-CTi between the click and the payment event, if the time difference is less than the preset time, it can be judged that the click event is related to the transaction time. Referring to FIG. 5, assuming that the transaction result is recorded as Y, let Y = 1 represent the transaction as a risk transaction, and let Y = 0 represent the transaction as a normal transaction.

S407: After the payment is successful, mark the transaction as a risk transaction and upload the transaction result to the server;

S408. The server calculates, based on the transaction result information, whether the ratio of the number of risky transactions completed to the total number of completed transactions within a preset period of time by the merchant to be tested is greater than a first threshold;

S409. If the ratio is greater than the first threshold, continue to determine whether the total number of transactions completed by the merchant under test within the preset time period is greater than a second threshold. If the total number of transactions is greater than the second threshold, step S410 is performed. If the total number of transactions is not greater than the second threshold. Then do not operate;

Understandably, when the time is sufficiently concentrated (within a preset time period) and the sample is sufficient (the total number of transactions is greater than the second threshold), if the number of risky transactions in the total number of transactions is high enough (the number of risky transactions completed) Whether the ratio of the total number of transactions completed is greater than the first threshold), then the merchant is likely to carry out the collection of activity funds.

S410: Determine that the business to be tested is a risk business.

In order to explain the solution of the embodiment of this specification more clearly, the following describes the method of execution from a one-sided perspective, respectively:

Referring to FIG. 6, this is a risk merchant discovery method performed on a client according to an embodiment of the present specification. The method includes:

S601. After receiving a code scanning payment operation initiated by a user, determine whether the code scanning interface selected by the user is a face-to-face scanning interface, wherein different code-scanning interfaces are used to identify pictures from different sources, and the face-to-face scanning interface is used for For the client device to identify nearby pictures through the image acquisition module;

S602: If the code scanning interface selected by the user is not a face-to-face scanning interface, after the payment is successful, mark the transaction as a risk transaction;

S603. Upload the transaction result to the server, so that the server calculates a ratio between the number of risky transactions completed and the number of completed transactions within a preset time period of the merchant under test, and determines whether the merchant under test is based on whether the ratio is greater than a first threshold. For risk merchants.

Referring to FIG. 7, this is a risk merchant discovery method performed on a server according to an embodiment of the present specification. The method includes:

S701. Receive transaction result information uploaded by a client.

S702. Calculate whether the ratio of the number of risky transactions completed to the total number of completed transactions within a preset time period is greater than a first threshold according to the transaction result information.

S703: Determine whether the merchant under test is a risk merchant according to the calculation result.

Corresponding to the above method embodiment, the embodiment of the present specification also provides a risk merchant discovery device applied to the client. As shown in FIG. 8, the device may include a code scanning detection module 810, a risk marking module 820, and a result uploading module. 830.

The code scanning detection module 810 is configured to determine whether the scanning interface selected by the user is a face-to-face scanning interface after receiving a scanning payment operation initiated by a user, wherein different scanning interfaces are used to identify pictures from different sources, The face-to-face scanning interface is used to enable a client device to identify nearby pictures through an image acquisition module;

Risk marking module 820: used for marking the transaction as a risk transaction after the payment is successful when the code scanning interface selected by the user is not the face scanning interface;

Result uploading module 830: It is used to upload the transaction results to the server, so that the server calculates the ratio of the number of risky transactions completed to the total number of transactions completed by the merchant to be tested within a preset period of time, and determines whether the ratio is greater than the first threshold. Describe whether the business to be tested is a risk business.

Corresponding to the above method embodiment, the embodiment of the present specification also provides a risk merchant discovery device applied to a server. As shown in FIG. 9, the device may include a result receiving module 910, a risk statistics module 920, and a risk determination module 930. .

A result receiving module 910, configured to receive transaction result information uploaded by a user terminal;

A risk statistics module 920, configured to calculate, based on the transaction result information, whether the ratio of the number of risky transactions completed to the total number of completed transactions within a preset period of time by the merchant to be tested is greater than a first threshold;

A risk determination module 930 is configured to determine whether the merchant to be tested is a risk merchant according to a calculation result.

An embodiment of the present specification further provides a computer device including at least a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor implements the foregoing risk merchant discovery method when the processor executes the program, The method is applied to a client, and the method includes at least:

An embodiment of the present specification further provides a computer device including at least a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor implements the foregoing risk merchant discovery method when the processor executes the program, The method is applied to a server, and the method includes at least:

Receive the transaction result information uploaded by the client;

FIG. 10 shows a more specific schematic diagram of a hardware structure of a computing device provided by an embodiment of the present specification. The device may include a processor 1010, a memory 1020, an input / output interface 1030, a communication interface 1040, and a bus 1050. The processor 1010, the memory 1020, the input / output interface 1030, and the communication interface 1040 implement a communication connection within the device through a bus 1050.

The processor 1010 may be implemented by a general-purpose CPU (Central Processing Unit), a microprocessor, an Application Specific Integrated Circuit (ASIC), or one or more integrated circuits, etc., for performing related operations. Program to implement the technical solutions provided by the embodiments of this specification.

The memory 1020 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage devices, dynamic storage devices, and the like. The memory 1020 may store an operating system and other application programs. When the technical solutions provided in the embodiments of the present specification are implemented by software or firmware, related program codes are stored in the memory 1020 and are called and executed by the processor 1010.

The input / output interface 1030 is used to connect an input / output module to implement information input and output. The input / output / module can be configured in the device as a component (not shown in the figure), or it can be externally connected to the device to provide corresponding functions. The input device may include a keyboard, a mouse, a touch screen, a microphone, various sensors, etc., and the output device may include a display, a speaker, a vibrator, and an indicator light.

The communication interface 1040 is used to connect a communication module (not shown in the figure) to implement communication interaction between the device and other devices. The communication module can implement communication through a wired method (such as USB, network cable, etc.), and can also implement communication through a wireless method (such as mobile network, WIFI, Bluetooth, etc.).

The bus 1050 includes a path for transmitting information between various components of the device (for example, the processor 1010, the memory 1020, the input / output interface 1030, and the communication interface 1040).

It should be noted that although the above-mentioned device only shows the processor 1010, the memory 1020, the input / output interface 1030, the communication interface 1040, and the bus 1050, in the specific implementation process, the device may also include necessary for achieving normal operation Other components. In addition, a person skilled in the art can understand that the foregoing device may also include only components necessary to implement the solutions of the embodiments of the present specification, and does not necessarily include all the components shown in the drawings.

An embodiment of the present specification also provides a computer-readable storage medium on which a computer program is stored. When the program is executed by a processor, the foregoing method for detecting a risky merchant is implemented. The method is applied to a client. The method at least includes:

An embodiment of the present specification also provides a computer-readable storage medium on which a computer program is stored. When the program is executed by a processor, the foregoing method for discovering a risky merchant is implemented. The method is applied to a server. The method includes at least:

Receive the transaction result information uploaded by the client;

Computer-readable media includes both permanent and non-persistent, removable and non-removable media. Information can be stored by any method or technology. Information may be computer-readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), and read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, read-only disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, Magnetic tape cartridges, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media may be used to store information that can be accessed by computing devices. As defined herein, computer-readable media does not include temporary computer-readable media, such as modulated data signals and carrier waves.

This note also provides a risk merchant discovery system, which includes:

Server, client

The client is configured to determine whether the code scanning interface selected by the user is a face-to-face scanning interface after receiving a code scanning payment operation initiated by a user, wherein different code scanning interfaces are used to identify pictures from different sources. The face-to-face scanning interface is used to enable the client device to identify nearby pictures through the image acquisition module;

The client is configured to mark the transaction as a risk transaction after the payment is successful when the code scanning interface selected by the user is not an in-person scanning interface;

The client is used to upload the transaction result to the server;

The server is configured to receive transaction result information uploaded by a client;

The server is configured to calculate, based on the transaction result information, whether the ratio of the number of completed risky transactions to the total number of completed transactions within a preset time period of the merchant to be tested is greater than a first threshold;

The server is configured to determine whether the merchant to be tested is a risk merchant according to a calculation result.

As for the device embodiment, since it basically corresponds to the method embodiment, the relevant part may refer to the description of the method embodiment. The device embodiments described above are only schematic, 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, may be located One place, or it can be distributed across 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 without creative efforts.

It can be known from the description of the foregoing embodiments that those skilled in the art can clearly understand that the embodiments of the present specification can be implemented by means of software plus a necessary universal hardware platform. Based on such an understanding, the technical solutions of the embodiments of the present specification may be embodied in the form of software products that are essentially or contribute to the existing technology. The computer software product may be stored in a storage medium, such as ROM / RAM, Magnetic disks, optical disks, and the like include a number of instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to perform the methods described in various embodiments or portions of the embodiments of this specification.

The system, device, module, or unit described in the foregoing embodiments may be specifically implemented by a computer chip or entity, or a product with a certain function. A typical implementation device is a computer, and the specific form of the computer may be a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email sending and receiving device, and a game control Desk, tablet computer, wearable device, or a combination of any of these devices.

Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on the differences from other embodiments. In particular, as for the device embodiment, since it is basically similar to the method embodiment, it is described relatively simply. For the relevant part, refer to the description of the method embodiment. The device embodiments described above are only schematic, and the modules described as separate components may or may not be physically separated. When implementing the solutions of the embodiments of this specification, the functions of the modules may be the same. Or multiple software and / or hardware. Some or all of the modules may also be selected according to actual needs to achieve the objective of the solution of this embodiment. Those of ordinary skill in the art can understand and implement without creative efforts.

The above are only specific implementations of the embodiments of the present specification. It should be noted that, for those of ordinary skill in the art, without departing from the principles of the embodiments of the present specification, several improvements and retouches can be made. These Improvement and retouching should also be regarded as the protection scope of the embodiments of the present specification.

Claims

A risk merchant discovery method, the method includes:

After receiving the code scanning payment operation initiated by the user, the client determines whether the code scanning interface selected by the user is a face-to-face scanning interface, wherein different code-scanning interfaces are used to identify pictures from different sources, and the face-to-face scanning interface is used for For the client device to identify nearby pictures through the image acquisition module;

If the code scanning interface selected by the user is not a face-to-face scanning interface, after the payment is successful, the client marks the transaction as a risk transaction and uploads the transaction result to the server;

The server calculates, based on the transaction result information, whether the ratio of the number of risky transactions completed to the total number of completed transactions within a preset period of time by the merchant to be tested is greater than a first threshold;

The server determines whether the business to be tested is a risk business according to the calculation result.
A risk merchant discovery method applied to a client, the method includes:

After receiving the code scanning payment operation initiated by the user, determine whether the code scanning interface selected by the user is a face-to-face scanning interface, wherein different code-scanning interfaces are used to identify pictures from different sources, and the face-to-face scanning interface is used to make The client device recognizes nearby pictures through the image acquisition module;

If the code scanning interface selected by the user is not a face-to-face scanning interface, after the payment is successful, the transaction is marked as a risky transaction;

Upload the transaction results to the server, so that the server calculates the ratio of the number of risky transactions completed to the total number of transactions completed by the merchant under test within a preset period of time, and determines whether the merchant under test is risky based on whether the ratio is greater than a first threshold Merchants.
The method according to claim 2, wherein, after receiving the code scanning payment operation initiated by the user, determining whether the code scanning interface selected by the user is a face-to-face scanning interface, comprising:

Monitor different code scanning interfaces provided by the client to users for code scanning payment;

After the user operates one of the different code scanning interfaces, it is determined whether the code scanning interface operated by the user is a face-to-face scanning interface.
The method according to claim 3, wherein if the code scanning mode selected by the user is not a face-to-face scan, marking the transaction as a risk transaction after the payment is successful comprises:

If the interface operated by the user is a non-face-to-face scanning interface, determine whether a code scan payment event occurs in the client within a preset time after the operation is completed;

If a code scan payment event occurs, the transaction is marked as a risk transaction after the payment is successful.
The method according to claim 3, wherein if the code scanning mode selected by the user is not a face-to-face scan, marking the transaction as a risk transaction after the payment is successful comprises:

If the interface operated by the user is a non-face-to-face scanning interface, record the interface operation time of the user;

After the interface operation ends, when the first code scanning payment event occurs, the time when the code scanning payment event occurs is recorded;

Calculate the time difference between the interface operation time and the time when the code scan payment event occurs. If the time difference is not greater than a preset time, the transaction is marked as a risk transaction after the payment is successful.
A risk merchant discovery method applied to a server, the method includes:

Receive the transaction result information uploaded by the client;

Calculating, according to the transaction result information, whether the ratio of the number of risky transactions completed to the total number of transactions completed by the merchant to be tested within a preset time period is greater than a first threshold;

According to the calculation result, it is determined whether the business to be tested is a risk business.
The method according to claim 6, wherein determining whether the merchant under test is a risk merchant based on a calculation result comprises:

Determining whether the ratio is greater than a first threshold;

If the ratio is greater than the first threshold, continue to determine whether the total number of transactions completed by the merchant to be tested within the preset time period is greater than the second threshold;

If the total number of transactions is greater than the second threshold, it is determined that the merchant to be tested is a risk merchant.
A risk merchant discovery device applied to a client, the device includes:

Scanning code detection module: It is used to determine whether the scanning interface selected by the user is a face-to-face scanning interface after receiving a scanning payment operation initiated by a user. Among them, different scanning interfaces are used to identify pictures from different sources. The face-to-face scanning interface is used to enable the client device to identify nearby pictures through the image acquisition module;

Risk marking module: used to mark the transaction as a risk transaction after the payment is successful when the code scanning interface selected by the user is not a face-to-face scanning interface;

Result uploading module: used to upload transaction results to the server, so that the server calculates the ratio of the number of risky transactions completed to the total number of transactions completed by the merchant under test within a preset time period, and determines the ratio based on whether the ratio is greater than a first threshold Whether the business to be tested is a risk business.
The apparatus according to claim 8, wherein the determining whether the code scanning interface selected by the user is a face-to-face scanning interface comprises:

Monitor different code scanning interfaces provided by the client to users for code scanning payment;

After the user operates one of the different code scanning interfaces, it is determined whether the code scanning interface operated by the user is a face-to-face scanning interface.
The device according to claim 9, wherein if the code scanning mode selected by the user is not a face-to-face scanning, marking the transaction as a risk transaction after the payment is successful comprises:

If the interface operated by the user is a non-face-to-face scanning interface, determine whether a code scan payment event occurs in the client within a preset time after the operation is completed;

If a code scan payment event occurs, the transaction is marked as a risk transaction after the payment is successful.
The device according to claim 9, wherein if the code scanning mode selected by the user is not a face-to-face scanning, marking the transaction as a risk transaction after the payment is successful comprises:

If the interface operated by the user is a non-face-to-face scanning interface, record the interface operation time of the user;

After the interface operation ends, when the first code scanning payment event occurs, the time when the code scanning payment event occurs is recorded;

Calculate the time difference between the interface operation time and the time when the code scan payment event occurs. If the time difference is not greater than a preset time, the transaction is marked as a risk transaction after the payment is successful.
A risk merchant discovery device applied to a server, the device includes:

Result receiving module: used to receive the transaction result information uploaded by the client;

A risk statistics module, configured to calculate, based on the transaction result information, whether the ratio of the number of risk transactions completed to the total number of transactions completed by the merchant to be tested within a preset time period is greater than a first threshold;

Risk determination module: used to determine whether the business to be tested is a risk business according to the calculation result.
The apparatus according to claim 12, wherein the determining whether the merchant under test is a risk merchant based on a judgment result, comprising:

Determining whether the ratio is greater than a first threshold;

If the ratio is greater than the first threshold, continue to determine whether the total number of transactions completed by the merchant to be tested within the preset time period is greater than the second threshold;

If the total number of transactions is greater than the second threshold, it is determined that the merchant to be tested is a risk merchant.
A risk merchant discovery system, the system includes:

Server, client

The client is configured to determine whether the code scanning interface selected by the user is a face-to-face scanning interface after receiving a code scanning payment operation initiated by a user, wherein different code scanning interfaces are used to identify pictures from different sources. The face-to-face scanning interface is used to enable the client device to identify nearby pictures through the image acquisition module;

The client is configured to mark the transaction as a risk transaction after the payment is successful when the code scanning interface selected by the user is not an in-person scanning interface;

The client is used to upload the transaction result to the server;

The server is configured to receive transaction result information uploaded by a client;

The server is configured to calculate, based on the transaction result information, whether the ratio of the number of completed risky transactions to the total number of completed transactions within a preset time period of the merchant to be tested is greater than a first threshold;

The server is configured to determine whether the merchant to be tested is a risk merchant according to a calculation result.
A computer device includes a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein when the processor executes the program, the method according to claim 2 is implemented.
A computer device includes a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein when the processor executes the program, the method according to claim 6 is implemented.