Transaction request checking method and related device

Abstract

The invention discloses a transaction request verification method and a related device, and the method comprises the steps: carrying out the analysis and verification of a transaction request message according to the verification parameter configuration, and obtaining the values of a channel parameter and a transaction parameter set; querying risk level configuration according to the values of the channel parameters and the transaction parameter set to obtain a risk level; if the risk level reaches a first risk level range, matching verification strategy configuration according to the value of the transaction parameter set and the risk level to obtain a verification strategy; generating a verification transaction according to the verification strategy and the channel parameters, and returning the verification transaction to the front end; after the transaction verification parameter returned by the front end is received, verifying the transaction verification parameter according to the verification strategy; and if the transaction verification parameter passes verification, forwarding the transaction request message to a corresponding back-end server for processing. Before the transaction is processed, the transaction request message is verified in multiple modes, original codes do not need to be modified in the development process, the development efficiency is high, and the verification modes are multiple and reliable.

Description

Technical Field

[0001] The present invention relates to the field of online transactions, and in particular to a transaction request verification method and related devices. Background Art

[0002] As the digital transformation of enterprises accelerates and the pace of online operations quickens, online has become the main channel for customers. When enterprises sell coupons, train tickets, and commemorative coins, they will attract both normal customers and uninvited guests such as scalpers and freeloaders. Enterprises need to identify online requests and prohibit abnormal requests initiated by scalpers and freeloaders.

[0003] At present, business personnel need to design relevant verification requirements such as picture verification codes and mobile phone verification codes, and developers need to write relevant functional codes and update the original business transaction process to realize the verification of customer requests in the business process, so as to identify abnormal requests initiated by scalpers and wool parties. The verification function is fixed in a certain business process and is easy to be bypassed. For example, if a picture verification code is added to the login process and the purchase process is not set, the system will not be able to verify the request after login. When adding a new request verification function, the front-end application needs to add additional verification page display logic. The back-end service needs to add code logic for the double verification code of specific verification parameters and verification credentials, which requires invading the existing business logic, modifying the original business code, and performing additional development and testing work, resulting in low development efficiency. Summary of the invention

[0004] In view of the above problems, the present invention provides a transaction request verification method and related devices that overcome the above problems or at least partially solve the above problems.

[0005] In a first aspect, a transaction request verification method includes:

[0006] According to the pre-configured verification parameter configuration, the transaction request message is parsed and verified to obtain the corresponding channel parameter and transaction parameter set values;

[0007] According to the values ​​of the channel parameter and the transaction parameter set, query the pre-configured risk level configuration to obtain the corresponding risk level;

[0008] If the risk level reaches a preset first risk level range, then according to the value of the transaction parameter set and the risk level, a pre-configured verification strategy configuration is matched to obtain a corresponding verification strategy;

[0009] According to the verification strategy and the channel parameters, dynamically generate a verification transaction corresponding to the verification strategy and return the verification transaction to the front end, so that the front end returns a transaction verification parameter for the verification transaction;

[0010] After receiving the transaction verification parameters returned by the front end, verify the transaction verification parameters according to the verification strategy;

[0011] If the transaction verification parameters pass the verification, the transaction request message is forwarded to the corresponding backend server for processing.

[0012] Optionally, in some optional implementations, parsing and verifying the transaction request message according to the pre-configured verification parameter configuration to obtain the values ​​of the corresponding channel parameters and transaction parameter sets includes:

[0013] According to the message format parameters in the verification parameter configuration, call the corresponding message parsing class;

[0014] Use the message parsing class to parse the transaction request message to obtain corresponding message fields;

[0015] According to the message field, query the value of the parameter corresponding to the message field name in the verification parameter configuration, wherein the value of the parameter includes the value of the channel parameter and the value of the transaction parameter set.

[0016] Optionally, in some optional implementations, querying a pre-configured risk level configuration according to the values ​​of the channel parameter and the transaction parameter set to obtain a corresponding risk level includes:

[0017] According to the values ​​of the channel parameters and the values ​​of the transaction parameter set, the pre-configured risk level configuration is queried to obtain the corresponding risk level, wherein the risk level configuration establishes a corresponding relationship between the value range of the channel parameters, the value range of the transaction parameter set and the risk level.

[0018] Optionally, in certain optional implementations, after querying a pre-configured risk level configuration according to the values ​​of the channel parameter and the transaction parameter set to obtain a corresponding risk level, the method further includes:

[0019] If the risk level reaches a preset second risk level range, the transaction request message is forwarded to the corresponding back-end server for processing, and the processing result is forwarded to the front-end.

[0020] Optionally, in some optional implementations, if the risk level reaches a preset first risk level range, a pre-configured verification strategy configuration is matched according to the value of the transaction parameter set and the risk level to obtain a corresponding verification strategy, including:

[0021] If the risk level reaches a preset first risk level range, a verification strategy corresponding to the transaction request message is matched from a preset verification strategy configuration according to the value of the transaction parameter set and the risk level, wherein the verification strategy includes: a verification method and a verification rule.

[0022] Optionally, in some optional implementations, dynamically generating a verification transaction corresponding to the verification strategy according to the verification strategy and the channel parameter and returning the verification transaction to the front end, so that the front end returns a transaction verification parameter for the verification transaction, includes:

[0023] Find the corresponding front-end environment according to the verification method of the inspection strategy and the client version information in the channel parameters;

[0024] Dynamically generate a verification transaction of the verification method according to the front-end environment;

[0025] The verification transaction is returned to the front end, so that the front end returns a transaction verification parameter for the verification transaction, wherein the transaction verification parameter includes at least one of a graphic verification code, fingerprint recognition data, and face recognition data.

[0026] Optionally, in some optional implementations, after receiving the transaction verification parameter returned by the front end, verifying the transaction verification parameter according to the verification strategy includes:

[0027] After receiving the transaction verification parameters returned by the front end, the corresponding transaction verification parameters are verified according to the verification method in the verification strategy, wherein the verification method includes: picture verification code verification, SMS verification code verification, slider verification, fingerprint verification and face recognition verification.

[0028] Optionally, in some optional implementations, after receiving the transaction verification parameter returned by the front end and verifying the transaction verification parameter according to the verification strategy, the method further includes:

[0029] If the transaction verification parameter fails to pass the verification, the transaction request message is prevented from being sent to the back-end server, and a message rejecting the request is returned to the front-end.

[0030] In a second aspect, a transaction request verification device includes: a message parsing unit, a risk level query unit, a verification strategy matching unit, a verification transaction generation unit, a verification parameter verification unit, and a transaction forwarding processing unit;

[0031] The message parsing unit is used to parse and verify the transaction request message according to the pre-configured verification parameter configuration to obtain the corresponding channel parameter and transaction parameter set values;

[0032] The risk level query unit is used to query the pre-configured risk level configuration according to the values ​​of the channel parameter and the transaction parameter set to obtain the corresponding risk level;

[0033] The verification strategy matching unit is used to match the pre-configured verification strategy configuration according to the value of the transaction parameter set and the risk level to obtain the corresponding verification strategy if the risk level reaches a preset first risk level range;

[0034] The verification transaction generation unit is used to dynamically generate a verification transaction corresponding to the verification strategy according to the verification strategy and the channel parameter and return the verification transaction to the front end, so that the front end returns a transaction verification parameter for the verification transaction;

[0035] The verification parameter verification unit is used to verify the transaction verification parameter according to the verification strategy after receiving the transaction verification parameter returned by the front end;

[0036] The transaction forwarding processing unit is used to forward the transaction request message to the corresponding backend server for processing if the transaction verification parameter passes the verification.

[0037] In a third aspect, an electronic device comprises at least one processor, and at least one memory and a bus connected to the processor; wherein the processor and the memory communicate with each other via the bus; and the processor is used to call program instructions in the memory to execute any of the transaction request verification methods described above.

[0038] By means of the above technical scheme, a transaction request verification method and related device provided by the present invention can parse and verify the transaction request message according to the pre-configured verification parameter configuration, and obtain the corresponding channel parameter and transaction parameter set values; according to the channel parameter and the transaction parameter set values, query the pre-configured risk level configuration to obtain the corresponding risk level; if the risk level reaches the preset first risk level range, match the pre-configured verification strategy configuration according to the transaction parameter set value and the risk level to obtain the corresponding verification strategy; according to the verification strategy and the channel parameter, dynamically generate the verification transaction corresponding to the verification strategy and return the verification transaction to the front end, so that the front end returns the transaction verification parameter for the verification transaction; after receiving the transaction verification parameter returned by the front end, verify the transaction verification parameter according to the verification strategy; if the transaction verification parameter passes the verification, forward the transaction request message to the corresponding back-end server for processing. It can be seen from this that the present invention verifies the transaction request message in multiple ways before processing the transaction, and the original code does not need to be modified during the development process. The development efficiency is high and the verification method is multiple, which is relatively reliable.

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

[0040] Various other advantages and benefits will become apparent to those of ordinary skill in the art by reading the detailed description of the preferred embodiments below. The accompanying drawings are only for the purpose of illustrating the preferred embodiments and are not to be considered as limiting the present invention. Moreover, the same reference symbols are used throughout the accompanying drawings to represent the same components. In the accompanying drawings:

[0041] Figure 1 A flow chart of a transaction request verification method provided by the present invention is shown;

[0042] Figure 2 A structural diagram of a transaction request verification system provided by the present invention is shown;

[0043] Figure 3 A timing diagram of a transaction request verification method provided by the present invention is shown;

[0044] Figure 4 A schematic diagram showing the structure of a transaction request verification device provided by the present invention is shown;

[0045] Figure 5 A structural schematic diagram of an electronic device provided by the present invention is shown. DETAILED DESCRIPTION

[0046] As the digital transformation of enterprises accelerates and the pace of online operations quickens, online has become the main channel for customers. When enterprises sell coupons, train tickets, and commemorative coins, they will attract both normal customers and uninvited guests such as scalpers and freeloaders. Enterprises need to identify online requests and prohibit abnormal requests initiated by scalpers and freeloaders.

[0047] At present, business personnel need to design relevant verification requirements such as picture verification codes and mobile phone verification codes, and developers need to write relevant functional codes and update the original business transaction process to realize verification of customer requests in the business process, so as to identify abnormal requests initiated by scalpers and wool parties. The verification function is fixed in a certain business process and is easy to be bypassed. For example, if a picture verification code is added to the login process and it is not set in the purchase process, the system will not be able to verify the request after login. The inventor of this solution has found through research that when adding a new request verification function to the existing technology, it is necessary to modify the original business code, the entire production cycle is long, and it is impossible to quickly add a request verification function to a certain business. The business process after adding the verification function will increase the complexity of use for normal customers, the transaction process will become lengthy, and the customer transaction experience will be reduced.

[0048] 1. The existing technology requires the modification of front-end and back-end applications and cannot provide seamless injection. The front-end application needs to add additional verification page display logic. The back-end service needs to add code logic for double verification codes of specific verification parameters and verification credentials, which requires intrusion into the existing business logic and additional development and testing work.

[0049] 2. The existing technology has a fixed verification method, and it is impossible to dynamically add verification methods, and the ability to resist forged requests is insufficient. A double verification code verification rule is adopted to set specific verification parameters and verification credentials in advance. The verification parameters include: fixed terminal parameters (such as model), terminal operating system information, terminal Internet Protocol address and location information, etc. The verification credentials include verification codes, etc. Once these verification parameters and verification credentials are identified and vulnerabilities appear, attackers can forge related requests and successfully pass the double verification of verification codes. When the above verification logic is breached, if the verification logic needs to be replaced, such as changing the image verification code to other verification forms such as face recognition, the front-end and back-end programs need to be updated, and the timeliness is poor.

[0050] 3. The existing technology adds verification function to the business process, which will increase the complexity of normal customers. For example, users are required to enter a verification code every time, which makes the transaction process lengthy and reduces the customer transaction experience. For some non-critical transactions, such as purchases, after adding verification logic according to the above patent, users are required to enter a verification code every time they purchase goods, which reduces the customer transaction experience. However, if the verification code is not entered, it is difficult to identify whether it is an abnormal request initiated by the wool party. It is impossible to dynamically decide whether the customer request needs to be verified based on the current parameter situation.

[0051] The exemplary embodiments of the present invention will be described in more detail below with reference to the accompanying drawings. Although the exemplary embodiments of the present invention are shown in the accompanying drawings, it should be understood that the present invention can be implemented in various forms and should not be limited by the embodiments set forth herein. On the contrary, these embodiments are provided in order to enable a more thorough understanding of the present invention and to enable the scope of the present invention to be fully communicated to those skilled in the art.

[0052] like Figure 1 As shown, the present invention provides a transaction request verification method, including: S100, S200, S300, S400, S500 and S600;

[0053] S100, according to the pre-configured verification parameter configuration, the transaction request message is parsed and verified to obtain the corresponding channel parameter and transaction parameter set values;

[0054] For example, in some optional embodiments, the S100 includes: step 1.1, step 1.2 and step 1.3;

[0055] Step 1.1, according to the message format parameters in the verification parameter configuration, call the corresponding message parsing class;

[0056] Step 1.2: Use the message parsing class to parse the transaction request message to obtain the corresponding message fields;

[0057] Step 1.3: According to the message field, query the value of the parameter corresponding to the message field name in the verification parameter configuration, wherein the value of the parameter includes the value of the channel parameter and the value of the transaction parameter set.

[0058] Optionally, the present invention may pre-configure the verification parameter configuration of the transaction request message, including: channel parameters, message field names and message formats corresponding to the transaction parameters, etc., and the present invention does not impose any limitation on this.

[0059] Optionally, the channel parameters may include: client type, version number, calling channel, location information and IP, etc., which are not limited in the present invention.

[0060] Optionally, the transaction parameters may include: transaction code, transaction type, customer ID, transaction frequency and timestamp, etc., which are not limited in the present invention.

[0061] Optionally, the message format may include: Json format, Xml format and custom format, etc., which is not limited in the present invention.

[0062] S200, querying a pre-configured risk level configuration according to the values ​​of the channel parameter and the transaction parameter set to obtain a corresponding risk level;

[0063] For example, in some optional embodiments, the S200 includes: step 2.1;

[0064] Step 2.1: According to the values ​​of the channel parameters and the values ​​of the transaction parameter set, query the pre-configured risk level configuration to obtain the corresponding risk level, wherein the risk level configuration establishes a corresponding relationship between the value range of the channel parameters, the value range of the transaction parameter set and the risk level.

[0065] Optionally, the present invention may pre-configure the value ranges and risk levels corresponding to the channel parameters and transaction parameters as the risk level configuration, wherein the transaction parameter set includes multiple transaction parameters, and the present invention does not impose any limitation on this.

[0066] Optionally, the transaction risk level may be: high risk, medium risk and low risk. Of course, the present invention may also divide the transaction risk levels into different levels according to actual needs, and the present invention does not limit this.

[0067] Optionally, as mentioned above, channel parameters may include: client type, channel network type, and location information. In the risk level configuration, the values ​​corresponding to the client type include: web browser, mobile client APP, windows client, API (Application Programming Interface), SDK (Software Development Kit), and WeChat applet. In the risk level configuration, the values ​​corresponding to the channel network type include: Internet and dedicated line. In the risk level configuration, the values ​​corresponding to the location information include: empty, same location, and different location.

[0068] Optionally, as mentioned above, the transaction parameters may include: transaction type, customer ID, transaction frequency, etc. In the risk level configuration, the values ​​corresponding to the transaction type include: user login class, user management class, financial transaction class, and financial account movement class, etc.

[0069] Optionally, in the risk level configuration, the rules corresponding to transactions at a high risk level (i.e., transaction request messages) include:

[0070] (1) The client type value is: web browser, API, SDK; the location information value is: different, empty; the transaction type value is: financial account type.

[0071] (2) The client type value is: mobile client APP, Windows client, WeChat applet; the location information value is: different, empty; the transaction type value is: financial account type; the transaction frequency value exceeds the configured threshold.

[0072] Optionally, in the risk level configuration, the rules corresponding to medium risk level transactions include:

[0073] (1) The client type value is: web browser API, SDK; the location information value is: same; the transaction type value is: financial transaction type, financial account type; the transaction frequency value exceeds the configured threshold.

[0074] (2) The client type value is: mobile client APP, windows client, WeChat applet; the location information value is: same; the transaction type value is: financial account type; the transaction frequency value exceeds the configured threshold.

[0075] Optionally, for transactions at a low risk level, no subsequent verification is performed, so there is no need to set corresponding rules, and the present invention does not impose any limitation on this.

[0076] Optionally, in some optional embodiments, after S200, the method further includes: step 3.1;

[0077] Step 3.1: If the risk level reaches a preset second risk level range, the transaction request message is forwarded to the corresponding back-end server for processing, and the processing result is forwarded to the front-end.

[0078] Optionally, the second risk level range mentioned here can be understood as the aforementioned low risk level, and the present invention is not limited to this.

[0079] S300: If the risk level reaches a preset first risk level range, matching a pre-configured verification strategy configuration according to the value of the transaction parameter set and the risk level to obtain a corresponding verification strategy;

[0080] For example, in some optional embodiments, the S300 includes: step 4.1;

[0081] Step 4.1: If the risk level reaches a preset first risk level range, match the verification strategy corresponding to the transaction request message from a preset verification strategy configuration according to the value of the transaction parameter set and the risk level, wherein the verification strategy includes: verification mode and verification rules.

[0082] Optionally, the present invention may pre-configure verification strategies corresponding to transaction parameters and risk levels as verification strategy configuration, and the present invention does not impose any limitation on this.

[0083] Optionally, the verification strategy may include: verification method and verification rule. The values ​​corresponding to the verification method include: picture verification code, SMS verification code, slider verification, fingerprint verification, and face recognition, etc. The values ​​corresponding to the verification rule include: equality (corresponding to picture verification code, SMS verification code, slider verification, and fingerprint verification) and face recognition threshold (corresponding to face recognition), etc.

[0084] S400, dynamically generating a verification transaction corresponding to the verification strategy according to the verification strategy and the channel parameter and returning the verification transaction to the front end, so that the front end returns a transaction verification parameter for the verification transaction;

[0085] For example, in some optional embodiments, the S400 includes: step 5.1, step 5.2 and step 5.3;

[0086] Step 5.1, according to the verification method of the inspection strategy and the client version information in the channel parameters, find the corresponding front-end environment;

[0087] Step 5.2, dynamically generating a verification transaction of the verification method according to the front-end environment;

[0088] Step 5.3: Return the verification transaction to the front end, so that the front end returns transaction verification parameters for the verification transaction, wherein the transaction verification parameters include: at least one of a graphic verification code, fingerprint recognition data, and face recognition data.

[0089] When the transaction request message is judged to be at a medium risk level or a high risk level, the present invention can search for the corresponding front-end environment (which can also be understood as a front-end framework) according to the verification method of the verification strategy and the client version information in the channel parameters, including: H5, Vue, Tauri-Vue, JQuery and Electron, and then dynamically generate the H5 code of the verification method of the verification strategy as a verification transaction, including: pictures, input boxes, fingerprints and camera devices calling js code, and finally return it to the front end to display the verification transaction.

[0090] It should be noted that the specific way to dynamically generate H5 code is: according to the front-end framework, select a specific From form object. Taking the Vue framework as an example, use the From form of ElementUI. Dynamically add multiple <el-form-item>It is used to place various types of form controls to display various interface elements, including input boxes, selectors, and JS controls, etc., for displaying pictures, entering verification codes, and SMS verification codes. It calls the local device interface to perform face recognition, fingerprint password input, etc. After receiving the verification transaction, the front end can remind the user to enter the verification parameters so that it can be returned to the execution subject of the present invention.

[0091] S500, after receiving the transaction verification parameters returned by the front end, verify the transaction verification parameters according to the verification strategy;

[0092] For example, in some optional embodiments, the S500 includes: step 6.1;

[0093] Step 6.1: After receiving the transaction verification parameters returned by the front end, verify the corresponding transaction verification parameters according to the verification method in the verification strategy, wherein the verification method includes: picture verification code verification, SMS verification code verification, slider verification, fingerprint verification and face recognition verification.

[0094] S600: If the transaction verification parameter passes the verification, the transaction request message is forwarded to a corresponding backend server for processing.

[0095] Optionally, in some optional implementations, after S500, the method further includes: step 7.1;

[0096] Step 7.1: If the transaction verification parameter fails to pass the verification, the transaction request message is prevented from being sent to the back-end server, and a message rejecting the request is returned to the front-end.

[0097] Optionally, the business management personnel can query the statistical results of the current transaction request message according to the transaction code and time, including: risk level, verification transaction volume, verification success rate and verification time, etc., and the present invention does not limit this.

[0098] Optionally, in order to further clarify the solution of the present invention, the present invention provides the following Figure 2 The system architecture diagram shown in Figure 3 The timing diagram shown in the figure can be understood by referring to the above explanation, and the present invention will not elaborate on it.

[0099] like Figure 4 As shown, the present invention provides a transaction request verification device, comprising: a message parsing unit 100, a risk level query unit 200, a verification strategy matching unit 300, a verification transaction generation unit 400, a verification parameter verification unit 500 and a transaction forwarding processing unit 600;

[0100] The message parsing unit 100 is used to parse and verify the transaction request message according to the pre-configured verification parameter configuration to obtain the corresponding channel parameter and transaction parameter set values;

[0101] The risk level query unit 200 is used to query the pre-configured risk level configuration according to the values ​​of the channel parameter and the transaction parameter set to obtain the corresponding risk level;

[0102] The verification strategy matching unit 300 is used to match the pre-configured verification strategy configuration according to the value of the transaction parameter set and the risk level to obtain the corresponding verification strategy if the risk level reaches a preset first risk level range;

[0103] The verification transaction generation unit 400 is used to dynamically generate a verification transaction corresponding to the verification strategy according to the verification strategy and the channel parameters and return the verification transaction to the front end, so that the front end returns a transaction verification parameter for the verification transaction;

[0104] The verification parameter verification unit 500 is used to verify the transaction verification parameter according to the verification strategy after receiving the transaction verification parameter returned by the front end;

[0105] The transaction forwarding processing unit 600 is used to forward the transaction request message to the corresponding backend server for processing if the transaction verification parameter passes the verification.

[0106] Optionally, in some optional implementations, the message parsing unit 100 includes: a parsing class calling subunit, a field parsing subunit and a value query subunit;

[0107] The parsing class calling subunit is used to call the corresponding message parsing class according to the message format parameters in the verification parameter configuration;

[0108] The field parsing subunit is used to parse the transaction request message using the message parsing class to obtain corresponding message fields;

[0109] The value query subunit is used to query the value of the parameter corresponding to the message field name in the verification parameter configuration according to the message field, wherein the value of the parameter includes the value of the channel parameter and the value of the transaction parameter set.

[0110] Optionally, in some optional implementations, the risk level query unit 200 includes: a risk level query subunit;

[0111] The risk level query subunit is used to query the pre-configured risk level configuration according to the value of the channel parameter and the value of the transaction parameter set to obtain the corresponding risk level, wherein the risk level configuration establishes a corresponding relationship between the value range of the channel parameter, the value range of the transaction parameter set and the risk level.

[0112] Optionally, the device further comprises: a direct processing unit;

[0113] The direct processing unit is used to, in certain optional embodiments, query the pre-configured risk level configuration according to the values ​​of the channel parameter and the transaction parameter set, and after obtaining the corresponding risk level, if the risk level reaches a preset second risk level range, forward the transaction request message to the corresponding back-end server for processing, and forward the processing result to the front end.

[0114] Optionally, in some optional implementations, the inspection strategy matching unit 300 includes: an inspection strategy matching subunit;

[0115] The verification strategy matching subunit is used to match the verification strategy corresponding to the transaction request message from a preset verification strategy configuration according to the value of the transaction parameter set and the risk level if the risk level reaches a preset first risk level range, wherein the verification strategy includes: a verification method and a verification rule.

[0116] Optionally, in some optional implementations, the verification transaction generation unit 400 includes: a front-end environment search subunit, a verification transaction generation subunit, and a verification transaction return subunit;

[0117] The front-end environment search subunit is used to search for the corresponding front-end environment according to the verification method of the inspection strategy and the client version information in the channel parameter;

[0118] The verification transaction generation subunit is used to dynamically generate a verification transaction of the verification mode according to the front-end environment;

[0119] The verification transaction returning subunit is used to return the verification transaction to the front end, so that the front end returns transaction verification parameters for the verification transaction, wherein the transaction verification parameters include: at least one of a graphic verification code, fingerprint recognition data and face recognition data.

[0120] Optionally, in certain optional implementations, the verification parameter verification unit 500 includes: a verification parameter verification subunit;

[0121] The verification parameter verification subunit is used to verify the corresponding transaction verification parameters according to the verification method in the verification strategy after receiving the transaction verification parameters returned by the front end, wherein the verification method includes: picture verification code verification, SMS verification code verification, slider verification, fingerprint verification and face recognition verification.

[0122] Optionally, in certain optional embodiments, the device further comprises: a prohibition processing unit;

[0123] The prohibition processing unit is used to, after receiving the transaction verification parameters returned by the front end and verifying the transaction verification parameters according to the verification strategy, prevent the transaction request message from being sent to the back-end server if the transaction verification parameters fail to pass the verification, and return a message rejecting the request to the front end.

[0124] The present invention provides a computer-readable storage medium on which a program is stored. When the program is executed by a processor, the transaction request verification method described in any one of the above items is implemented.

[0125] like Figure 5 As shown, the present invention provides an electronic device 70, which includes at least one processor 701, and at least one memory 702 and a bus 703 connected to the processor 701; wherein the processor 701 and the memory 702 communicate with each other through the bus 703; the processor 701 is used to call the program instructions in the memory 702 to execute any of the transaction request verification methods described above.

[0126] In the present invention, relational terms such as first and second, etc. are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "comprise", "include" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the statement "comprises a ..." does not exclude the presence of other identical elements in the process, method, article or device including the element.

[0127] Each embodiment in this specification is described in a related manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0128] The above description of the disclosed embodiments enables those skilled in the art to implement or use the present invention. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined in the present invention may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention will not be limited to the embodiments shown in the present invention, but will conform to the widest scope consistent with the principles and novel features disclosed in the present invention.

[0129] The above description is only a preferred embodiment of the present invention and is not intended to limit the protection scope of the present invention. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention are included in the protection scope of the present invention.

Claims

1. A transaction request verification method, characterized in that: include: According to the pre-configured verification parameter configuration, the transaction request message is parsed and verified to obtain the corresponding channel parameter and transaction parameter set values; According to the values ​​of the channel parameter and the transaction parameter set, query the pre-configured risk level configuration to obtain the corresponding risk level; If the risk level reaches a preset first risk level range, then according to the value of the transaction parameter set and the risk level, a pre-configured verification strategy configuration is matched to obtain a corresponding verification strategy; According to the verification strategy and the channel parameters, dynamically generate a verification transaction corresponding to the verification strategy and return the verification transaction to the front end, so that the front end returns a transaction verification parameter for the verification transaction; After receiving the transaction verification parameters returned by the front end, verify the transaction verification parameters according to the verification strategy; If the transaction verification parameters pass the verification, the transaction request message is forwarded to the corresponding backend server for processing.

2. The method according to claim 1, characterized in that The transaction request message is parsed and verified according to the pre-configured verification parameter configuration to obtain the corresponding channel parameter and transaction parameter set values, including: According to the message format parameters in the verification parameter configuration, call the corresponding message parsing class; Use the message parsing class to parse the transaction request message to obtain corresponding message fields; According to the message field, query the value of the parameter corresponding to the message field name in the verification parameter configuration, wherein the value of the parameter includes the value of the channel parameter and the value of the transaction parameter set.

3. The method according to claim 1, characterized in that The step of querying a pre-configured risk level configuration according to the values ​​of the channel parameter and the transaction parameter set to obtain a corresponding risk level includes: According to the values ​​of the channel parameters and the values ​​of the transaction parameter set, the pre-configured risk level configuration is queried to obtain the corresponding risk level, wherein the risk level configuration establishes a corresponding relationship between the value range of the channel parameters, the value range of the transaction parameter set and the risk level.

4. The method according to claim 1, characterized in that: After querying the pre-configured risk level configuration according to the values ​​of the channel parameter and the transaction parameter set to obtain the corresponding risk level, the method further includes: If the risk level reaches a preset second risk level range, the transaction request message is forwarded to the corresponding back-end server for processing, and the processing result is forwarded to the front-end.

5. The method according to claim 1, characterized in that If the risk level reaches a preset first risk level range, then according to the value of the transaction parameter set and the risk level, a pre-configured verification strategy configuration is matched to obtain a corresponding verification strategy, including: If the risk level reaches a preset first risk level range, a verification strategy corresponding to the transaction request message is matched from a preset verification strategy configuration according to the value of the transaction parameter set and the risk level, wherein the verification strategy includes: a verification method and a verification rule.

6. The method according to claim 5, characterized in that The dynamically generating a verification transaction corresponding to the verification strategy according to the verification strategy and the channel parameter and returning the verification transaction to the front end so that the front end returns a transaction verification parameter for the verification transaction, includes: Find the corresponding front-end environment according to the verification method of the inspection strategy and the client version information in the channel parameters; Dynamically generate a verification transaction of the verification method according to the front-end environment; The verification transaction is returned to the front end, so that the front end returns a transaction verification parameter for the verification transaction, wherein the transaction verification parameter includes: at least one of a graphic verification code, fingerprint recognition data, and face recognition data.

7. The method according to claim 1, characterized in that After receiving the transaction verification parameters returned by the front end, verifying the transaction verification parameters according to the verification strategy includes: After receiving the transaction verification parameters returned by the front end, the corresponding transaction verification parameters are verified according to the verification method in the verification strategy, wherein the verification method includes: picture verification code verification, SMS verification code verification, slider verification, fingerprint verification and face recognition verification.

8. The method according to claim 1, characterized in that After receiving the transaction verification parameter returned by the front end and verifying the transaction verification parameter according to the verification strategy, the method further includes: If the transaction verification parameter fails to pass the verification, the transaction request message is prevented from being sent to the back-end server, and a message rejecting the request is returned to the front-end.

9. A transaction request verification device, characterized in that: include: Message parsing unit, risk level query unit, inspection strategy matching unit, verification transaction generation unit, verification parameter verification unit and transaction forwarding processing unit; The message parsing unit is used to parse and verify the transaction request message according to the pre-configured verification parameter configuration to obtain the corresponding channel parameter and transaction parameter set values; The risk level query unit is used to query the pre-configured risk level configuration according to the values ​​of the channel parameter and the transaction parameter set to obtain the corresponding risk level; The verification strategy matching unit is used to match the pre-configured verification strategy configuration according to the value of the transaction parameter set and the risk level to obtain the corresponding verification strategy if the risk level reaches a preset first risk level range; The verification transaction generating unit is used to dynamically generate a verification transaction corresponding to the verification strategy according to the verification strategy and the channel parameter and return the verification transaction to the front end, so that the front end returns a transaction verification parameter for the verification transaction; The verification parameter verification unit is used to verify the transaction verification parameter according to the verification strategy after receiving the transaction verification parameter returned by the front end; The transaction forwarding processing unit is used to forward the transaction request message to the corresponding backend server for processing if the transaction verification parameter passes the verification.

10. An electronic device, characterized in that: The electronic device includes at least one processor, and at least one memory and a bus connected to the processor; wherein the processor and the memory communicate with each other via the bus; the processor is used to call program instructions in the memory to execute the transaction request verification method as described in any one of claims 1 to 8.

Images