WO2021103701A1

WO2021103701A1 - Transaction risk identification method and apparatus

Info

Publication number: WO2021103701A1
Application number: PCT/CN2020/111779
Authority: WO
Inventors: 汪志阳
Original assignee: 支付宝(杭州)信息技术有限公司
Priority date: 2019-11-26
Filing date: 2020-08-27
Publication date: 2021-06-03
Also published as: TWI807185B; TW202121290A; CN111080302A

Abstract

A transaction risk identification method and apparatus. The method comprises: receiving transaction information of a current transaction to be identified, the transaction information comprising user information and a device trust identifier corresponding to the current transaction, and the device trust identifier uniquely corresponding to a device where the current transaction occurs (101); sending the device trust identifier to a device center, and receiving a device query result corresponding to the device trust identifier and returned by the device center (102); and according to the device query result, performing risk identification on the transaction information (103).

Description

Method and device for identifying transaction risk

Technical field

This manual relates to the field of Internet technology, and in particular to a method and device for identifying transaction risks.

Background technique

With the continuous enrichment of Internet services, Internet-based payment methods have developed in depth, and offline payment has gradually become an important payment method. In offline payment, the payer only needs to show the payment code to the payee, and the payee scans the payment code and initiates a deduction request to the server. However, the payee cannot obtain the payer's device information, which causes the server to be unable to conduct risk assessment of the transaction payment from the device information dimension, thereby increasing the payer's payment risk.

Summary of the invention

At least one embodiment of this specification provides a transaction risk identification method, so that the server can accurately identify the transaction risk and reduce the payment risk of the payer.

In a first aspect, a transaction risk identification method is provided, the method includes: receiving transaction information of the current transaction to be recognized, the transaction information including user information corresponding to the transaction and a device trust identifier; the device The trust identifier is used to uniquely correspond to the device where the transaction occurred; send the device trust identifier to the device center, and receive the device query result corresponding to the device trust identifier returned by the device center; according to the device query result , Perform risk identification on the transaction information.

In a second aspect, a payment processing method is provided, which is applied to a client of a payer, and the method includes: receiving a payment code generation request; obtaining a payment code based on user information and a device trust identifier; the device trust identifier is used to uniquely Corresponding to the device where the transaction occurred; the payment code includes the user information and the device trust identifier;

The payment code is displayed, so that the payee executes this payment transaction according to the payment code.

In a third aspect, a payment processing method is provided, the method comprising: receiving a payment request for this transaction, the payment request carrying: a payment code and payment information for this transaction; and obtaining information included in the payment code User information and device trust identifier, the device trust identifier is used to uniquely correspond to the device where this transaction occurs; the transaction information of this transaction is sent to the payment system, and the transaction information carries: the user information, the device The trust mark and the payment information.

In a fourth aspect, a transaction risk identification device is provided. The device includes: a receiving module for receiving transaction information of this transaction to be identified, the transaction information including user information and equipment trust corresponding to this transaction ID; the device trust ID is used to uniquely correspond to the device where the transaction occurs; the processing module is used to send the device trust ID to the device center, and receive the device trust ID returned by the device center corresponding to the device trust ID Equipment query result; a risk identification module for risk identification on the transaction information according to the equipment query result.

In a fifth aspect, a payment processing device is provided, which is applied to a client of a payer. The device includes: a request receiving module, configured to receive a payment code generation request; and an acquiring module, configured to obtain Payment code; the device trust identifier is used to uniquely correspond to the device where this transaction occurs; the payment code includes the user information and the device trust identifier; the display module is used to display the payment code to enable payment The party executes this payment transaction according to the payment code.

In a sixth aspect, a payment processing device is provided. The device includes: a payment request receiving module for receiving a payment request for this transaction, the payment request carrying: a payment code and payment information for this transaction; The second acquiring module is used to acquire the user information and the device trust identifier included in the payment code, and the device trust identifier is used to uniquely correspond to the device where the transaction occurs; the second sending module is used to send this to the payment system Transaction information of the second transaction, where the transaction information carries: the user information, the device trust identifier, and the payment information.

In a seventh aspect, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and capable of running on the processor. When the processor executes the program, the program described in any of the embodiments of this specification is implemented. The transaction risk identification method, or the payment processing method described in any embodiment of this specification.

In an eighth aspect, a computer-readable storage medium is provided, on which a computer program is stored. When the program is executed by a processor, the transaction risk identification method described in any of the embodiments of this specification is implemented, or any one of the embodiments of this specification is implemented. The payment processing method described in the embodiment.

It can be seen from the above technical solutions that an embodiment of this specification realizes that the server can query the device information of the payer device in the current transaction according to the device trust identifier, so as to accurately identify the risk in the device information dimension and reduce the payment risk of the payer.

It should be understood that the above general description and the following detailed description are only exemplary and explanatory, and cannot limit this specification.

Description of the drawings

Fig. 1 is a flow chart showing a method for identifying transaction risks according to an exemplary embodiment.

Fig. 2 is a flow chart showing a payment processing method according to an exemplary embodiment.

Fig. 3 is a flow chart showing another payment processing method according to an exemplary embodiment.

Fig. 4 is a flow chart showing a transaction payment according to an exemplary embodiment.

Fig. 5 is a schematic diagram showing a transaction risk identification device according to an exemplary embodiment.

Fig. 6 is a schematic diagram showing a payment processing device according to an exemplary embodiment.

Fig. 7 is a schematic diagram showing another payment processing device according to an exemplary embodiment.

Fig. 8 is a schematic diagram showing yet another payment processing device according to an exemplary embodiment.

Detailed ways

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

The terms used in this specification are only for the purpose of describing specific embodiments, and are not intended to limit the specification. The singular forms of "a", "said" and "the" used in this specification and appended claims are also intended to include plural forms, unless the context clearly indicates other meanings. 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 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 second information, and similarly, the second information may also be referred to as first information. Depending on the context, the word "if" as used herein can be interpreted as "when" or "when" or "in response to determination".

At least one embodiment of this specification provides a transaction risk identification method: When the server performs risk identification on the current transaction, it queries the corresponding device information from the device center according to the unique device trust identifier of the payer device in the current transaction, and returns according to the device center The results of the equipment query to identify the risk of the current transaction. Since the device trust identifier can uniquely correspond to the device information in the current transaction, the server can accurately obtain the device information of the payer of the current transaction, and identify the risk of the current transaction from the device information dimension, reducing the payment risk of the payer.

In order to make the transaction risk identification solution provided in this specification clearer, the following describes the execution process of the solution provided in this specification in detail with reference to the accompanying drawings and specific embodiments.

Refer to Fig. 1, which is a flowchart of a method for identifying transaction risks according to an embodiment provided in this specification. This method is applied to a risk control system. It is understandable that all systems with risk identification and control functions can be regarded as "risk control systems", and there is no restriction here.

As shown in Figure 1, the process includes step 101 to step 103.

Step 101: Receive transaction information of this transaction to be identified, where the transaction information includes user information and device trust identifier corresponding to this transaction; the device trust identifier is used to uniquely correspond to the device where the transaction occurs.

Before the payment system performs a corresponding payment operation for this transaction, it needs to check the risk of the transaction with the risk control system, and decide whether to perform the payment operation based on the risk feedback of the risk control system. This step is when the payment system sends a "query request" to the risk control system, and the risk control system receives the user information and device trust identifier of the payer in this transaction.

Among them, the device trust identifier can uniquely correspond to the device used by the payer in the current transaction. For example, the device trust identifier can be the international mobile device identity code of the payer's device in the current transaction, and the "code" that can uniquely correspond to a device can be used as the above device trust identifier, which is not limited in this manual. For example, the device trust identifier may also be a unique identifier generated based on an international mobile device identity code, an international mobile subscriber identity code, a client random number, and a server random number-a device trust identifier (Trust ID, TID). TID is the unique identification of the same user and the same device in this transaction. The risk control system can query all the information of the device where the payer’s client is located through TID, thereby identifying risks in this transaction from different dimensions.

Step 102: Send the device trust identifier to the device center, and receive the device query result corresponding to the device trust identifier returned by the device center.

The device center pre-stores the mapping relationship between the device information and the device trust identifier. In this step, the risk control system sends the equipment trust mark to the equipment center for query, and accepts the query result fed back by the equipment center. For example, if the equipment center queries the equipment information corresponding to the same equipment trust identifier as equipment A, it will feed back the equipment query result-equipment A to the risk control system; if the equipment center queries the same equipment trust identifier, the equipment query result-no The existence of the same equipment trust mark is fed back to the risk control system.

Step 103: Perform risk identification on the transaction information according to the device query result.

Based on the historical transaction information of the equipment, the risk control system has carried out multi-dimensional data accumulation and factual judgment. In this step, the risk control system performs risk identification on the transaction information of this transaction based on the results of the device query and combined with the user's historical transaction information in this transaction. For example, the device query result shows that the device information is device A, and the risk control system obtains that the user has been using device A to conduct transactions through historical transaction information, and then the transaction can be identified as risk-free in the device information dimension; if the risk control system passes the history The transaction information query obtains that the user has been using device B for transactions, and the high risk of this transaction can be identified in the device information dimension.

Based on the risk identification of the equipment dimension, the risk control system can also comprehensively identify the risk of this transaction in combination with other dimensions. For example, by judging whether the transaction location is consistent with the historical transaction location, the current transaction risk can be identified; Whether the transaction object of the transaction and the historical transaction object are of the same type, identify the current transaction risk. For example, after the risk control system obtains all the information of the payer's device in this transaction based on the TID value, it performs risk identification from the SIM card dimension, and finds that the SIM card of the payer in this transaction has multiple logins with the SIM card, and it can be identified based on the number of logins. The risk of this transaction: Perform risk identification from the device dimension and find that the device of the payer of this transaction has multiple account logins with the same device, and then identify the risk of this transaction based on the number of logged-in accounts. The aforementioned user historical transaction information may also include: transaction time, transaction object type, transaction corresponding commodity type or transaction amount, etc.

In an example, the performing risk identification on the transaction information according to the device query result includes: if the device query result returned by the device center includes: there is no device information corresponding to the device trust identifier, then Confirm that this transaction is a risky transaction. The equipment center determines through query that there is no identical equipment trust identifier (that is, no corresponding equipment information), and it can identify the high risk of the current transaction in the dimension of equipment information. For example: A has been using device A for payment transactions, criminal B illegally obtained A’s user information and logged in on device B for offline payment (called illegal transactions), and intercepted the device sent to the device center during offline payment The data packet of information (device B) and user information causes the device center to fail to store the mapping relationship between device B and device trust identifier b. When the risk control system identifies this illegal transaction, after sending the device trust mark b to the equipment center, the device center query returns the result that there is no device information corresponding to the device trust mark b, and the risk control system can confirm that the illegal transaction is a risk Transaction, thereby preventing this transaction.

In an example, the performing risk identification on the transaction information according to the device query result includes: if the device query result returned by the device center includes: device information corresponding to the device trust identifier, and confirming all The device information is different from the device where the history of the user information is located, and it is confirmed that the current transaction is a risky transaction. For example: A has been using device A for payment transactions, criminal B illegally obtained A’s user information and logged in on device B for offline payment (known as illegal transactions), and sent device information (device B) during offline payment And user information to the device center, the device center stores the mapping relationship between device B and device trust identifier b. When the risk control system recognizes this illegal transaction, it sends the device trust mark b to the equipment center, and the equipment center queries and returns the device information corresponding to the device trust mark b is equipment B. The risk control system finds equipment B and the equipment in the historical transaction information If the equipment information of A is inconsistent, the illegal transaction is confirmed as a risky transaction, so as to prevent the illegal transaction in time.

In the transaction risk identification method of this embodiment, when the risk control system performs risk identification of this transaction, the transaction information of this transaction obtains the user information of this transaction and the device trust identifier uniquely corresponding to the payer device in this transaction , According to the device trust mark, query the corresponding device information from the device center, so as to identify the risk of this transaction in the device information dimension, thereby reducing the payment risk of the payer. Since the device trust ID can uniquely correspond to the payer's device in the current transaction, it is ensured that the device information queried by the risk control system based on the device trust ID is the device information of the payer's device in the current transaction, so that accurate risk identification is performed in the device information dimension and reduces Payer’s payment risk.

Refer to Fig. 2, which is a flowchart of a payment processing method shown in an embodiment of this specification. This method is applied to the client of the payer.

As shown in FIG. 2, the process of this embodiment includes the following steps 201 to 203.

Step 201: Receive a payment code generation request.

When the user uses the payer's client to make a payment, he will input a command to display the payment code to the payer's client. For example, the user clicks the "Payment Code" button on the payer's client. In this step, the payer client receives the payment code generation request (corresponding to the user inputting a command to display the payment code to the payment client).

In an example, before the receiving the payment code generation request, the method further includes: sending the device information of the device where the client is located and the device trust identifier to the device center, so that the device center stores The mapping relationship between the device information and the device trust identifier. The payer client directly or indirectly sends the device information and the device trust identifier to the device center, for example, through a number of intermediate devices and finally sent to the device center. As the back-end microservice application in the payment system, the device center has related management functions such as viewing, deleting, and storing device information, as well as features such as high stability and maintainability. The storage and management of the mapping relationship between the device information and the device trust mark in the device center is more reliable and manageable than the temporary storage of device information in the risk control system.

In an example, the sending the device information of the device where the payment client is located and the device trust identifier to the device center includes: when the client login is detected, the device information and the device trust Identification, sent to the equipment center. When the payer client detects that the user logs in to the client, it will automatically send the device information and device trust identifier to the device center. The above-mentioned "user login client" includes the automatic login of the client based on the saved account information after the user opens the client.

In an example, before receiving the payment code generation request, the method further includes: storing a device trust identifier, the device trust identifier being an identifier generated by the server according to device association parameters, and the device association parameters include: International Mobile Device identification code, international mobile user identification code, random number generated by the client and random number generated by the server. When the user enters user information (such as account number and password) when logging in to the payer’s client for the first time, the server will use the international mobile device identification code of the device where the current payer’s client is located, the international mobile user identification code in the device where the payer is located, and the current payer The random number generated by the client and the random number generated by the server are four device-related parameters to generate the device trust ID (Trust ID, abbreviated as TID), and the TID is used to uniquely correspond to the device where the payer client is located, and the payer client stores the TID .

The above "user enters user information (such as account number and password) when logging in to the payer's client for the first time", the server will generate a device trust identifier and store it in the payer's client; and the record is recorded on the payer's client for the first login After the login information, when the client automatically logs in when the user uses it again, the server will not regenerate a new device trust identifier. Regarding the above understanding of "the user enters user information (such as account number and password) when logging in to the payer's client for the first time", an example is as follows: in device A, the payer's client a logs in to user A's account, and log out in a And re-login to A’s account, the server will regenerate the device trust identifier; log out of A’s account in a and log in to B’s account, then the server will regenerate the device trust identifier; when logging in to user A’s account in a, change the mobile SIM card, the device trust mark is regenerated.

Step 202: Obtain a payment code according to the user information and the device trust identifier; the device trust identifier is used to uniquely correspond to the device where the transaction occurs; the payment code includes the user information and the device trust identifier.

In this step, the payer client goes to the decoding center to obtain the payment code according to the user information and the device trust identifier.

In an example, the obtaining the payment code according to the user information and the device trust identifier includes: sending a payment code obtaining request to a decoding center, and the payment code obtaining request includes: the user information and the device trust identifier; receiving the Decoding the payment code returned by the center, where the payment code is generated by the decoding center according to the user information and the device trust identifier. The payer client sends a payment code request containing the user information and the device trust identifier to the decoding center, and the decoding center generates the payment code based on the user information and the device trust identifier and returns it to the payer client.

Step 203: Display the payment code so that the payee executes the current payment transaction according to the payment code.

The payer client displays the payment code to the payee client so that the payee can obtain the payment code and execute the payment transaction.

In the payment processing method of this embodiment, the payer client obtains and displays the payment code according to the user information and the device trust identifier uniquely corresponding to the device where the transaction occurs, so that the payee client obtains the user information and device through the payment code Trust the ID, so that the payee client can initiate a payment request for this transaction based on the user information and the device trust ID.

Refer to Fig. 3, which is a flowchart of a payment processing method shown in an embodiment of this specification. This method is applied to the receiver's server.

As shown in FIG. 3, the process of this embodiment includes the following steps 301 to 303.

Step 301: Receive a payment request for this transaction, where the payment request carries: a payment code and payment information for this transaction.

After obtaining the payment code, the payee client sends a payment request for this transaction to the payee server. The payment request carries the payment code and payment information. The payment information may include: payee account, transaction amount, product information, transaction time, etc.

Step 302: Obtain the user information and the device trust identifier included in the payment code, where the device trust identifier is used to uniquely correspond to the device where the transaction occurs.

The payee server sends the payment code to the decoding center for analysis, and obtains the user information and the device trust identifier from the analysis result. Among them, the device trust identifier uniquely corresponds to the device where the payer client is located in this transaction.

In an example, the obtaining the user information and the device trust identifier included in the payment code includes: sending an analysis request to a decoding center, where the analysis request includes: the payment code; and receiving the payment code returned by the decoding center The user information and device trust identifier obtained by analyzing the payment code.

Step 303: Send transaction information of this transaction to the payment system, where the transaction information carries: the user information, the device trust identifier, and the payment information.

The payee server sends the transaction information of this transaction to the payment system, so that the payment system performs the payment operation for this transaction.

In the payment processing method of this embodiment, the payee server obtains the user information of the transaction in the payment code and the device trust identifier uniquely corresponding to the device where the transaction occurs, and combines the user information and device trust identifier of the transaction And the payment information is sent to the payment system, so that the payment system will perform the payment operation for this transaction according to the risk identification result of the risk control system.

Figure 4 illustrates a complete transaction payment process, describing the process of applying the transaction risk identification method shown in the embodiment of this specification to carry out risk control on the payment of this transaction. As shown in Figure 4, the process can include steps 401 to 416.

In step 401, when the payer client logs in to the current account for the first time (when the user enters the account password to log in), the device trust identifier generated by the server is stored. The device trust identifier is a unique identifier generated by the server according to the four influencing factors of the international mobile device identification code, the international mobile subscriber identification code, the client random number and the server random number of the device where the payer’s client is located, so the device trusts The identification uniquely corresponds to the device where the payer's client is located.

When the payer client automatically logs in to the current account (when the user opens the payer client and the client automatically logs in to the current account), in step 402, the device information and the device trust identifier are sent to the device center to store the corresponding mapping relationship. The device information is information that can indicate the device where the current payer's client is located, for example, it may be an international mobile device identity code.

When the payer client receives the payment code generation request (the user enters the payment code generation instruction, for example, when clicking the "Payment Code" button on the client side), in step 403, the payment code acquisition request carrying the user information and the device trust identifier is sent to In the decoding center, the decoding center generates a payment code according to the user information and the device trust identifier and returns (step 404) to the payer client.

In step 405, the payer client displays the payment code to the payee client, so that the payee scans the code in step 406 and obtains the payment code. Among them, the payment code displayed by the payer client in step 405 can be time-limited, for example, the payment code is valid within 3 minutes after it is generated; if the payment code becomes invalid after 3 minutes, the payment code needs to be regenerated in the decoding center and returned to the payer client .

In step 407, the payee client sends a payment request carrying the payment code and payment information to the payee server. The payment information may include: payee account, transaction amount, product information, and transaction time.

After receiving the payment request, the payee server sends a payment request carrying the payment code to the decoding center in step 408, and the decoding center parses the payment code and returns the user information and device trust identifier to the payee server in step 409. The payee server sends the complete transaction information of this transaction to the payment system, so that the payment system performs the payment operation for this transaction. Wherein, in step 410, the transaction information includes: user information, device trust identifier, and payment information.

Before the payment system performs payment operations on this transaction, it first consults with the risk control system whether there is any risk in this transaction. In step 411, the payment system sends transaction information carrying user information and device trust identification to the risk control system. In

steps

412 and 413, the risk control system sends the equipment trust mark to the equipment center, and the equipment center obtains the equipment query result according to the stored mapping relationship and returns it to the risk control system. The device query result includes: there is no device information corresponding to the device trust identifier or device information corresponding to the device trust identifier.

According to the result of the equipment query, the risk control system performs risk identification of the equipment information dimension on the transaction information of this transaction in step 414. For example, if the device query result is that there is no device information corresponding to the device trust mark, the transaction is high risk; if the device query result is that the device information corresponding to the device trust mark is device B, and it is confirmed that the user’s commonly used device in this transaction is Device A identifies that this transaction is a high risk; if the device query result is that the device information corresponding to the device trust mark is device B, and it is confirmed that the user's commonly used device in this transaction is device B, then it is identified that this transaction is risk-free. In step 414 risk identification, the risk control system is based on the risk identification of the equipment information dimension, and integrates other kinds of historical information, carries out risk identification of this transaction from multiple dimensions, and finally comprehensively obtains the risk identification result of this transaction, as The risk control result is returned to the payment system in step 415. Among them, a variety of historical information includes, the user's historical transaction location, transaction time, transaction object type, transaction commodity type and transaction amount in this transaction.

Finally, the payment system completes the payment operation for this transaction according to the risk control result (step 416); or, abandons the payment operation for this transaction.

This implementation describes a complete transaction payment process. The payer client stores the device information and the device trust identifier uniquely corresponding to the device where the payer client is located in the device center in advance, and the payee server uses the payment code displayed by the payer client. Obtain the equipment information and the equipment trust mark, so that when the risk control system identifies the risk of this transaction, it can query the corresponding equipment information from the equipment center according to the equipment trust mark, and identify the risk of principal and interest transactions in the equipment information dimension. Since the device trust identifier uniquely corresponds to the device where the payer's client is located in this transaction, the risk control system can accurately obtain the device information of the payer of this transaction, and perform risk identification in the device information dimension, which reduces the payment risk of the payer.

As shown in Figure 5, this specification provides a transaction risk identification device, which can execute the transaction risk identification method of any embodiment of this specification. The device may include a receiving module 501, a processing module 502, and a risk identification module 503. Wherein: the receiving module 501 is used to receive the transaction information of this transaction to be identified, the transaction information includes the user information corresponding to this transaction and the device trust identifier; the device trust identifier is used to uniquely correspond to the occurrence of this transaction The device where it is located; processing module 502, used to send the device trust identifier to the device center, and receive the device query results corresponding to the device trust identifier returned by the device center; risk identification module 503, used to As a result of the equipment query, risk identification is performed on the transaction information.

In one embodiment, the risk identification module 503 is configured to perform risk identification on the transaction information according to the device query result, including: when the device query result returned by the device center includes: the device query result does not exist The device information corresponding to the device trust identifier confirms that the current transaction is a risky transaction.

In one embodiment, the risk identification module 503 is configured to perform risk identification on the transaction information according to the device query result, including: when the device query result returned by the device center includes: the device trust Identify the corresponding device information, confirm that the device information is different from the device where the history of the user information is located, and confirm that the current transaction is a risky transaction.

As shown in Figure 6, this specification provides a payment processing device that can execute the payment processing method of any embodiment of this specification. The device may include a request receiving module 601, an obtaining module 602, and a display module 603. Wherein: the request receiving module 601 is used to receive the payment code generation request; the obtaining module 602 is used to obtain the payment code according to the user information and the device trust identifier; the device trust identifier is used to uniquely correspond to the device where the transaction occurred; The payment code includes the user information and the device trust identifier; the display module 603 is configured to display the payment code so that the payee can execute the current payment transaction according to the payment code.

In one embodiment, the obtaining module 602 is configured to obtain the payment code according to the user information and the device trust identifier, including: sending a payment code obtaining request to the decoding center, and the payment code obtaining request includes: the user information And a device trust identifier; receiving the payment code returned by the decoding center, where the payment code is generated by the decoding center according to the user information and the device trust identifier.

In one embodiment, as shown in FIG. 7, the apparatus further includes: a sending module 701, configured to send the device information of the device where the payer client is located and the device trust identifier to the device center, so that The device center stores the mapping relationship between the device information and the device trust identifier.

In one embodiment, the sending module 701 is configured to send the device information of the device where the payer client is located and the device trust identifier to the device center, including: when the client login is detected, sending The device information and the device trust identifier are sent to the device center.

In one embodiment, as shown in FIG. 7, the apparatus further includes: a storage module 702, configured to store a device trust identifier, the device trust identifier being an identifier generated by the server according to device associated parameters, and the device associated parameters include : International Mobile Equipment Identity Code, International Mobile User Identity Code, random number generated by the client and random number generated by the server.

As shown in Figure 8, this specification provides another payment processing device, which can execute the payment processing method of any embodiment of this specification. The device may include a payment request receiving module 801, a second obtaining module 802, and a second sending module 803. Wherein: the payment request receiving module 801 is used to receive the payment request of this transaction, and the payment request carries: the payment code and the payment information of this transaction; the second obtaining module 802 is used to obtain the payment code including The user information and the device trust identifier of the device are used to uniquely correspond to the device where the transaction occurs; the second sending module 803 is used to send the transaction information of this transaction to the payment system, and the transaction information carries : The user information, the device trust identifier, and the payment information.

In one embodiment, when the second obtaining module 802 is used to obtain the user information and the device trust identifier included in the payment code, it includes: sending a resolution request to a decoding center, and the resolution request includes: the payment Code; receiving the user information and device trust identifier returned by the decoding center from the analysis of the payment code.

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

For the device embodiment, since it basically corresponds to the method embodiment, the relevant part can refer to the part of the description of the method embodiment. The device embodiments described above are merely illustrative, where the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in One place, or it can be distributed to multiple network units. Some or all of the modules may be selected according to actual needs to achieve the objectives of at least one embodiment of the specification. Those of ordinary skill in the art can understand and implement without creative work.

This specification also provides a computer device, including a memory, a processor, and a computer program stored in the memory and capable of running on the processor. When the processor executes the program, the transaction in any embodiment of this specification can be realized. Risk identification method, or the payment processing method that implements any embodiment of this specification.

This specification also provides a computer-readable storage medium on which a computer program is stored. When the program is executed by a processor, it can implement the transaction risk identification method of any embodiment of this specification, or implement any embodiment of this specification. Payment processing method.

Wherein, the non-transitory computer-readable storage medium may be ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, optical data storage device, etc., which is not limited in this specification.

Those skilled in the art will easily think of other embodiments of this specification after considering the specification and practicing the invention applied here. This specification is intended to cover any variations, uses, or adaptive changes of this specification. These variations, uses, or adaptive changes follow the general principles of this specification and include common knowledge or customary technical means in the technical field not applied for in this specification. . The description and the embodiments are only regarded as exemplary, and the true scope and spirit of the description are pointed out by the following claims.

It should be understood that this specification is not limited to the precise structure that has been described above and shown in the drawings, and various modifications and changes can be made without departing from its scope. The scope of this specification is only limited by the appended claims.

The above are only the preferred embodiments of this specification and are not used to limit this specification. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this specification shall be included in this specification. Within the scope of protection.

Claims

A method for identifying transaction risks, the method comprising:

Receiving transaction information of the current transaction to be identified, the transaction information including the user information corresponding to the transaction and the device trust identifier; the device trust identifier is used to uniquely correspond to the device where the transaction occurs;

Sending the device trust identifier to the device center, and receiving the device query result corresponding to the device trust identifier returned by the device center;

Perform risk identification on the transaction information according to the result of the device query.
The method according to claim 1, wherein the performing risk identification on the transaction information according to the device query result includes:

If the device query result returned by the device center includes: there is no device information corresponding to the device trust identifier, it is confirmed that the current transaction is a risky transaction.
The method according to claim 1, wherein the performing risk identification on the transaction information according to the device query result includes:

If the device query result returned by the device center includes: device information corresponding to the device trust identifier, and it is confirmed that the device information is different from the device where the history of the user information is located, then it is confirmed that the current transaction is a risky transaction.
A payment processing method applied to a client of a payer, the method comprising:

Receive payment code generation request;

Obtain the payment code according to the user information and the device trust identifier; the device trust identifier is used to uniquely correspond to the device where the transaction occurs; the payment code includes the user information and the device trust identifier;

The payment code is displayed, so that the payee executes this payment transaction according to the payment code.
The method according to claim 4, wherein the obtaining the payment code according to the user information and the device trust identifier includes:

Sending a payment code acquisition request to the decoding center, where the payment code acquisition request includes: the user information and the device trust identifier;

Receiving the payment code returned by the decoding center, where the payment code is generated by the decoding center according to the user information and the device trust identifier.
The method according to claim 4, before the receiving the payment code generation request, the method further comprises:

The device information of the device where the payer client is located and the device trust identifier are sent to the device center, so that the device center stores the mapping relationship between the device information and the device trust identifier.
The method according to claim 6, wherein the sending the device information of the device where the payer client is located and the device trust identifier to the device center includes:

When the client login is detected, the device information and the device trust identifier are sent to the device center.
The method according to claim 4, before the receiving the payment code generation request, the method further comprises:

Stores the device trust identifier, the device trust identifier is an identifier generated by the server according to device associated parameters, and the device associated parameters include: International Mobile Equipment Identity, International Mobile Subscriber Identity, random numbers generated by the client, and generated by the server random number.
A payment processing method, the method comprising:

Receive a payment request for this transaction, where the payment request carries: a payment code and payment information for this transaction;

Acquiring the user information and the device trust identifier included in the payment code, where the device trust identifier is used to uniquely correspond to the device where the transaction occurred;

Send transaction information of this transaction to the payment system, where the transaction information carries: the user information, the device trust identifier, and the payment information.
The method according to claim 9, wherein said obtaining the user information and the device trust identifier included in the payment code includes:

Sending a parsing request to the decoding center, where the parsing request includes: the payment code;

Receiving the user information and the device trust identifier that are obtained by analyzing the payment code and returned by the decoding center.
A transaction risk identification device, the device comprising:

The receiving module is used to receive the transaction information of this transaction to be identified, the transaction information includes the user information corresponding to this transaction and the device trust identifier; the device trust identifier is used to uniquely correspond to the device where the transaction occurs ；

A processing module, configured to send the device trust identifier to the device center, and receive the device query result corresponding to the device trust identifier returned by the device center;

The risk identification module is used to perform risk identification on the transaction information according to the device query result.
The apparatus according to claim 11, wherein the risk identification module is configured to perform risk identification on the transaction information according to the device query result, comprising:

When the device query result returned by the device center includes: there is no device information corresponding to the device trust identifier, it is confirmed that the current transaction is a risky transaction.
The apparatus according to claim 11, wherein the risk identification module is configured to perform risk identification on the transaction information according to the device query result, comprising:

When the device query result returned by the device center includes: the device information corresponding to the device trust identifier, and it is confirmed that the device information is different from the device where the history of the user information is located, it is confirmed that the current transaction is a risky transaction.
A payment processing device applied to a client of a payer, the device comprising:

The request receiving module is used to receive the payment code generation request;

The obtaining module is configured to obtain a payment code based on user information and a device trust identifier; the device trust identifier is used to uniquely correspond to the device where the transaction occurs; the payment code includes the user information and the device trust identifier;

The display module is used to display the payment code so that the payee can execute the payment transaction according to the payment code.
The apparatus according to claim 14, wherein the obtaining module is configured to obtain the payment code according to the user information and the device trust identifier, including:

Sending a payment code acquisition request to the decoding center, where the payment code acquisition request includes: the user information and the device trust identifier;

Receiving the payment code returned by the decoding center, where the payment code is generated by the decoding center according to the user information and the device trust identifier.
The device according to claim 14, further comprising:

The sending module is configured to send the device information of the device where the payer client is located and the device trust identifier to the device center, so that the device center stores the mapping relationship between the device information and the device trust identifier.
The apparatus according to claim 16, wherein the sending module is configured to send the device information of the device where the payer client is located and the device trust identifier to the device center, including:

When the client login is detected, the device information and the device trust identifier are sent to the device center.
The device according to claim 14, further comprising:

The storage module is used to store the device trust identifier. The device trust identifier is an identifier generated by the server according to device associated parameters. The device associated parameters include: International Mobile Equipment Identity, International Mobile User Identity, and random numbers generated by the client And the random number generated by the server.
A payment processing device, the device comprising:

The payment request receiving module is used to receive the payment request of this transaction, and the payment request carries: the payment code and the payment information of this transaction;

The second obtaining module is configured to obtain the user information and the device trust identifier included in the payment code, where the device trust identifier is used to uniquely correspond to the device where the transaction occurs;

The second sending module is configured to send transaction information of this transaction to the payment system, where the transaction information carries: the user information, the device trust identifier, and the payment information.
The apparatus according to claim 19, when the second obtaining module is configured to obtain the user information and the device trust identifier included in the payment code, the method includes:

Sending a parsing request to the decoding center, where the parsing request includes: the payment code;

Receiving the user information and the device trust identifier that are obtained by analyzing the payment code and returned by the decoding center.
A computer device, comprising a memory, a processor, and a computer program stored in the memory and running on the processor. The processor implements the method according to any one of claims 1 to 3 when the program is executed, or implements The method of any one of claims 4-8, or the method of any one of claims 9-10.
A computer-readable storage medium with a computer program stored thereon, which when executed by a processor implements the method described in any one of claims 1-3, or implements the method described in any one of claims 4-8, Or implement the method of any one of claims 9-10.