Security inspection method, device, equipment and storage medium

Abstract

The embodiments of the present application disclose a security inspection method, apparatus, device and storage medium, which belong to the field of Internet technology. The method includes: receiving an initial payment request for a target payment process from a client; sending a first security inspection request to a first security inspection party in a security inspection party cluster; receiving a first security inspection result; the first security inspection result is used to indicate that the target payment process has not passed the inspection, and the first security inspection result includes first identification information, and the first identification information is used to indicate that the first security inspection party has performed a security inspection task for the target payment process; sending the first security inspection result to the client. The present application can obtain the information that the corresponding security inspection party has performed a security inspection on the target payment process through the identification information, so that based on the identification information, the security inspection party can perform idempotent operations on the target payment process without obtaining other trigger information, thereby reducing the complexity of information interaction.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of Internet technology, and in particular to a security inspection method, apparatus, device, and storage medium. Background Art

[0002] With the development of Internet technology, people are accustomed to paying various fees online. In order to ensure the security of online payment, payment applications need to perform security checks on the online payment process.

[0003] In related technologies, the backend server of a payment application performs security checks on the online payment process by requesting multiple security checkers. To prevent duplicate security checks on the online payment process, each security checker is equipped with its own idempotent mechanism. Specifically, each security checker needs to identify its own trigger information to trigger its own idempotent mechanism. The security checker performs security checks on the online payment process based on its corresponding security check policy. The idempotent mechanism is used to prevent duplicate security checks on the same payment process.

[0004] However, in the above-mentioned related technologies, since each security checker has its own idempotent mechanism, that is, each security checker requires its own triggering information, the complexity of information interaction increases. Summary of the Invention

[0005] The embodiments of the present application provide a security inspection method, apparatus, device, and storage medium that can reduce the complexity of information interaction and thus improve the efficiency of information interaction. The technical solution is as follows:

[0006] According to one aspect of an embodiment of the present application, a security inspection method is provided, the method comprising:

[0007] Receive an initial payment request from a client for a target payment process;

[0008] Sending a first security check request to a first security checker in the security checker cluster, where the first security check request is used to request the first security checker to perform a security check task for the target payment process;

[0009] receiving a first security check result fed back by the first security checker; wherein the first security check result is used to indicate that the target payment process has failed the check, and the first security check result includes first identification information, and the first identification information is used to indicate that the first security checker has performed a security check task for the target payment process;

[0010] Send the first security check result to the client.

[0011] According to one aspect of an embodiment of the present application, a security inspection method is provided, the method comprising:

[0012] Receiving a first security check request from a server; wherein the first security check request is used to request a first security check party to perform a security check task for a target payment process;

[0013] If the target payment process fails the inspection, generating a first security inspection result; wherein the first security inspection result is used to indicate that the target payment process fails the inspection, and the first security inspection result includes first identification information, and the first identification information is used to indicate that the first security inspection party has performed a security inspection task for the target payment process;

[0014] Send the first security check result to the server.

[0015] According to one aspect of an embodiment of the present application, a security inspection method is provided, the method comprising:

[0016] Displaying a user payment interface, wherein the user payment interface includes a first payment control for initiating a target payment process;

[0017] In response to a triggering operation on the first payment control, sending an initial payment request for the target payment process to a server;

[0018] Receiving a first security check result from the server; wherein the first security check result is used to indicate that the target payment process has failed the check, and the first security check result includes first identification information, and the first identification information is used to indicate that a first security check party has performed a security check task for the target payment process;

[0019] A first security prompt interface is displayed, where the first security prompt interface includes security prompt information determined based on the first security check result.

[0020] According to one aspect of an embodiment of the present application, a security inspection device is provided, the device comprising:

[0021] A payment request receiving module, configured to receive an initial payment request for a target payment process from a client;

[0022] An inspection request sending module, configured to send a first security inspection request to a first security inspection party in the security inspection party cluster, wherein the first security inspection request is used to request the first security inspection party to perform a security inspection task for the target payment process;

[0023] an inspection result receiving module, configured to receive a first security inspection result fed back by the first security inspection party; wherein the first security inspection result is used to indicate that the target payment process has failed the inspection, and the first security inspection result includes first identification information, and the first identification information is used to indicate that the first security inspection party has performed a security inspection task for the target payment process;

[0024] The inspection result sending module is used to send the first security inspection result to the client.

[0025] In an exemplary embodiment, the first identification information includes a first checker identifier and a first idempotent identifier; wherein the first checker identifier is used to globally uniquely identify the first security checker, and the first idempotent identifier is used to globally uniquely identify the first security check result.

[0026] In an exemplary embodiment, the payment request receiving module is further configured to receive a continuing payment request for the target payment process from the client, wherein the continuing payment request includes the first checking party identifier and the first idempotent identifier;

[0027] The inspection request sending module is further configured to send a secondary security inspection request to the first security inspection party based on the first inspection party identifier, wherein the secondary security inspection request includes the first idempotent identifier;

[0028] The inspection result receiving module is further configured to receive a third security inspection result fed back by the first security inspection party, wherein the third security inspection result is used to indicate that the security inspection result of the first security inspection party for the target payment process has been displayed;

[0029] The inspection request sending module is further configured to send a third security inspection request to a second security inspection party in the security inspection party cluster based on the third security inspection result, wherein the third security inspection request is used to request the second security inspection party to perform a security inspection task for the target payment process;

[0030] The deduction process execution module is used to execute the deduction process for the target payment process after all security check parties in the security check party cluster have executed the security check task for the target payment process.

[0031] In an exemplary embodiment, the payment request receiving module is further configured to receive a continuing payment request for the target payment process from the client, wherein the continuing payment request includes the first checking party identifier and the first idempotent identifier;

[0032] a result information determination module, configured to determine, based on the first checker identifier and the first idempotent identifier, that the security check result of the first security checker on the target payment process has been displayed;

[0033] The inspection request sending module is further configured to send a third security inspection request to a second security inspection party in the security inspection party cluster, wherein the third security inspection request is used to request the second security inspection party to perform a security inspection task for the target payment process;

[0034] The deduction process execution module is further configured to execute the deduction process for the target payment process after all security check parties in the security check party cluster have executed the security check task for the target payment process.

[0035] In an exemplary embodiment, the security check stopping module is configured to stop sending security check requests to a security checker next to the first security checker in the security checker cluster upon receiving the first security check result fed back by the first security checker;

[0036] The inspection request sending module is also used to send a security inspection request to the next security inspection party of the first security inspection party in the security inspection party cluster upon receiving the second security inspection result fed back by the first security inspection party, wherein the second security inspection result is used to indicate that the target payment process has passed the inspection.

[0037] In an exemplary embodiment, the information acquisition module is configured to acquire the query priority of each security checker included in the security checker cluster and the dependency relationship between the security checkers, wherein the query priority is determined by the security level of the security checker;

[0038] A first sequence acquisition module, configured to sort the security check parties based on their inquiry priorities to obtain an initial inquiry sequence;

[0039] The second sequence acquisition module is used to adjust the initial query sequence based on the dependency relationship between the various security check parties to obtain an adjusted query sequence; wherein the adjusted query sequence is used to specify the order of requesting security checks to the various security check parties.

[0040] According to one aspect of an embodiment of the present application, a security inspection device is provided, the device comprising:

[0041] A check request receiving module, configured to receive a first security check request from a server; wherein the first security check request is used to request a first security check party to perform a security check task for a target payment process;

[0042] an inspection result generating module, configured to generate a first security inspection result if the target payment process fails the inspection; wherein the first security inspection result is used to indicate that the target payment process fails the inspection, and the first security inspection result includes first identification information, and the first identification information is used to indicate that the first security inspection party has performed a security inspection task for the target payment process;

[0043] A result sending module is used to send the first security check result to the server.

[0044] In an exemplary embodiment, the first identification information includes a first checker identifier and a first idempotent identifier; wherein the first checker identifier is used to globally uniquely identify the first security checker, and the first idempotent identifier is used to globally uniquely identify the first security check result.

[0045] In an exemplary embodiment, the inspection result generating module is further configured to generate a second security inspection result if the target payment process passes the inspection, wherein the second security inspection result is configured to indicate that the target payment process passes the inspection;

[0046] The result sending module is further configured to send the second security check result to the server.

[0047] In an exemplary embodiment, the check request receiving module is further configured to obtain a secondary security check request from the server, wherein the secondary security check request includes the first idempotent identifier;

[0048] The result sending module is further configured to send a third security check result to the server in response to detecting that the first idempotent identifier is included in the data repository, wherein the third security check result is used to indicate that the security check result of the target security check party for the target payment process has been displayed.

[0049] According to one aspect of an embodiment of the present application, a security inspection device is provided, the device comprising:

[0050] A payment interface display module, configured to display a user payment interface, wherein the user payment interface includes a first payment control for initiating a target payment process;

[0051] a payment request sending module, configured to send an initial payment request for the target payment process to a server in response to a triggering operation on the first payment control;

[0052] a result receiving module configured to receive a first security check result from the server; wherein the first security check result is used to indicate that the target payment process has failed the check, and the first security check result includes first identification information, and the first identification information is used to indicate that the first security check party has performed a security check task for the target payment process;

[0053] The prompt interface display module is used to display a first security prompt interface, wherein the first security prompt interface includes security prompt information determined based on the first security check result.

[0054] In an exemplary embodiment, the first identification information includes a first policy identifier and a first idempotent identifier, the first checker identifier is used to globally uniquely identify the first security checker, and the first idempotent identifier is used to globally uniquely identify the first security check result.

[0055] In an exemplary embodiment, the first security prompt interface includes a second payment control:

[0056] The payment request sending module is further used to send a continuing payment request for the target payment process to the server in response to a triggering operation on the second payment control, wherein the continuing payment request includes the first checking party identifier and the first idempotent identifier.

[0057] According to one aspect of an embodiment of the present application, a computer device is provided, comprising a processor and a memory, wherein the memory stores at least one instruction, at least one program, a code set, or an instruction set, and the at least one instruction, the at least one program, the code set, or the instruction set is loaded and executed by the processor to implement the above-mentioned security inspection method.

[0058] Optionally, the computer device is a terminal or a server.

[0059] According to one aspect of an embodiment of the present application, a computer-readable storage medium is provided, in which at least one instruction, at least one program, a code set or an instruction set is stored. The at least one instruction, the at least one program, the code set or the instruction set is loaded and executed by a processor to implement the above-mentioned security inspection method.

[0060] According to one aspect of an embodiment of the present application, a computer program product or computer program is provided, the computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the above-described security check method.

[0061] The technical solutions provided in the embodiments of the present application can bring the following beneficial effects:

[0062] By including identification information in the security check results, the corresponding security checker can obtain information indicating that the target payment process has been security checked. Based on this identification information, the security checker can implement idempotent operations for the target payment process. This allows each security checker to utilize a unified idempotent mechanism to perform security checks on the payment process, eliminating the need to configure their own internal idempotent mechanisms. This reduces the complexity of information exchange and improves its efficiency. Furthermore, when adding new security checkers, the onboarding process is simplified and the workload is reduced, as new idempotent mechanisms do not need to be designed, thereby improving onboarding efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0063] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0064] Figure 1 This is a schematic diagram of an implementation environment for a solution provided by an embodiment of the present application;

[0065] Figure 2 This is a flow chart of a security inspection method provided by one embodiment of the present application;

[0066] Figure 3 is a flow chart of a security inspection method provided by another embodiment of the present application;

[0067] Figure 4 is a flow chart of a security inspection method provided by another embodiment of the present application;

[0068] Figure 5 This is a schematic diagram of a user payment interface provided by an embodiment of the present application;

[0069] Figure 6 This is a schematic diagram of a security prompt interface provided by an embodiment of the present application;

[0070] Figure 7 This is a schematic diagram of a password input interface provided by an embodiment of the present application;

[0071] Figure 8 This is a schematic diagram of a successful payment interface provided by an embodiment of the present application;

[0072] Figure 9 is a flow chart of a security inspection method provided by another embodiment of the present application;

[0073] Figures 10 to 13 is a block diagram of a security inspection device provided in an embodiment of the present application;

[0074] Figure 14 This is a structural block diagram of a terminal provided by an embodiment of the present application;

[0075] Figure 15 This is a structural block diagram of a server provided in one embodiment of the present application. DETAILED DESCRIPTION

[0076] In order to make the objectives, technical solutions and advantages of this application clearer, the implementation methods of this application will be further described in detail below with reference to the accompanying drawings.

[0077] Please refer to Figure 1 , which shows a schematic diagram of a solution implementation environment provided by an embodiment of the present application. The solution implementation environment can be implemented as an online payment system, and the solution implementation environment may include: a terminal 11, a server 12, and a security checker 13.

[0078] Terminal 11 is a terminal device used by a user. Terminal 11 can be an electronic device such as a mobile phone, tablet computer, wearable device, or PC (Personal Computer). The user can perform online payment operations on terminal 11. For example, if a client running a target application is installed on terminal 11, the user can perform online payment operations on the client of the target application. The target application can be a payment application, a shopping application, a reservation application, a mobile business hall application, an online banking application, or any other application with a payment function, which is not limited in this embodiment of the present application.

[0079] The server 12 may be a background server of the target application, configured to provide background services to the client of the target application. The server 12 may be a single server, a server cluster consisting of multiple servers, or a cloud computing service center.

[0080] The security checker 13 is used to perform security checks on the online payment process. The security checker 13 can be a single server, a server cluster consisting of multiple servers, or a cloud computing service center. The security checker 13 is provided with a security check policy, which can be a payment information inspection security check policy, a payment risk warning security check policy, a duplicate payment warning security check policy, a payment interception security check policy, etc., which is not limited in the embodiment of the present application. Optionally, the online payment system can include multiple security checkers 13, and different security checkers 13 are provided with different security check policies. Among them, the security check policy refers to the method of performing security checks on the online payment process.

[0081] Optionally, the terminal 11 and the server 12 may communicate with each other through a network, and the server 12 and the security checker 13 may communicate with each other through a network.

[0082] For example, taking a client application for a payment application as an example, during an online payment process, in response to a user's payment operation, terminal 11 sends a payment request to server 12. Server 12 then sends a security check request to security checker 13. Security checker 13 then performs a security check on the payment request based on the corresponding security check policy and sends the security check result to server 12. Server 12 then forwards the security check result to terminal 11, which then displays a security prompt interface to the user based on the security check result.

[0083] Please refer to Figure 2 , which shows a flow chart of a security inspection method provided by an embodiment of the present application. The execution subject of each step of the method may be the server 12 introduced above. The method may include the following steps (201-204):

[0084] Step 201: Receive an initial payment request for a target payment process from a client.

[0085] In an embodiment of the present application, a target application with an online payment function is installed in the client, and the target payment process may refer to an online payment process initiated by a user through the target application. For example, the target payment process may be a payment process initiated by a user through a payment application; the target payment process may also be a payment process initiated by a user through a shopping application; or the target payment process may also be a payment process initiated by a user through a reservation application, although this embodiment of the present application is not limited thereto.

[0086] The payment request is used to request the server to process the target payment process to complete the corresponding transaction (such as the exchange of money and goods). Optionally, the initial payment request refers to the first payment request for the target payment process. For example, in response to multiple initiation operations of the user for the target payment process, multiple payment requests for the target payment process may be formed. Alternatively, in order to ensure the security of the target payment process, the user is required to confirm the payment information multiple times, thereby forming multiple payment requests for the target payment process. The first payment request among the multiple payment requests is the initial payment request. Optionally, the target payment process has a globally unique payment identifier, and the multiple payment requests corresponding to the target payment process will include the payment identifier to identify that the multiple payment requests are all payment requests corresponding to the target payment process.

[0087] Step 202: Send a first security check request to a first security checker in the security checker cluster. The first security check request is used to request the first security checker to perform a security check task for a target payment process.

[0088] The security check party is used to perform a security check on the target payment process based on the corresponding security check strategy. Among them, the security check strategy refers to the method of performing a security check on the target payment process. Different security check parties use different security check strategies to perform security checks on the target payment process, and different security check strategies target different security areas. For example, security check party A can perform a security check on the payment risk of the target payment process based on a payment risk warning type security check strategy, and security check party B can perform a security check on possible duplicate payments in the target payment process based on a duplicate payment warning type security check strategy. This embodiment of the present application is not limited here.

[0089] Optionally, a security checker cluster can include multiple security checkers. For example, to ensure a more comprehensive security check of the target payment process, multiple security checkers can be set up for the target application from multiple security perspectives. Designers can adaptively add, reduce, or modify security checkers in the security checker cluster based on changes in the target application's actual application strategy.

[0090] Optionally, the first security checker may refer to any security checker in the security checker cluster. The first security check request includes a first checker identifier configured for the first security checker by the server corresponding to the first security checker. The first checker identifier is used to globally uniquely identify the first security checker (i.e., the security check policy corresponding to the first security checker). The first security check request may also include a payment identifier corresponding to the target payment process to identify that the first security check request is initiated for the target payment process.

[0091] In one example, security checkers can be requested to perform security checks on a target payment process in a configured order. For example, before requesting a security checker to perform a security check on a target payment process, multiple security checkers in a security checker cluster can be sorted. The specific method can be as follows: obtaining the query priority of each security checker included in the security checker cluster and the dependencies between each security checker, where the query priority is determined by the security level of the security checker; sorting each security checker based on the query priority of each security checker to obtain an initial query sequence; adjusting the initial query sequence based on the dependencies between each security checker to obtain an adjusted query sequence; wherein the adjusted query sequence is used to specify the order in which security checks are requested from each security checker.

[0092] The security level of a security checker indicates the importance and necessity of the security checker in the security check of the target payment process. The higher the security level of a security checker, the more important it is to the security check of the target payment process. For example, if the security level of security checker A, used for payment risk checks, is higher than the security level of security checker B, used for fraudulent payment checks, and the security level of security checker B, used for fraudulent payment checks, is higher than the security level of security checker C, used for duplicate payment checks, the server should prioritize sending security check requests to security checker A. In other words, the initial query sequence is security checker A, security checker B, and security checker C.

[0093] A dependency between security checkers refers to the existence of shared information between them. For example, if Security Checker A and Security Checker C need to obtain the user's identity information, and the initial payment request does not include the user's identity information, but the user uploads the information at the request of Security Checker C, then Security Checker A will need to rely on whether the user's identity information has been recorded on the server. This means that Security Checker C can be adjusted to make its request before Security Checker A. The query sequence after this adjustment is Security Checker C, Security Checker A, and Security Checker B.

[0094] Step 203, receiving the first security check result fed back by the first security check party; wherein the first security check result is used to indicate that the target payment process has not passed the inspection, and the first security check result includes first identification information, and the first identification information is used to indicate that the first security check party has performed the security check task for the target payment process.

[0095] The first identification information may include a first checking party identifier and a first idempotent identifier; wherein the first checking party identifier is used to globally uniquely identify the first security checking party, and the first idempotent identifier is used to globally uniquely identify the first security checking result.

[0096] Optionally, the first checker identifier can be obtained by hashing to ensure the global uniqueness of the first checker identifier. The first idempotent identifier can be obtained by self-incrementing the primary key to ensure that the first security checker can uniquely identify the first security check result based on the first idempotent identifier. For example, based on the idempotent identifier A, difference information is added to generate the idempotent identifier B, and based on the idempotent identifier B, difference information is added to generate the idempotent identifier C. The difference information can be a specified value (such as 1, 2, 3, etc.).

[0097] Optionally, the first security check result can be globally uniquely identified based on the first checker identifier and the first idempotent identifier. For example, based on the first checker identifier, it can be determined that the first security check result comes from the first security checker, and based on the first idempotent identifier, it can be determined that the first security check result was generated by the first security checker for the target payment process.

[0098] In an embodiment of the present application, the first security check result refers to the security check result fed back by the first security check party when the target payment process fails the inspection, and the second security check result below refers to the security check result fed back by the first security check party when the target payment process passes the inspection. For example, if the first security check party detects that there is a risk of duplicate payment in the target payment process (for the same merchant, the user initiates two payment processes of the same amount within the threshold time), a first security check result with a hit identifier is generated. If the first security check party detects that there is no risk of duplicate payment in the target payment process, a second security check result without a hit identifier is generated. Among them, the hit identifier is used to indicate that the target payment process has failed the inspection.

[0099] Optionally, upon receiving a first security check result fed back by the first security checker, stop sending a security check request to the next security checker of the first security checker in the security checker cluster; upon receiving a second security check result fed back by the first security checker, send a security check request to the next security checker of the first security checker in the security checker cluster, and the second security check result is used to indicate that the target payment process has passed the inspection.

[0100] Optionally, the second security check result includes a first check identifier to identify that the second security check result comes from the first security check party.

[0101] Step 204: Send the first security check result to the client.

[0102] Optionally, in response to detecting that the security check result includes a hit identifier, the server sends the security check result to the client; in response to detecting that the security check result does not include a hit identifier, the server does not send the security check result to the client.

[0103] In one example, after sending a first security check result to a client, in response to a user selecting to continue completing a transaction corresponding to a target payment process, a continue payment request for the target payment process is received. Since the continue payment request for the target payment process is a new payment request for the server, the server needs to again request each security checker in the security checker group to perform a security check on the target payment process. The specific content may be as follows: receiving a continue payment request for the target payment process from the client, the continue payment request including a first checker identifier and a first idempotent identifier; based on the first checker identifier, sending a second security check request to the first security checker, the second security check request including the first idempotent identifier; receiving a third security check result fed back by the first security checker, the third security check result being used to indicate that the security check result of the first security checker for the target payment process has been displayed; based on the third security check result, sending a third security check request to the second security checker in the security checker cluster, the third security check request being used to request the second security checker to perform a security check task for the target payment process; after all security checkers in the security checker cluster have performed the security check task for the target payment process, executing a deduction process for the target payment process.

[0104] The "continue payment request" is used to request the server to continue processing the target payment process to complete the transaction corresponding to the target payment process. A "continue payment request" can refer to any payment request for the target payment process after the initial payment request. For example, a "continue payment request" can refer to the second payment request for the target payment process, or the third payment request for the target payment process.

[0105] The second security check request is used to request the first security checker to perform a second security check on the target payment process. The third security check result is the security check result generated by the first security checker after the second security check on the target payment process. The second security checker is the security checker that follows the first security checker in the security checker cluster.

[0106] Optionally, since the continued payment request provides the first security checker with the data it needs or the data that has not changed, the target payment process will pass the inspection of the first security checker in the second inspection, or the security inspection result generated by the first security checker for the target payment process for the second time is the same as the security inspection result generated for the target payment process for the first time. In this way, the first security checker can skip the process of performing a security inspection on the target payment process again based on the first idempotent identifier, and can directly return the security inspection result with the identification information that does not need to be displayed. The server detects that the identification information does not need to be displayed and no longer sends the security inspection result to the client. The embodiment of the present application is based on the idempotent identifier, which can reduce the workload of the security checker and avoid the repeated sending and display of security inspection results with the same content, further reducing the amount of data transmission in the online payment system.

[0107] In a feasible example, the method for the server to perform a second processing on the target payment process may be as follows: receiving a request for continued payment from the client for the target payment process, the request for continued payment including a first inspection party identifier and a first idempotent identifier; based on the first inspection party identifier and the first idempotent identifier, determining that the security inspection result of the first security inspection party for the target payment process has been displayed; sending a third security inspection request to the second security inspection party in the security inspection party cluster, the third security inspection request is used to request the second security inspection party to perform a security inspection task for the target payment process; after all security inspection parties in the security inspection party cluster have performed the security inspection task for the target payment process, executing the deduction process for the target payment process. In the embodiment of the present application, the server determines that there is no need to send a security inspection request to the first security inspection party based on the first inspection party identifier and the first idempotent identifier, which can reduce the number of security inspection requests and thereby improve the efficiency of payment security inspection.

[0108] Optionally, the information interaction method between the client and the security checker complies with a unified information interaction protocol, such as a cross-platform information interaction protocol, and the backend server corresponding to the client acts as an intermediate layer, responsible for transferring the interaction information. For example, each security checker describes the content of the security check result in accordance with the cross-platform information interaction protocol. The client can understand the content of the security check result of each security checker based on the cross-platform information interaction protocol, without having to understand the security result content of each security checker one by one based on the different information interaction protocols defined internally by each security checker. By defining a unified information interaction mechanism (i.e., checker identifier + idempotent identifier + cross-platform message interaction protocol), the complexity of the client can be reduced, and it is easier for the client to understand the content of the security check result of each security checker. At the same time, when a new security checker needs to be added, it is only necessary to access the security checker according to the unified information interaction protocol, without the need to make additional modifications to the client and the backend server corresponding to the client, thereby avoiding additional modification workload, thereby reducing the access time of the new security checker, and thereby improving the online efficiency of the target application.

[0109] In summary, the technical solution provided by the embodiments of the present application, by setting identification information in the security check results, can obtain information that the corresponding security check party has conducted a security check on the target payment process. Based on this identification information, the security check party can implement idempotent operations for the target payment process, thereby allowing each security check party to use a unified idempotent mechanism to perform security checks on the payment process without having to set up their own internal idempotent mechanism, thereby reducing the complexity of information interaction and improving the efficiency of information interaction. In addition, when adding a new security check party, since there is no need to design a new idempotent mechanism, the difficulty and workload of the new security check party are reduced, thereby improving the access efficiency of the new security check party.

[0110] In addition, during the security check process for the target payment process, the security check party is requested to perform a security check on the target payment process in turn, and if the target payment process fails the check, the corresponding security check result is sent to the client, and only one security check result that needs to be displayed is sent at a time. The client only needs to understand one security check result at a time, and does not need to understand multiple security check results at the same time, thereby reducing the client's task processing volume and the complexity of the client's tasks, thereby alleviating the client's task pressure.

[0111] Furthermore, by defining a unified information exchange mechanism (i.e., inspector identifier + idempotent identifier + cross-platform message exchange protocol), the client no longer needs to understand the security results of different security inspectors based on different information exchange protocols. This reduces client complexity and makes it easier for clients to understand the security inspection results of each security inspector, improving the efficiency of understanding the security inspection results.

[0112] Furthermore, during information exchange, security checkers are isolated through checker identification, preventing information from different security checkers from influencing each other. Idempotence identification implements an idempotent mechanism within a security checker, preventing the mutual impact of different security check results from the same security checker and avoiding additional checks on the same target payment process. Using both checker identification and idempotence identification allows for accurate identification of exchanged information, thereby improving the accuracy of information exchange.

[0113] Please refer to Figure 3 , which shows a flow chart of a security inspection method provided by an embodiment of the present application. The execution subject of each step of the method may be the security inspection method 13 introduced above. The method may include the following steps (301-304):

[0114] Step 301: Receive a first security check request from a server.

[0115] The first security check request is used to request the first security check party to perform a security check task for the target payment process.

[0116] In this embodiment of the present application, the server refers to the backend server of the target application. The first security check request refers to the security check request sent by the server to the first security check party for the target payment process. The target payment process may refer to the online payment process initiated by the user through the client of the target application.

[0117] Optionally, the first security checker performs a security check on the target payment process based on a corresponding security check policy. A security check policy refers to a method for performing a security check on the target payment process. Different security checkers employ different security check policies to perform security checks on the target payment process, with different security check policies targeting different security areas.

[0118] Optionally, the first security check request includes a first checker identifier, which is uniformly set by the background server of the target application.

[0119] Step 302: If the target payment process fails the check, a first security check result is generated.

[0120] The first security check result is used to indicate that the target payment process has failed the check. The first security check result includes first identification information. The first identification information is used to indicate that the first security check party has performed a security check task for the target payment process.

[0121] Optionally, the first identification information includes a first checker identifier and a first idempotence identifier. The first checker identifier is used to globally uniquely identify the first security checker, and the first idempotence identifier is used to globally uniquely identify the first security check result. The methods for generating the checker identifier and the idempotence identifier have been described above and will not be repeated here.

[0122] Step 303: Send the first security check result to the server.

[0123] Optionally, if the target payment process passes the inspection, a second security inspection result is generated, the second security inspection result being used to indicate that the target payment process passes the inspection, and the second security inspection result is sent to the server, wherein the second security inspection result includes the first inspection party identifier.

[0124] Optionally, the first security check result includes a hit indicator, while the second security check result does not include a hit indicator. The hit indicator is used to indicate that the target payment process has failed the check.

[0125] In one example, in response to a user's request to continue payment for a target payment process, the server needs to request the first security checker to perform a second security check on the target payment process. Specifically, this process may include: obtaining a second security check request from the server, the second security check request including a first idempotency flag; and, in response to detecting the first idempotency flag in the data repository, sending a third security check result to the server. The third security check result indicates that the target security checker has previously displayed security check results for the target payment process.

[0126] Optionally, after returning the first security check result, the first security check party records the corresponding first idempotency identifier in the data repository and marks it as having conducted a security check on the target payment process and having returned the generated security check result to the backend server corresponding to the target application. If the first security check party detects the first idempotency identifier from the security check request and the first idempotency identifier is recorded in the data repository, the first security check party may not need to conduct a security check on the target payment process again, and may directly return the third security check result, and also identify the third security check result with the first idempotency identifier. Optionally, the third security check result may also include identification information that does not need to be displayed, and the identification information that does not need to be displayed may be used to prompt the server that there is no need to feedback the third security check result to the client.

[0127] In summary, the technical solution provided by the embodiments of the present application, by setting identification information in the security check results, can obtain information that the corresponding security check party has conducted a security check on the target payment process. Based on this identification information, the security check party can implement idempotent operations for the target payment process, thereby allowing each security check party to use a unified idempotent mechanism to perform security checks on the payment process without having to set up their own internal idempotent mechanism, thereby reducing the complexity of information interaction and improving the efficiency of information interaction. In addition, when adding a new security check party, since there is no need to design a new idempotent mechanism, the difficulty and workload of the new security check party are reduced, thereby improving the access efficiency of the new security check party.

[0128] Furthermore, during information exchange, security checkers are isolated through checker identification to prevent information from different security checkers from interfering with each other. Idempotence identification implements an idempotent mechanism within the security checker, preventing different security check results from the same security checker from interfering with each other and avoiding additional checks on the same target payment process.

[0129] Please refer to Figure 4 , which shows a flow chart of a security inspection method provided by an embodiment of the present application. The execution subject of each step of the method may be the terminal 11 introduced above, such as the client of the target application installed in the terminal 11. The method may include the following steps (401-404):

[0130] Step 401: Display a user payment interface, which includes a first payment control for initiating a target payment process.

[0131] The user payment interface is used to display payment information. The user payment interface may include payment recipient information (such as the name of the payment recipient), payment amount, payment controls, etc. For example, refer to Figure 5 The user payment interface 500 includes a payment amount 501 (ie, 0.01 yuan), a payment object 502 (ie, store A), and a payment control 503. The target payment process may refer to an online payment process initiated by a user through the client of the target application.

[0132] Step 402: In response to the triggering operation on the first payment control, an initial payment request for the target payment process is sent to the server.

[0133] The initial payment request refers to the first payment request for the target payment process. The triggering operation may refer to an operation such as pressing, clicking, or sliding the first payment control.

[0134] Step 403: Receive a first security check result from the server.

[0135] The first security check result is used to indicate that the target payment process has failed the check. The first security check result includes first identification information. The first identification information is used to indicate that the first security check party has performed a security check task for the target payment process.

[0136] Optionally, the first identification information includes a first policy identifier and a first idempotent identifier, the first checker identifier is used to globally uniquely identify the first security checker, and the first idempotent identifier is used to globally uniquely identify the first security check result. The first policy identifier and the first idempotent identifier can be stored in a local cache.

[0137] Step 404: Display a first security prompt interface, which includes security prompt information determined based on the first security check result.

[0138] The first security prompt interface refers to the security prompt interface corresponding to the first security check result. It includes security prompt information used to remind users of payment security. Different security prompt information can be determined based on different security check results. For example, if security check result A indicates that the target payment process has not passed the duplicate payment check, the security prompt information can be used to remind users that the transaction may involve duplicate payment operations. If security check result A indicates that the target payment process has not passed the fraud risk check, the security prompt information can be used to remind users that the transaction may involve fraud risks. Figure 6 Taking the security prompt interface corresponding to security check result A as an example, the security prompt interface 504 displays the security prompt message "You have already paid an order of the same amount at the current merchant, please confirm whether to continue payment."

[0139] Optionally, the first security prompt interface includes a second payment control. The second payment control is used to initiate a request to continue payment for the target payment process. In response to the triggering operation on the second payment control, a request to continue payment for the target payment process is sent to the server, and the request to continue payment includes the first checking party identifier and the first idempotent identifier. For example, referring to Figure 6 The security prompt interface 504 includes a confirm payment control 505 (i.e., a second payment control) and a cancel payment control 506. In response to a user triggering operation on the confirm payment control 505, the client sends a request to the server to continue payment for the target payment process. In response to a user triggering operation on the cancel payment control 506, the transaction corresponding to the target payment process is canceled.

[0140] Optionally, after all security check parties in the security check party cluster have performed the security check task for the target payment process, the client will receive a password input interface display instruction from the server and display the password input interface. In response to detecting that the user has completed the password input operation in the password input interface, the payment success interface will be displayed. For example, refer to Figure 7 and Figure 8 In the password input interface 507, the user can enter the payment password. In response to the completion of the password input operation, the payment success interface 800 is displayed, that is, the transaction corresponding to the target payment process has been completed.

[0141] In summary, the technical solution provided by the embodiments of the present application, by setting identification information in the security check results, can obtain information that the corresponding security check party has conducted a security check on the target payment process. Based on this identification information, the security check party can implement idempotent operations for the target payment process, thereby allowing each security check party to use a unified idempotent mechanism to perform security checks on the payment process without having to set up their own internal idempotent mechanism, thereby reducing the complexity of information interaction and improving the efficiency of information interaction. In addition, when adding a new security check party, since there is no need to design a new idempotent mechanism, the difficulty and workload of the new security check party are reduced, thereby improving the access efficiency of the new security check party.

[0142] In one exemplary embodiment, reference Figure 9 , which shows a flow chart of a security check method provided by another embodiment of the present application. The method can be applied to the online payment system introduced above. The method can be specifically as follows:

[0143] 1. The client 902 displays a user payment interface, which includes a first payment control for initiating a target payment process.

[0144] 2. User 901 triggers the first payment control to initiate a target payment process.

[0145] 3. The client 902 sends an initial payment request for the target payment process to the backend server 903.

[0146] 4. After receiving the initial payment request, the backend server 903 sends a first security check request to the first security checker 904. The first security check request includes a first checker identifier for globally uniquely identifying the first security checker 904.

[0147] 5. The first security checker 904 performs a security check on the target payment process based on the corresponding security check policy. In response to the target payment process failing the check, the first security checker 904 generates a first security check result with a hit identifier and sends the first security check result to the backend server 903. The first security check result includes the first checker identifier and a first idempotence identifier. The first idempotence identifier is used to globally uniquely identify the first security check result.

[0148] 6. When receiving the first security check, the backend server 903 sends the first security check result to the client 902 in response to detecting a hit identifier, and stops sending the security check request to the second security check party 905 .

[0149] 7. Based on the first security check result, the client 902 displays a first security prompt interface, which includes a second payment control.

[0150] 8. User 901 triggers the second payment control.

[0151] 9. The client 902 sends a payment continuation request for the target payment process to the backend server 903 . The payment continuation request includes the first checking party identifier and the first idempotent identifier.

[0152] 10. The backend server 903 sends a secondary security check request to the first security checker 904 based on the first checker identifier, where the secondary security check request includes the first idempotent identifier.

[0153] 11. In response to detecting that the second security check request includes the first idempotent flag, the first security checker 904 performs an idempotent check operation (ie, skips the check), generates and returns a second security check result, and the second security check result includes a no-display flag.

[0154] 12. In response to detecting that the second security check result includes the no-display-needed indicator, the backend server 903 sends a security check request to the second security checker 905 .

[0155] 13. The second security checker 905 performs a security check on the target payment process based on the corresponding security check strategy. In response to the target payment process failing the security check, it generates and returns a third security check result with a hit identifier. The third security check result includes a second checker identifier and a second idempotent identifier. The second checker identifier is used to globally uniquely identify the second security checker 905, and the second idempotent identifier is used to globally uniquely identify the third security check result.

[0156] 14. The backend server 903 sends the third security check result to the client 902. The backend server 903 adds a check completion identifier to the third security check result, indicating that all security checkers in the security checker cluster have completed the security check task for the target payment process.

[0157] 15. The client 902 displays a second security prompt interface corresponding to the third security check result.

[0158] 16. In response to detecting the user 901 continuing the payment operation, the client 902 displays a password input interface.

[0159] 17. In response to detecting that the user 901 has completed inputting the payment password, the client 902 displays a payment success interface.

[0160] In summary, the technical solution provided by the embodiments of the present application, by setting identification information in the security check results, can obtain information that the corresponding security check party has conducted a security check on the target payment process. Based on this identification information, the security check party can implement idempotent operations for the target payment process, thereby allowing each security check party to use a unified idempotent mechanism to perform security checks on the payment process without having to set up their own internal idempotent mechanism, thereby reducing the complexity of information interaction and improving the efficiency of information interaction. In addition, when adding a new security check party, since there is no need to design a new idempotent mechanism, the difficulty and workload of the new security check party are reduced, thereby improving the access efficiency of the new security check party.

[0161] The following are device embodiments of the present application, which can be used to implement the method embodiments of the present application. For details not disclosed in the device embodiments of the present application, please refer to the method embodiments of the present application.

[0162] Please refer to Figure 10 , which shows a block diagram of a security inspection device provided by one embodiment of the present application. This device has the functionality to implement the aforementioned method examples. These functionality can be implemented by hardware or by hardware executing corresponding software. This device can be a server or be located within a server. This device 1000 may include: a payment request receiving module 1001, an inspection request sending module 1002, an inspection result receiving module 1003, and an inspection result sending module 1004.

[0163] The payment request receiving module 1001 is configured to receive an initial payment request for a target payment process from a client.

[0164] The inspection request sending module 1002 is used to send a first security inspection request to a first security inspection party in the security inspection party cluster, where the first security inspection request is used to request the first security inspection party to perform a security inspection task for the target payment process.

[0165] The inspection result receiving module 1003 is used to receive the first security inspection result fed back by the first security inspection party; wherein, the first security inspection result is used to indicate that the target payment process has failed the inspection, and the first security inspection result includes first identification information, and the first identification information is used to indicate that the first security inspection party has performed the security inspection task for the target payment process.

[0166] The inspection result sending module 1004 is configured to send the first security inspection result to the client.

[0167] In an exemplary embodiment, the first identification information includes a first checker identifier and a first idempotent identifier; wherein the first checker identifier is used to globally uniquely identify the first security checker, and the first idempotent identifier is used to globally uniquely identify the first security check result.

[0168] In an exemplary embodiment, Figure 11 As shown, the device 1000 further includes: a deduction process execution module 1005.

[0169] The payment request receiving module 1001 is further configured to receive a payment continuation request for the target payment process from the client, wherein the payment continuation request includes the first checking party identifier and the first idempotent identifier.

[0170] The check request sending module 1002 is further configured to send a secondary security check request to the first security check party based on the first checker identifier, where the secondary security check request includes the first idempotent identifier.

[0171] The inspection result receiving module 1003 is further configured to receive a third security inspection result fed back by the first security inspection party, where the third security inspection result is used to indicate that the security inspection result of the target payment process by the first security inspection party has been displayed.

[0172] The inspection request sending module 1002 is also used to send a third security inspection request to the second security inspection party in the security inspection party cluster based on the third security inspection result, and the third security inspection request is used to request the second security inspection party to perform a security inspection task for the target payment process.

[0173] The deduction process execution module 1005 is configured to execute the deduction process for the target payment process after all security check parties in the security check party cluster have executed the security check task for the target payment process.

[0174] In an exemplary embodiment, Figure 11 As shown, the apparatus 1000 further includes: a result information determination module 1006 .

[0175] The payment request receiving module 1001 is further configured to receive a payment continuation request for the target payment process from the client, wherein the payment continuation request includes the first checking party identifier and the first idempotent identifier.

[0176] The result information determination module 1006 is configured to determine, based on the first checker identifier and the first idempotent identifier, whether the security check result of the first security checker on the target payment process has been displayed.

[0177] The inspection request sending module 1002 is further configured to send a third security inspection request to a second security inspection party in the security inspection party cluster, wherein the third security inspection request is configured to request the second security inspection party to perform a security inspection task for the target payment process.

[0178] The deduction process execution module 1005 is further configured to execute the deduction process for the target payment process after all security check parties in the security check party cluster have executed the security check task for the target payment process.

[0179] In an exemplary embodiment, Figure 11 As shown, the device 1000 further includes: a safety check stopping module 1007 .

[0180] The security check stopping module 1007 is configured to stop sending security check requests to a security checker next to the first security checker in the security checker cluster upon receiving the first security check result fed back by the first security checker.

[0181] The inspection request sending module 1002 is also used to send a security inspection request to the next security inspection party of the first security inspection party in the security inspection party cluster upon receiving the second security inspection result fed back by the first security inspection party, and the second security inspection result is used to indicate that the target payment process has passed the inspection.

[0182] In an exemplary embodiment, Figure 11As shown, the apparatus 1000 further includes: an information acquisition module 1008 , a first sequence acquisition module 1009 and a second sequence acquisition module 1010 .

[0183] The information acquisition module 1008 is configured to acquire the query priority of each security checker included in the security checker cluster and the dependency relationship between the security checkers. The query priority is determined by the security level of the security checker.

[0184] The first sequence acquisition module 1009 is configured to sort the security check parties based on their inquiry priorities to obtain an initial inquiry sequence.

[0185] The second sequence acquisition module 1010 is configured to adjust the initial query sequence based on the dependency relationship between the security check parties to obtain an adjusted query sequence; wherein the adjusted query sequence is used to specify the order in which security checks are requested from the security check parties.

[0186] In summary, the technical solution provided by the embodiments of the present application, by setting identification information in the security check results, can obtain information that the corresponding security check party has conducted a security check on the target payment process. Based on this identification information, the security check party can implement idempotent operations for the target payment process, thereby allowing each security check party to use a unified idempotent mechanism to perform security checks on the payment process without having to set up their own internal idempotent mechanism, thereby reducing the complexity of information interaction and improving the efficiency of information interaction. In addition, when adding a new security check party, since there is no need to design a new idempotent mechanism, the difficulty and workload of the new security check party are reduced, thereby improving the access efficiency of the new security check party.

[0187] Please refer to Figure 12 , which shows a block diagram of a security inspection device provided by another embodiment of the present application. This device has the functionality to implement the aforementioned method examples. These functionality can be implemented by hardware or by hardware executing corresponding software. This device can be a server or be located within a server. This device 1200 may include: an inspection request receiving module 1201, an inspection result generating module 1202, and a result sending module 1203.

[0188] The inspection request receiving module 1201 is used to receive a first security inspection request from a server; wherein, the first security inspection request is used to request a first security inspection party to perform a security inspection task for a target payment process.

[0189] The inspection result generation module 1202 is used to generate a first security inspection result when the target payment process fails the inspection; wherein, the first security inspection result is used to indicate that the target payment process fails the inspection, and the first security inspection result includes first identification information, and the first identification information is used to indicate that the first security inspection party has performed the security inspection task for the target payment process.

[0190] The result sending module 1203 is configured to send the first security check result to the server.

[0191] In an exemplary embodiment, the first identification information includes a first checker identifier and a first idempotent identifier; wherein the first checker identifier is used to globally uniquely identify the first security checker, and the first idempotent identifier is used to globally uniquely identify the first security check result.

[0192] In an exemplary embodiment, the inspection result generating module 1202 is further configured to generate a second security inspection result when the target payment process passes the inspection, wherein the second security inspection result is configured to indicate that the target payment process passes the inspection.

[0193] The result sending module 1203 is further configured to send the second security check result to the server.

[0194] In an exemplary embodiment, the check request receiving module 1201 is further configured to obtain a secondary security check request from the server, where the secondary security check request includes the first idempotent identifier.

[0195] The result sending module 1203 is also used to send a third security check result to the server in response to detecting that the data repository includes the first idempotent identifier, and the third security check result is used to indicate that the security check result of the target security check party for the target payment process has been displayed.

[0196] In summary, the technical solution provided by the embodiments of the present application, by setting identification information in the security check results, can obtain information that the corresponding security check party has conducted a security check on the target payment process. Based on this identification information, the security check party can implement idempotent operations for the target payment process, thereby allowing each security check party to use a unified idempotent mechanism to perform security checks on the payment process without having to set up their own internal idempotent mechanism, thereby reducing the complexity of information interaction and improving the efficiency of information interaction. In addition, when adding a new security check party, since there is no need to design a new idempotent mechanism, the difficulty and workload of the new security check party are reduced, thereby improving the access efficiency of the new security check party.

[0197] Please refer to Figure 13 , which shows a block diagram of a security inspection device provided by another embodiment of the present application. This device has the functionality to implement the aforementioned method examples. These functionality can be implemented by hardware or by hardware executing corresponding software. This device can be a terminal or be incorporated into a terminal. This device 1300 may include: a payment interface display module 1301, a payment request sending module 1302, an inspection result acquisition module 1303, and a prompt interface display module 1304.

[0198] The payment interface display module 1301 is used to display a user payment interface, where the user payment interface includes a first payment control for initiating a target payment process.

[0199] The payment request sending module 1302 is used to send an initial payment request for the target payment process to the server in response to the triggering operation for the first payment control.

[0200] The result receiving module 1303 is used to receive a first security check result from the server; wherein, the first security check result is used to indicate that the target payment process has failed the inspection, and the first security check result includes first identification information, and the first identification information is used to indicate that the first security check party has performed a security check task for the target payment process.

[0201] The prompt interface display module 1304 is used to display a first security prompt interface, where the first security prompt interface includes security prompt information determined based on the first security check result.

[0202] In an exemplary embodiment, the first identification information includes a first policy identifier and a first idempotent identifier, the first checker identifier is used to globally uniquely identify the first security checker, and the first idempotent identifier is used to globally uniquely identify the first security check result.

[0203] In an exemplary embodiment, the first security prompt interface includes a second payment control:

[0204] The payment request sending module 1302 is further configured to send a payment continuation request for the target payment process to the server in response to a triggering operation on the second payment control, wherein the payment continuation request includes the first checking party identifier and the first idempotent identifier.

[0205] In summary, the technical solution provided by the embodiments of the present application, by setting identification information in the security check results, can obtain information that the corresponding security check party has conducted a security check on the target payment process. Based on this identification information, the security check party can implement idempotent operations for the target payment process, thereby allowing each security check party to use a unified idempotent mechanism to perform security checks on the payment process without having to set up their own internal idempotent mechanism, thereby reducing the complexity of information interaction and improving the efficiency of information interaction. In addition, when adding a new security check party, since there is no need to design a new idempotent mechanism, the difficulty and workload of the new security check party are reduced, thereby improving the access efficiency of the new security check party.

[0206] It should be noted that the apparatus provided in the above embodiments, when implementing its functions, is only illustrated by the division of the above functional modules. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the content structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus and method embodiments provided in the above embodiments are based on the same concept. The specific implementation process is detailed in the method embodiment and will not be repeated here.

[0207] Please refer to Figure 14 , which shows a block diagram of the structure of a terminal 1400 provided in one embodiment of the present application. The terminal 1400 may be the terminal described above. The terminal 1400 may be used to implement the above-mentioned terminal-side security inspection method. Specifically:

[0208] Typically, the terminal 1400 includes a processor 1401 and a memory 1402 .

[0209] The processor 1401 may include one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor 1401 may be implemented in at least one hardware form of DSP (Digital Signal Processing), FPGA (Field Programmable Gate Array), or PLA (Programmable Logic Array). The processor 1401 may also include a main processor and a coprocessor. The main processor is a processor for processing data in the awake state, also known as a CPU (Central Processing Unit); the coprocessor is a low-power processor for processing data in the standby state. In some embodiments, the processor 1401 may be integrated with a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the display screen. In some embodiments, the processor 1401 may also include an AI (Artificial Intelligence) processor, which is used to process computing operations related to machine learning.

[0210] Memory 1402 may include one or more computer-readable storage media, which may be non-transitory. Memory 1402 may also include high-speed random access memory and non-volatile memory, such as one or more disk storage devices or flash memory storage devices. In some embodiments, the non-transitory computer-readable storage medium in memory 1402 is used to store a computer program, which is configured to be executed by one or more processors to implement the terminal-side security inspection method described above.

[0211] In some embodiments, terminal 1400 may optionally include a peripheral device interface 1403 and at least one peripheral device. Processor 1401, memory 1402, and peripheral device interface 1403 may be connected via a bus or signal lines. Each peripheral device may be connected to peripheral device interface 1403 via a bus, signal lines, or circuit boards. Specifically, the peripheral device may include at least one of a radio frequency circuit 1404, a display screen 1405, a camera assembly 1406, an audio circuit 1407, a positioning assembly 1408, and a power supply 1409.

[0212] Those skilled in the art will understand that Figure 14 The structure shown in the figure does not constitute a limitation on the terminal 1400, and the terminal 1400 may include more or fewer components than shown in the figure, or combine certain components, or adopt a different component arrangement.

[0213] Please refer to Figure 15 , which shows a structural block diagram of a server provided in one embodiment of the present application. The server can be used to implement the server-side security inspection method provided in the above embodiment. Specifically:

[0214] The server 1500 includes a central processing unit (CPU, central processing unit), GPU (graphics processing unit), and FPGA (field programmable gate array) 1501, a system memory 1504 including RAM (random-access memory) 1502 and ROM (read-only memory) 1503, and a system bus 1505 connecting the system memory 1504 and the CPU 1501. The server 1500 also includes a basic input / output system (I / O system) 1506 for facilitating information transfer between various components within the server, and a mass storage device 1507 for storing an operating system 1513, application programs 1514, and other program modules 1515.

[0215] The basic input / output system 1506 includes a display 1508 for displaying information and an input device 1509 such as a mouse and keyboard for user input. Both the display 1508 and the input device 1509 are connected to the central processing unit 1501 via an input / output controller 1510 connected to the system bus 1505. The basic input / output system 1506 may also include an input / output controller 1510 for receiving and processing input from a variety of other devices such as a keyboard, mouse, or electronic stylus. Similarly, the input / output controller 1510 also provides output to a display screen, printer, or other types of output devices.

[0216] The mass storage device 1507 is connected to the central processing unit 1501 via a mass storage controller (not shown) connected to the system bus 1505. The mass storage device 1507 and its associated computer-readable media provide non-volatile storage for the server 1500. In other words, the mass storage device 1507 may include a computer-readable medium (not shown) such as a hard disk or a CD-ROM (Compact Disc Read-Only Memory) drive.

[0217] Without loss of generality, the computer-readable medium may include computer storage media and communication media. Computer storage media include volatile and non-volatile, removable and non-removable media implemented by any method or technology for storing information such as computer-readable instructions, data structures, program modules or other data. Computer storage media include RAM, ROM, EPROM (Erasable Programmable Read-Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), flash memory or other solid-state storage technology, CD-ROM, DVD (Digital Video Disc) or other optical storage, tape cassettes, magnetic tape, disk storage or other magnetic storage devices. Of course, those skilled in the art will appreciate that the computer storage media is not limited to the above-mentioned ones. The above-mentioned system memory 1504 and mass storage device 1507 can be collectively referred to as memory.

[0218] According to an embodiment of the present application, the server 1500 may also be connected to a remote computer on a network such as the Internet for operation. That is, the server 1500 may be connected to the network 1512 via the network interface unit 1511 connected to the system bus 1505. Alternatively, the network interface unit 1511 may be used to connect to other types of networks or remote computer systems (not shown).

[0219] The memory also includes a computer program, which is stored in the memory and configured to be executed by one or more processors to implement the above-mentioned server-side security checking method.

[0220] In an exemplary embodiment, a computer-readable storage medium is also provided, in which at least one instruction, at least one program, a code set or an instruction set is stored. When the at least one instruction, the at least one program, the code set or the instruction set is executed by the processor of the terminal, the terminal-side security inspection method mentioned above is implemented.

[0221] In an exemplary embodiment, a computer-readable storage medium is also provided, in which at least one instruction, at least one program, a code set or an instruction set is stored. When the at least one instruction, the at least one program, the code set or the instruction set is executed by the processor of the server, the above-mentioned server-side security check method is implemented.

[0222] Optionally, the computer-readable storage medium may include: ROM (Read-Only Memory), RAM (Random-Access Memory), SSD (Solid State Drives), or an optical disk, etc. Among them, the random access memory may include ReRAM (Resistance Random Access Memory) and DRAM (Dynamic Random Access Memory).

[0223] In an exemplary embodiment, a computer program product or computer program is also provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a terminal reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the terminal to perform the terminal-side security check method described above.

[0224] In an exemplary embodiment, a computer program product or computer program is also provided, comprising computer instructions stored in a computer-readable storage medium. A server processor reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the server to perform the above-described server-side security check method.

[0225] It should be understood that the "multiple" mentioned in this article refers to two or more. "And / or" describes the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can represent three situations: A exists alone, A and B exist at the same time, and B exists alone. The character " / " generally indicates that the previous and subsequent associated objects are in an "or" relationship. In addition, the step numbers described in this article only illustrate a possible execution sequence between the steps. In some other embodiments, the above steps may not be executed in the order of the numbers, such as two steps with different numbers are executed at the same time, or two steps with different numbers are executed in the opposite order to the diagram. The embodiments of the present application do not limit this.

[0226] Those skilled in the art will understand that all or part of the steps to implement the above embodiments may be accomplished by hardware, or by a program to instruct the relevant hardware, and the program may be stored in a computer-readable storage medium, which may be a read-only memory, a disk, or an optical disk, etc.

[0227] The above description is merely an exemplary embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application shall be included in the scope of protection of the present application.

Claims

1. A security inspection method, characterized in that: The method comprises: Receive an initial payment request from a client for a target payment process; Sending a first security check request to a first security checker in the security checker cluster, where the first security check request is used to request the first security checker to perform a security check task for the target payment process; Receive a first security check result fed back by the first security checker; wherein the first security check result is used to indicate that the target payment process has failed the check, and the first security check result includes first identification information, the first identification information is used to indicate that the first security checker has performed a security check task for the target payment process, and the first identification information includes a first checker identifier and a first idempotent identifier, the first checker identifier is used to globally uniquely identify the first security checker, and the first idempotent identifier is used to globally uniquely identify the first security check result; Send the first security check result to the client.

2. The method according to claim 1, characterized in that After sending the first security check result to the client, the method further includes: receiving a payment continuation request for the target payment process from the client, wherein the payment continuation request includes the first checking party identifier and the first idempotent identifier; Based on the first checker identifier, sending a secondary security check request to the first security checker, wherein the secondary security check request includes the first idempotent identifier; receiving a third security check result fed back by the first security checker, wherein the third security check result is used to indicate that the security check result of the first security checker on the target payment process has been displayed; Sending a third security check request to a second security checker in the security checker cluster according to the third security check result, wherein the third security check request is used to request the second security checker to perform a security check task for the target payment process; After all security check parties in the security check party cluster have performed the security check task for the target payment process, a deduction process for the target payment process is performed.

3. The method according to claim 1, characterized in that After sending the first security check result to the client, the method further includes: receiving a payment continuation request for the target payment process from the client, wherein the payment continuation request includes the first checking party identifier and the first idempotent identifier; Determining, based on the first checker identifier and the first idempotent identifier, that a security check result of the target payment process by the first security checker has been displayed; Sending a third security check request to a second security checker in the security checker cluster, wherein the third security check request is used to request the second security checker to perform a security check task for the target payment process; After all security check parties in the security check party cluster have performed the security check task for the target payment process, a deduction process for the target payment process is performed.

4. The method according to claim 1, wherein After sending the first security check request to the first security checker in the security checker cluster, the method further includes: Upon receiving the first security check result fed back by the first security checker, stopping sending security check requests to a security checker next to the first security checker in the security checker cluster; or, Upon receiving the second security check result fed back by the first security checker, a security check request is sent to the next security checker of the first security checker in the security checker cluster, where the second security check result is used to indicate that the target payment process has passed the check.

5. The method according to claim 1, wherein The method further comprises: Obtaining the query priority of each security checker included in the security checker cluster and the dependency relationship between the security checkers, wherein the query priority is determined by the security level of the security checker; Sorting the security check parties based on their inquiry priorities to obtain an initial inquiry sequence; The initial inquiry sequence is adjusted based on the dependency relationship between the various security check parties to obtain an adjusted inquiry sequence; wherein the adjusted inquiry sequence is used to specify the order in which security checks are requested from the various security check parties.

6. A safety inspection method, characterized in that: The method comprises: Receiving a first security check request from a server; wherein the first security check request is used to request a first security check party to perform a security check task for a target payment process; If the target payment process fails the inspection, a first security inspection result is generated; wherein the first security inspection result is used to indicate that the target payment process fails the inspection, and the first security inspection result includes first identification information, the first identification information is used to indicate that the first security inspection party has performed the security inspection task for the target payment process, and the first identification information includes a first inspection party identifier and a first idempotent identifier, the first inspection party identifier is used to globally uniquely identify the first security inspection party, and the first idempotent identifier is used to globally uniquely identify the first security inspection result; Send the first security check result to the server.

7. The method according to claim 6, characterized in that After receiving the first security check request from the server, the method further includes: If the target payment process passes the check, generating a second security check result, where the second security check result is used to indicate that the target payment process passes the check; Send the second security check result to the server.

8. The method according to claim 6, characterized in that The method further comprises: Obtaining a secondary security check request from the server, where the secondary security check request includes the first idempotent identifier; In response to detecting that the data repository includes the first idempotent identifier, a third security check result is sent to the server, where the third security check result is used to indicate that the security check result of the target security check party on the target payment process has been displayed.

9. A safety inspection method, characterized in that: The method comprises: Displaying a user payment interface, wherein the user payment interface includes a first payment control for initiating a target payment process; In response to a triggering operation on the first payment control, sending an initial payment request for the target payment process to a server; receiving a first security check result from the server; wherein the first security check result is used to indicate that the target payment process has failed the check, the first security check result includes first identification information, the first identification information is used to indicate that a first security checker has performed a security check task for the target payment process, the first identification information includes a first checker identifier and a first idempotent identifier, the first checker identifier is used to globally uniquely identify the first security checker, and the first idempotent identifier is used to globally uniquely identify the first security check result; A first security prompt interface is displayed, where the first security prompt interface includes security prompt information determined based on the first security check result.

10. A safety inspection device, characterized in that: The device comprises: A payment request receiving module, configured to receive an initial payment request for a target payment process from a client; An inspection request sending module, configured to send a first security inspection request to a first security inspection party in the security inspection party cluster, wherein the first security inspection request is used to request the first security inspection party to perform a security inspection task for the target payment process; An inspection result receiving module, configured to receive a first security inspection result fed back by the first security inspection party; wherein the first security inspection result is used to indicate that the target payment process has failed the inspection, the first security inspection result includes first identification information, the first identification information is used to indicate that the first security inspection party has performed the security inspection task for the target payment process, the first identification information includes a first inspection party identifier and a first idempotent identifier, the first inspection party identifier is used to globally uniquely identify the first security inspection party, and the first idempotent identifier is used to globally uniquely identify the first security inspection result; The inspection result sending module is used to send the first security inspection result to the client.

11. A safety inspection device, characterized in that: The device comprises: A check request receiving module, configured to receive a first security check request from a server; wherein the first security check request is used to request a first security check party to perform a security check task for a target payment process; An inspection result generation module is configured to generate a first security inspection result if the target payment process fails the inspection; wherein the first security inspection result is used to indicate that the target payment process fails the inspection, and the first security inspection result includes first identification information, the first identification information is used to indicate that the first security inspection party has performed the security inspection task for the target payment process, and the first identification information includes a first inspection party identifier and a first idempotent identifier, the first inspection party identifier is used to globally uniquely identify the first security inspection party, and the first idempotent identifier is used to globally uniquely identify the first security inspection result; A result sending module is used to send the first security check result to the server.

12. A safety inspection device, characterized in that: The device comprises: A payment interface display module, configured to display a user payment interface, wherein the user payment interface includes a first payment control for initiating a target payment process; a payment request sending module, configured to send an initial payment request for the target payment process to a server in response to a triggering operation on the first payment control; A result receiving module, configured to receive a first security check result from the server; wherein the first security check result is used to indicate that the target payment process has failed the check, the first security check result includes first identification information, the first identification information is used to indicate that a first security check party has performed a security check task for the target payment process, the first identification information includes a first check party identifier and a first idempotent identifier, the first check party identifier is used to globally uniquely identify the first security check party, and the first idempotent identifier is used to globally uniquely identify the first security check result; The prompt interface display module is used to display a first security prompt interface, wherein the first security prompt interface includes security prompt information determined based on the first security check result.

13. A computer device, characterized in that: The computer device includes a processor and a memory, wherein the memory stores at least one instruction, and the at least one instruction is loaded and executed by the processor to implement the security inspection method according to any one of claims 1 to 5, or the security inspection method according to any one of claims 6 to 8, or the security inspection method according to claim 9.

14. A computer-readable storage medium, characterized in that The storage medium stores at least one instruction, which is loaded and executed by the processor to implement the security inspection method according to any one of claims 1 to 5, or the security inspection method according to any one of claims 6 to 8, or the security inspection method according to claim 9.

15. A computer program product, characterized in that The computer program product includes computer instructions, which are stored in a computer-readable storage medium. The processor reads and executes the computer instructions from the computer-readable storage medium to implement the security inspection method according to any one of claims 1 to 5, or the security inspection method according to any one of claims 6 to 8, or the security inspection method according to claim 9.

Images