Identity non-inductive verification method and device in weak network environment, medium and equipment

Abstract

The embodiment of the invention discloses a non-inductive identity verification method and device in a weak network environment, a medium and equipment, and the method comprises the steps: determining a payment scene recognition result when a payment verification request triggered by a payment terminal in the weak network environment is detected, determining a risk assessment result according to the payment scene recognition result, and carrying out the verification of the risk assessment result. Determining at least one semi-offline identity verification mode based on the payment scene recognition result and the risk assessment result; and performing identity verification on the payment terminal through a semi-offline identity verification mode, determining a semi-offline identity verification result and completing the payment verification request. According to the scheme, automatic identity verification of the equipment in the weak network environment can be realized, the verification process does not need user participation, the identity verification efficiency in the weak network environment is effectively improved, the non-inductive payment experience of the user is improved, meanwhile, the flexibility of the identity verification mode is improved in combination with the matched better semi-offline identity verification mode, and the user experience is improved. And the security of the transaction process is effectively ensured.

Description

Technical Field

[0001] This specification relates to the field of payment security technology, and particularly to an identity seamless verification method, device, medium, and equipment in a weak network environment. Background Art

[0002] With the popularization of mobile payment and the continuous expansion of application scenarios, the security and convenience of payment systems have become important challenges in the industry. Especially in the case of poor network environment or unstable network connection, the payment experience of users is often severely affected. Since traditional payment verification methods often rely on real-time network connection and remote verification, in the case of unstable network, the payment verification process is easily affected by delays and interruptions, and identity authentication cannot be completed in time, thus affecting the payment experience of users.

[0003] Currently, when dealing with complex payment scenarios in related payment verification systems, due to the complex and diverse payment scenarios, and the different device and network environments of users, traditional verification methods are difficult to provide personalized and efficient identity verification strategies when facing ever-changing payment scenarios. Especially in the case of large payment amounts or frequent payments, existing verification means are difficult to balance security and convenience, often resulting in unnecessary delays or cumbersome operations for users during the payment process. Although some payment systems try to improve security by strengthening identity verification, in a weak network environment, overly complex verification methods may increase the operation difficulty and further affect the user experience. Summary of the Invention

[0004] In the first aspect of the embodiments of the specification, an identity seamless verification method in a weak network environment is provided. This method can improve the efficiency of identity verification in a weak network environment, and enhance the fluency and security of the identity verification process. The method includes:

[0005] Respond to a payment verification request triggered when the payment terminal is in a weak network environment, and determine the payment scenario recognition result corresponding to the payment verification request;

[0006] Determine the risk assessment result of the payment verification request according to the payment scenario recognition result;

[0007] Determine at least one semi-offline identity verification method based on the payment scenario recognition result and the risk assessment result;

[0008] Authenticate the payment terminal through the semi-offline identity verification method to determine the semi-offline identity verification result, so as to complete the payment verification request through the semi-offline identity verification result.

[0009] Further, in some embodiments, determining at least one semi-offline authentication method based on the payment scenario recognition result and the risk assessment result includes:

[0010] Determine the scenario feature data of the payment scenario recognition result;

[0011] Match and determine candidate semi-offline authentication methods from a preset authentication support library according to the scenario feature data;

[0012] Filter the candidate semi-offline authentication methods based on the risk assessment result to obtain at least one semi-offline authentication method for verifying the payment terminal.

[0013] Further, in some embodiments, authenticating the payment terminal through the semi-offline authentication method includes:

[0014] Determine the verification method identification data corresponding to the semi-offline authentication method;

[0015] Call the authentication interface corresponding to the semi-offline authentication method according to the verification method identification data, so as to authenticate the payment terminal by calling the authentication logic through the authentication interface.

[0016] Further, in some embodiments, the semi-offline authentication method includes a time-synchronized one-time password authentication method. Authenticating the payment terminal by calling the authentication logic through the authentication interface corresponding to the time-synchronized one-time password authentication method includes:

[0017] Obtain the first time dynamic password included in the payment verification request, where the first time dynamic password is generated by the payment terminal based on a first timestamp, a preset time window, and a shared key;

[0018] Calculate a second time dynamic password according to the preset time window, the shared key, and the collected second timestamp;

[0019] Match and verify the first time dynamic password and the second time dynamic password, and determine the semi-offline authentication result through the match verification result.

[0020] Further, in some embodiments, calculating the second time dynamic password according to the preset time window, the shared key, and the collected second timestamp includes:

[0021] Determine the time window number according to the second timestamp and the preset time window;

[0022] Encrypt the shared key and the time window number, and calculate the second time-based dynamic password.

[0023] Further, in some embodiments, the matching and verifying the first time-based dynamic password and the second time-based dynamic password, and determining the semi-offline authentication result based on the matching verification result includes:

[0024] If the matching verification of the first time-based dynamic password and the second time-based dynamic password is successful, determine that the semi-offline authentication result is authentication passed;

[0025] If the matching verification of the first time-based dynamic password and the second time-based dynamic password fails, recalculate a new second time-based dynamic password within a nearby time window, and perform the matching verification based on the new second time-based dynamic password. If the verification is successful within the maximum number of retry verification times, determine that the semi-offline authentication result is authentication passed; otherwise, determine that the semi-offline authentication result is authentication failed.

[0026] Further, in some embodiments, the semi-offline authentication method includes a count-based dynamic password verification method. The payment terminal is authenticated by invoking the authentication logic through the authentication interface corresponding to the count-based dynamic password verification method, including:

[0027] Obtain the first count-based dynamic password included in the payment verification request. The first count-based dynamic password is generated by the payment terminal based on the first count value of the first counter and the shared key;

[0028] Read the second count value of the second counter, and calculate the second count-based dynamic password based on the second count value and the shared key;

[0029] Match and verify the first count-based dynamic password and the second count-based dynamic password, and determine the semi-offline authentication result based on the matching verification result.

[0030] Further, in some embodiments, the matching and verifying the first count-based dynamic password and the second count-based dynamic password, and determining the semi-offline authentication result based on the matching verification result includes:

[0031] If the matching verification of the first count-based dynamic password and the second count-based dynamic password is successful, determine that the semi-offline authentication result is authentication passed;

[0032] If the matching verification of the first counted dynamic password and the second counted dynamic password fails, then the second counter is readjusted within a preset adjustment range to obtain a new second count value, and a new second counted dynamic password is calculated based on the new second count value, and matching verification is performed according to the new second counted dynamic password. If the verification is successful within the maximum number of retry verifications, it is determined that the semi-offline authentication result is authentication passed; otherwise, it is determined that the semi-offline authentication result is authentication failed.

[0033] Further, in some embodiments, the semi-offline authentication method includes an authentication method based on a public key infrastructure. The payment terminal is authenticated by invoking authentication logic through an authentication interface corresponding to the authentication method based on the public key infrastructure, including:

[0034] Obtain the signature information and digital certificate included in the payment verification request, where the signature information is obtained by the payment terminal encrypting the received original challenge message;

[0035] If the validity verification of the digital certificate passes, then the public key stored in the digital certificate is used to decrypt the signature information to obtain decrypted challenge information;

[0036] Match and verify the decrypted challenge information and the original challenge message, and determine the semi-offline authentication result based on the matching verification result.

[0037] Further, in some embodiments, determining the risk assessment result of the payment verification request according to the payment scenario recognition result includes:

[0038] Obtain the historical payment behavior data associated with the payment verification request;

[0039] Determine the risk assessment result of the payment verification request through the payment scenario recognition result and the historical payment behavior data.

[0040] Further, in some embodiments, determining the risk assessment result of the payment verification request through the payment scenario recognition result and the historical behavior data includes:

[0041] Construct a multi-dimensional payment feature vector through the payment scenario recognition result and the historical behavior data;

[0042] Input the multi-dimensional payment feature vector into a payment risk assessment model to obtain a risk assessment score, and determine the payment risk level through the risk assessment score;

[0043] Determine the risk assessment result of the payment verification request based on the payment risk level.

[0044] In the second aspect of the embodiment of the specification, a non-sensing identity verification device in a weak network environment is also proposed, including:

[0045] A payment scenario recognition module, used to respond to a payment verification request triggered by a payment terminal in a weak network environment, and determine a payment scenario recognition result corresponding to the payment verification request;

[0046] A payment risk assessment module, used to determine a risk assessment result of the payment verification request according to the payment scenario identification result;

[0047] An identity authentication adaptation module, configured to determine at least one semi-offline identity authentication method based on the payment scenario identification result and the risk assessment result;

[0048] The senseless identity verification module is used to authenticate the payment terminal through the semi-offline identity verification method, determine the semi-offline identity verification result, and complete the payment verification request through the semi-offline identity verification result.

[0049] According to a third aspect of the embodiments of this specification, a computer program product is provided. The computer program product stores at least one instruction, and the at least one instruction is suitable for being loaded by a processor and executing the method steps in the first aspect.

[0050] According to a fourth aspect of the embodiments of this specification, a storage medium is provided, wherein the storage medium stores a computer program, and the computer program is suitable for being loaded by a processor and executing the steps of the method in the first aspect.

[0051] According to a fifth aspect of the embodiments of the present specification, there is also provided an electronic device, comprising: a processor and a memory; wherein the memory stores a computer program, and the computer program is suitable for being loaded by the processor and executing the steps of the method in the first aspect.

[0052] In an embodiment of the present specification, when a payment verification request is detected to be triggered when the payment end is in a weak network environment, the payment scenario identification result corresponding to the payment verification request can be determined, and the risk assessment result of the payment verification request can be determined based on the payment scenario identification result; then, at least one semi-offline identity authentication method can be determined based on the payment scenario identification result and the risk assessment result, and the payment end can be authenticated by using the most suitable semi-offline identity authentication method screened, and the semi-offline identity authentication result is determined, thereby completing the payment verification request through the semi-offline identity authentication result. On the one hand, combined with the payment scenario identification results and risk assessment results corresponding to the payment verification request, it can dynamically adapt at least one semi-offline identity authentication method in the current payment scenario to achieve identity authentication, effectively avoiding the limitations of relying on a fixed or single identity authentication method when the network is unstable, and improving the flexibility of the identity authentication method to meet the needs of various complex payment scenarios; on the other hand, through real-time detection and evaluation of payment scenarios and risks, the system can automatically adjust the complexity of identity authentication according to the type of payment scenario and actual risk, avoid user experience problems caused by excessive or insufficient verification, and improve the identity authentication efficiency of the payment process while ensuring the security of payment verification; on the other hand, combined with the dynamically adapted semi-offline identity authentication method, it can reduce the dependence of the payment verification process on the network environment of the payment end, improve the reliability and success rate of identity authentication, and ensure the smoothness of the payment verification process, so that users can complete payment verification in a shorter time, avoid long waiting times, and improve the overall payment experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] Figure 1 A schematic diagram of the system architecture of an exemplary application environment of a method and device for senseless identity verification in a weak network environment to which the embodiments of this specification can be applied is shown.

[0054] Figure 2 A flowchart of a method for seamless identity verification in a weak network environment provided in an embodiment of this specification.

[0055] Figure 3 A schematic diagram of a process for performing identity authentication through a time-synchronized one-time password authentication method provided in an embodiment of this specification.

[0056] Figure 4 A schematic diagram of a process for performing identity authentication through a counting-based dynamic password authentication method provided in an embodiment of this specification.

[0057] Figure 5 A schematic diagram of a process for performing identity authentication through a public key infrastructure-based authentication method provided in an embodiment of this specification.

[0058] Figure 6A schematic diagram of the structure of a seamless identity verification platform in a weak network environment provided in an embodiment of this specification.

[0059] Figure 7 A schematic diagram of the structure of a non-sensitive identity verification device in a weak network environment provided in an embodiment of this specification.

[0060] Figure 8 A schematic diagram of the structure of an electronic device provided in an embodiment of this specification. DETAILED DESCRIPTION

[0061] In order to make the purpose, technical solutions and advantages of this specification more clear, the technical solutions of this specification will be clearly and completely described below in combination with the specific embodiments of this specification and the corresponding drawings. Obviously, the described embodiments are only part of the embodiments of this specification, not all of them. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this specification.

[0062] Figure 1 A schematic diagram of a system architecture of an exemplary application environment in which a method and device for detecting spoofed documents according to an embodiment of the present specification can be applied is shown.

[0063] like Figure 1 As shown, the system architecture 100 may include one or more of terminal devices 101, 102, 103, a network 104, and a server 105. The network 104 is used to provide a medium for communication links between the terminal devices 101, 102, 103 and the server 105. The network 104 may include various connection types, such as wired, wireless communication links or optical fiber cables, etc. The terminal devices 101, 102, 103 may be various electronic devices with payment verification and network communication capabilities, including but not limited to desktop computers, portable computers, smart phones, tablet computers, etc. It should be understood that Figure 1 The number of terminal devices, networks and servers in the embodiment is only for illustration. According to the implementation requirements, there may be any number of terminal devices, networks and servers. For example, the server 105 may be a server cluster composed of multiple servers.

[0064] The senseless identity verification method in a weak network environment provided in the embodiments of this specification is generally performed by the terminal devices 101, 102, and 103, and accordingly, the senseless identity verification device in a weak network environment is generally set in the terminal devices 101, 102, and 103. However, it is easy for those skilled in the art to understand that the senseless identity verification method in a weak network environment provided in the embodiments of this specification can also be performed by the server 105, and accordingly, the senseless identity verification device in a weak network environment can also be set in the server 105, which is not particularly limited in this exemplary embodiment.

[0065] See also Figure 2 , which is a flowchart of a method for non-sense identity verification in a weak network environment provided in the embodiments of this specification. In the embodiments of this specification, the method for non-sense identity verification in a weak network environment can be applied to a terminal device or a server, and this exemplary embodiment does not make any special restrictions on this. Figure 2 The process shown in the figure is described in detail. The identity verification method in a weak network environment in the embodiment of this specification may specifically include the following steps:

[0066] Step S210, responding to a payment verification request triggered by a payment terminal in a weak network environment, and determining a payment scenario recognition result corresponding to the payment verification request;

[0067] Step S220, determining a risk assessment result of the payment verification request according to the payment scenario identification result;

[0068] Step S230, determining at least one semi-offline identity authentication method based on the payment scenario identification result and the risk assessment result;

[0069] Step S240, authenticating the payment terminal through the semi-offline identity authentication method, determining a semi-offline identity authentication result, and completing the payment authentication request through the semi-offline identity authentication result.

[0070] According to the identity-free verification method in a weak network environment in the embodiments of this specification, on the one hand, in combination with the payment scenario identification result and the risk assessment result corresponding to the payment verification request, it is possible to dynamically adapt at least one semi-offline identity verification method in the current payment scenario to achieve identity verification, effectively avoiding the limitation of relying on a fixed or single identity verification method when the network is unstable, and improving the flexibility of the identity verification method to meet the needs of various complex payment scenarios; on the other hand, through real-time detection and evaluation of payment scenarios and risks, the system can automatically adjust the complexity of identity verification according to the type of payment scenario and the actual risk, avoiding user experience problems caused by excessive or insufficient verification, and ensuring the security of payment verification while improving the identity verification efficiency of the payment process; on the other hand, combined with the dynamically adapted semi-offline identity verification method, it can reduce the dependence of the payment verification process on the network environment of the payment end, improve the reliability and success rate of identity verification, and ensure the smoothness of the payment verification process, so that users can complete payment verification in a shorter time, avoid long waiting times, and improve the overall payment experience.

[0071] The following is a detailed description of the identity verification method in a weak network environment in the embodiments of this specification.

[0072] In step S210, in response to a payment verification request triggered when the payment terminal is in a weak network environment, a payment scenario recognition result corresponding to the payment verification request is determined.

[0073] In an example embodiment of this specification, a weak network environment refers to a network state in which the communication quality between the payment terminal (i.e., the user device) and the service terminal is poor due to factors such as network bandwidth limitation, network delay, and excessive packet loss rate. For example, a weak network environment can be an environment in which the payment terminal is in a signal blind spot of the mobile network, or an environment in which the network signal is unstable, resulting in extremely slow or unstable data transmission speed. Of course, it can also be an environment in which the network signal is shielded. This example embodiment does not specifically limit the specific type of weak network environment.

[0074] Whether it is in a weak network environment can be determined by the network status indicators of the payment end. For example, the network environment of the payment end can be determined by parameters such as TCP (Transmission Control Protocol) delay, IP (Internet Protocol) packet loss rate, and network access method (such as 2G / 3G / 4G / Wi-Fi). It is understandable that if the payment end is in a strong network environment, it can be directly verified according to the online payment verification method. Of course, the identity verification method provided in this embodiment can also be used for identity verification. This embodiment does not make special restrictions on this.

[0075] A payment verification request refers to a request initiated by a user during a payment operation. For example, a payment verification request can be a request initiated when the user uses the Near Field Communication (NFC) function of the payment terminal device to approach the server device to complete the payment, or it can be a request initiated when the server device scans the QR code presented by the payment terminal to complete the payment. This exemplary embodiment does not make any special limitations on the scenario of initiating a payment verification request. A payment verification request generally can include data such as the payment amount, merchant information, payment method, verification information, etc., to facilitate the server to complete the current payment process based on the payment verification request. The specific data types included in the payment verification request can be custom-set according to actual verification requirements, and this embodiment does not make any special limitations on this.

[0076] The payment scenario recognition result refers to determining what kind of payment scenario the current payment operation belongs to (such as QR code offline reverse scan payment, NFC cabinet offline payment, e-wallet payment, airplane offline payment, etc.) by analyzing relevant information in the payment verification request. For example, when using a barcode scanner in a mall to reverse scan the payment code presented by the payment terminal, the payment verification request can be recognized as a "QR code offline reverse scan payment scenario", and an appropriate payment identity verification method can be selected according to the characteristics of this scenario set in advance. Of course, this is only an illustrative example here and should not cause any special limitations to this exemplary embodiment.

[0077] When detecting a payment verification request triggered in a weak network environment of the payment terminal, the payment scenario recognition result corresponding to the current payment operation can be determined according to the data included in the payment verification request. For example, a payment verification feature vector can be created according to the data in the payment verification request, and the payment verification feature vector can be matched in a preset payment scenario database to obtain the payment scenario recognition result; or the data in the payment verification request can be input into a pre-trained payment scenario recognition model for inference to obtain the payment scenario recognition result corresponding to the payment verification request; of course, the payment scenario recognition result corresponding to the payment verification request can also be determined by other means, and this embodiment is not limited thereto.

[0078] In step S220, determine the risk assessment result of the payment verification request according to the payment scenario recognition result.

[0079] In an exemplary embodiment of this specification, the risk assessment result refers to a quantitative assessment of the potential risks of a payment request. By determining the risk assessment result of the payment verification request and combining it with the payment scenario recognition result, a semi-offline identity verification method more suitable for the current payment process can be adapted. For example, the risk assessment result can be set to low risk, medium risk, and high risk levels, or it can be set to the first risk, second risk, and third risk levels. The higher the number, the higher the risk level. Of course, the risk assessment result here is only a schematic example, and it can be customized according to the actual situation. This embodiment is not limited thereto.

[0080] When evaluating, the risk level of the current payment process can be determined by combining the payment scenario recognition result. For example, different risk levels can be set for different payment scenarios in advance based on expert experience. For example, the risk of the NFC vending machine offline payment scenario is higher than that of the QR code offline reverse scan payment scenario, the risk of the QR code offline reverse scan payment scenario is higher than that of the e-wallet payment scenario, and the risk of the e-wallet payment scenario is higher than that of the airplane offline payment scenario, etc. Of course, the risk level setting here is only a schematic example and should not cause special limitations.

[0081] Optionally, the payment scenario recognition result can also be combined with the historical payment behavior data of the payment terminal or the associated account information to comprehensively estimate the risk assessment result of the current payment operation. For example, the historical payment behavior data can include historical transaction behaviors, the device information of the user, the geographical location of the payment, etc. Specifically, assuming that the payment terminal or the associated account information attempts to make a large payment in a certain unfamiliar geographical location, the current payment operation can be evaluated as a high risk level. On the contrary, if the user makes multiple small payments at a regular merchant, the current payment operation can be evaluated as a low risk level. For example, the payment scenario recognition result and the historical payment behavior data of the payment terminal or the associated account information can be used to construct a multi-dimensional feature vector and input it into a pre-trained risk assessment model based on deep learning for inference and evaluation to obtain the risk assessment result; or the risk assessment result corresponding to the payment scenario recognition result and the historical payment behavior data can be determined through the knowledge graph. This embodiment is not limited thereto.

[0082] In step S230, at least one semi-offline identity verification method is determined based on the payment scenario recognition result and the risk assessment result.

[0083] In an exemplary embodiment of this specification, the semi-offline authentication method refers to a technology for completing authentication when the payment terminal does not require a real-time network connection while the server has a network connection. During the semi-offline authentication process, some computing tasks can be completed locally on the user device. For example, the semi-offline authentication method can be an authentication method based on a dynamically generated verification code stored locally, or a biometric recognition technology (such as fingerprint verification, face recognition verification, etc.) recognized locally on the user device. This exemplary embodiment does not make special limitations on the specific type of the semi-offline authentication method.

[0084] At least one semi-offline authentication method can be screened and matched from a preset authentication support library according to the payment scenario recognition result and the risk assessment result. For example, keywords corresponding to the payment scenario recognition result and the risk assessment result can be extracted, and the semi-offline authentication method can be matched and screened from the preset authentication support library according to the keyword and a preset regular expression. Of course, candidate semi-offline authentication methods can also be matched and determined from the preset authentication support library according to the scenario feature data of the payment scenario recognition result, and then filtered by the risk assessment result to determine the appropriate semi-offline authentication method.

[0085] In step S240, the payment terminal is authenticated through the semi-offline authentication method to determine the semi-offline authentication result, so as to complete the payment verification request through the semi-offline authentication result.

[0086] In an exemplary embodiment of this specification, the semi-offline authentication result refers to the verification result returned after authenticating the payment terminal through the matched semi-offline authentication method in a weak network environment. For example, the semi-offline authentication result can be "verification passed", "verification failed", or "retry", etc. This exemplary embodiment does not make special limitations on the expression of the semi-offline authentication result.

[0087] The payment terminal can be authenticated through one or more semi-offline authentication methods that are matched. For example, assuming that only one semi-offline authentication method is matched, the authentication result obtained by the current semi-offline authentication method is used as the semi-offline authentication result. Assuming that more than two semi-offline authentication methods are matched, the authentication results obtained by each semi-offline authentication method can be fused to obtain the semi-offline authentication result. For example, if the authentication result of any semi-offline authentication method fails, the semi-offline authentication result is considered to fail. It can also be that the weights of the authentication results of each semi-offline authentication method are preset, and the authentication results of each semi-offline authentication method are weighted and calculated using the weights of the authentication results, and the final semi-offline authentication result is determined according to the score value obtained from the weighted calculation. Of course, this is only an illustrative example here, and the present exemplary embodiment does not make special limitations on the method for obtaining the semi-offline authentication result.

[0088] Combining the payment scenario recognition result and the risk assessment result corresponding to the payment verification request, it is possible to dynamically adapt at least one semi-offline authentication method in the current payment scenario to achieve authentication, effectively avoiding the limitation of relying on a fixed or single authentication method when the network is unstable, improving the flexibility of the authentication method to meet the needs of various complex payment scenarios; through the real-time detection and assessment of the payment scenario and risks, the system can automatically adjust the complexity of authentication according to the type of payment scenario and the actual risk, avoiding user experience problems caused by over-verification or under-verification, and ensuring the security of payment verification while improving the authentication efficiency of the payment process; and by combining the dynamically adapted semi-offline authentication method, it is possible to reduce the dependence of the payment verification process on the network environment of the payment terminal, improve the reliability and success rate of authentication, ensure the smoothness of the payment verification process, so that users can complete the payment verification in a short time, avoid long waiting times, and enhance the overall payment experience.

[0089] The content in steps S210 to S240 will be further described below.

[0090] In an exemplary embodiment of this specification, the risk assessment result of the payment verification request can be determined according to the payment scenario recognition result in step S220 through the following steps, which can specifically include:

[0091] The historical payment behavior data associated with the payment verification request can be obtained, and the risk assessment result of the payment verification request can be determined through the payment scenario recognition result and the historical payment behavior data.

[0092] Among them, historical payment behavior data refers to payment-related data generated by the payment terminal that initiates the payment verification request or the current account information on the payment terminal at a historical moment. For example, the historical payment behavior data can be historical payment scenarios, common payment amount ranges, etc., or historical payment frequencies, common merchant geographical locations, etc. In this embodiment, no special limitation is imposed on the data type of the historical payment behavior data.

[0093] The payment scenario recognition result can be used as the core input parameter, and the historical payment behavior data associated with the payment verification request can be used as supplementary data to form the context data for realizing the risk assessment of the payment verification request. Thus, by combining the payment scenario recognition result and the historical payment behavior data, it is possible to effectively determine the consistency between the current payment request and the historical behavior pattern, determine the abnormality of the payment operation at the current moment, and further determine the risk assessment result of the payment verification request.

[0094] By combining the payment scenario recognition result with the historical payment behavior data, the dynamic assessment of payment risks can be realized, the abnormality of the payment request can be accurately judged, and a scientific basis can be provided for the subsequent identity verification method selection strategy, thereby reducing the impact of over-verification on the user experience while ensuring payment security.

[0095] Optionally, the risk assessment result of the payment verification request can be determined through the payment scenario recognition result and the historical behavior data by the following steps, which may specifically include:

[0096] A multi-dimensional payment feature vector can be constructed through the payment scenario recognition result and the historical behavior data, and the multi-dimensional payment feature vector can be input into the payment risk assessment model to obtain a risk assessment score. Furthermore, the payment risk level can be determined through the risk assessment score, and the payment risk level can be used as the risk assessment result of the payment verification request.

[0097] Among them, the multi-dimensional payment feature vector refers to a vector constructed based on the payment scenario recognition result and the historical behavior data for characterizing the reliability of the current payment operation. For example, the multi-dimensional payment feature vector can be a multi-dimensional vector composed of features such as transaction amount features, payment time features, merchant category features, geographical location features, device features, and historical behavior data.

[0098] A payment risk assessment model refers to a systematic tool that quantifies and classifies the potential risks of payment operations through specific algorithms or rules based on multi-dimensional payment feature vectors. This model takes the payment scenario recognition results, historical payment behavior data, and current payment features as inputs, and outputs risk scores or risk levels through specific algorithms, which are used to guide the selection of subsequent combined strategies for authentication methods. For example, the payment risk assessment model can be a constraint model based on conditional rules, or an artificial intelligence model that trains historical transaction data through supervised learning algorithms to learn the degree of influence of different payment features on risks. Such an artificial intelligence model can be a random forest, a gradient boosting decision tree (GBDT), a support vector machine (SVM), or a deep learning network, etc. There are no special limitations on this in history and privately.

[0099] By constructing a multi-dimensional payment feature vector and inputting it into the payment risk assessment model, and comprehensively analyzing the payment features through the payment risk assessment model, the risk assessment efficiency for payment verification requests is improved. Moreover, through the multi-dimensional payment feature vector that integrates context data such as payment scenario recognition results and historical behavior data, the accuracy of the risk assessment results is enhanced, providing support for the dynamic adjustment of the subsequent combined strategy for authentication methods. Thus, the combined strategy for authentication methods selected by the method provided in this embodiment achieves a balance between the security and convenience of payment operations.

[0100] In an exemplary embodiment of this specification, the determination of at least one semi-offline authentication method in step S230 can be achieved through the following steps, which can specifically include:

[0101] The scenario feature data of the payment scenario recognition result can be determined, and candidate semi-offline authentication methods can be matched and determined from a preset authentication support library according to the scenario feature data. Furthermore, the candidate semi-offline authentication methods can be filtered based on the risk assessment result to obtain at least one semi-offline authentication method for verifying the payment end.

[0102] Among them, the scenario feature data refers to the data representing the current payment scenario environment extracted based on the payment scenario recognition result. For example, the scenario feature data can be feature data such as payment methods, payment amount ranges, payment times, or can also be feature data such as merchant categories, geographical locations, and network environment statuses of user devices. There are no special limitations on the type of scenario feature data in this embodiment.

[0103] The authentication support library refers to a pre-set database for managing semi-offline authentication methods. The semi-offline authentication method applicable to the current payment scenario can be matched from the authentication support library according to the scenario feature data. For example, the scenario feature keywords and security levels adapted to each semi-offline authentication method in the authentication support library can be pre-added, and then the candidate semi-offline authentication method can be determined through the matching of the scenario feature data and the scenario feature keywords.

[0104] After matching through the scenario feature data, all candidate semi-offline authentication methods that can authenticate the current payment scenario can be obtained. Further, the candidate semi-offline authentication methods can be further filtered based on the risk assessment results, so that the security level of the semi-offline authentication method matches the risk level included in the risk assessment results.

[0105] For example, in an optional embodiment, it is assumed that the semi-offline authentication methods may include time-synchronized one-time password authentication method, counter-based dynamic password authentication method, and public key infrastructure-based authentication method. The characteristics of the above semi-offline authentication methods can be set, and then the scenario feature data can also be matched with the characteristics of the authentication methods. For example, the characteristics of the above semi-offline authentication methods can be set as follows:

[0106] Table 1 Examples of characteristics of semi-offline authentication methods

[0107]

[0108] It should be noted that the characteristics of the above semi-offline authentication methods are only illustrative examples and should not impose any special limitations on the present exemplary embodiments.

[0109] By combining the scenario feature data of the payment scenario recognition result and the risk assessment result to select the semi-offline authentication method, it can ensure that in a weak network environment, the selected semi-offline authentication method can not only meet the authentication of the current payment scenario, but also effectively guarantee the security requirements, making a balance between the security of payment operations and user convenience, and optimizing the user experience.

[0110] In an exemplary embodiment of this specification, the authentication of the payment terminal through the semi-offline authentication method in step S240 can be implemented through the following steps, which may specifically include:

[0111] The verification method identification data corresponding to the semi-offline authentication method can be determined, and then the authentication interface corresponding to the semi-offline authentication method can be called according to the verification method identification data, so as to call the authentication logic through the authentication interface to authenticate the payment terminal.

[0112] Among them, the verification method identification data refers to the data used to uniquely identify each semi-offline authentication method. For example, the verification method identification data can be the name of the verification method of the semi-offline authentication method, or the type of the verification method of the semi-offline authentication method or the adaptation interface information, or it can also be the unique coding information corresponding to the semi-offline authentication method. This exemplary embodiment is not limited thereto.

[0113] The authentication interface refers to an application programming interface (API) used to implement the authentication logic of the semi-offline authentication method. The authentication logic for implementing the semi-offline authentication method can be encapsulated as an authentication interface in advance through a unified interface encapsulation protocol. In this way, when a certain semi-offline authentication method is adopted, the corresponding authentication interface can be directly called to implement.

[0114] Through the combination of the verification method identification data and the authentication interface, the modular management of the authentication logic is realized, the complexity of the identity seamless authentication system is reduced, and the scalability and reusability of the authentication logic are improved. In addition, this solution realizes the standardization of the verification process by calling the preset interface, effectively enhancing the flexibility of the identity seamless authentication system.

[0115] In an optional implementation manner, the semi-offline authentication method includes a time-synchronized one-time password authentication method. Specifically, the Figure 3 in the steps can be used to implement the call of the authentication logic to authenticate the payment end through the authentication interface corresponding to the time-synchronized one-time password authentication method. Referring to Figure 3 shown, the authentication logic of the time-synchronized one-time password authentication method may include:

[0116] Step S310, obtaining the first time dynamic password included in the payment verification request, where the first time dynamic password is generated by the payment end based on the first timestamp, the preset time window, and the shared key;

[0117] Step S320, calculating a second time dynamic password according to the preset time window, the shared key, and the collected second timestamp;

[0118] Step S330, matching and verifying the first time dynamic password and the second time dynamic password, and determining the semi-offline authentication result through the matching verification result.

[0119] Among them, the first-time dynamic password refers to the dynamic verification password generated by the payment terminal based on the first timestamp collected at the payment terminal and combined with the preset time window and shared key pre-shared with the server. The second-time dynamic password refers to the dynamic verification password generated by the server based on the second timestamp collected at the server and combined with the preset time window and shared key pre-shared with the payment terminal. The calculation methods of the first-time dynamic password and the second-time dynamic password are the same, and the only difference is that the calculation is performed on different device terminals.

[0120] It can be understood that the "first" and "second" here are only used to distinguish the time dynamic passwords calculated on different device terminals and the collected timestamps, and have no special meaning, nor should they cause any special limitations to the embodiments of this example.

[0121] The time synchronization one-time password verification method combines timestamps, shared keys, and time windows to realize the automatic generation and verification of dynamic passwords, which can effectively resist replay attacks and ensure the uniqueness and timeliness of dynamic passwords. At the same time, this verification method reduces the dependence on the real-time network during the authentication process, enabling smooth completion of authentication even in a weak network environment, and improving the availability and security of the system.

[0122] Specifically, the second-time dynamic password can be calculated according to the preset time window, shared key, and the collected second timestamp through the following steps, which can specifically include:

[0123] The time window number can be determined according to the second timestamp and the preset time window, and then the shared key and the time window number can be encrypted to calculate the second-time dynamic password.

[0124] Among them, the determination of the time window number is based on the segmented calculation of the timestamp and the preset time window. The second timestamp can be divided by the size of the preset time window, and the integer obtained is used as the time window number. This time window number serves as a unique identifier in the entire time synchronization one-time password verification method to ensure the timeliness and uniqueness of the dynamic password.

[0125] The HMAC algorithm or the AES algorithm can be used to encrypt the shared key and the time window number. This embodiment does not make special limitations on the type of encryption algorithm, as long as the security and anti-tampering ability of the calculation process are ensured. The encrypted output is the second-time dynamic password, which has high security in combination with the characteristics of the time window number and the shared key.

[0126] It is understandable that the calculation methods of the first-time dynamic password and the second-time dynamic password are the same. In this embodiment, the calculation method of the time dynamic password is given by taking the second-time dynamic password as an example, and the calculation method of the first-time dynamic password will not be elaborated here.

[0127] By mapping the timestamp to a time window number and generating a dynamic password based on the shared key, the high security and anti-tampering of the dynamic password generation process are ensured. Moreover, the robustness of the time synchronization process can be improved through the time window number, effectively coping with the clock deviation problem between the payment end and the server, thereby enhancing the reliability of dynamic password verification.

[0128] Specifically, the first-time dynamic password and the second-time dynamic password can be matched and verified, and the semi-offline identity verification result can be determined based on the matching verification result. Specifically, it can include:

[0129] When it is detected that the matching verification of the first-time dynamic password and the second-time dynamic password is successful, it can be determined that the semi-offline identity verification result is identity verification passed; when it is detected that the matching verification of the first-time dynamic password and the second-time dynamic password fails, a new second-time dynamic password can be recalculated within the nearby time window, and the matching verification is performed again according to the new second-time dynamic password. If the verification is successful within the preset maximum number of retry verifications, it is determined that the semi-offline identity verification result is identity verification passed, otherwise it is determined that the semi-offline identity verification result is identity verification failed, or a new payment verification request is requested again.

[0130] During the dynamic password matching process, the first-time dynamic password and the second-time dynamic password can be compared. If the two match, the verification passes and a verification successful result is returned; if the match fails, the time window can be extended forward or backward based on the current time window for recalculation. This verification mechanism can allow a certain range of time deviation to tolerate the problem of clock asynchronization between the client and the server. If the verification still cannot be successful after multiple retries, the verification fails. The limit on the number of retries can prevent malicious attacks and ensure the security of the verification at the same time.

[0131] In the case of dynamic password verification failure, through the adjustment of the time window and the retry mechanism, the fault tolerance and success rate of identity verification are improved. In this way, while ensuring the security of the verification, the probability of verification failure caused by clock asynchronization between the payment end and the service end can be reduced, thereby improving the payment success rate of users in a weak network environment and optimizing the user experience.

[0132] In an optional embodiment, the semi-offline identity verification method can include a dynamic password verification method based on counting, which can be through Figure 4The steps in [reference] implement the authentication of the payment terminal by invoking the authentication logic through the authentication interface corresponding to the count-based dynamic password authentication method. Figure 4 As shown in [reference], the authentication logic of this count-based dynamic password authentication method may include:

[0133] Step S410: Obtain the first count dynamic password included in the payment verification request. The first count dynamic password is generated by the payment terminal based on the first count value of the first counter and the shared key.

[0134] Step S420: Read the second count value of the second counter, and calculate the second count dynamic password according to the second count value and the shared key.

[0135] Step S430: Match and verify the first count dynamic password and the second count dynamic password, and determine the semi-offline authentication result through the match verification result.

[0136] Among them, the first count dynamic password refers to the dynamic verification password generated by the payment terminal based on the first count value read from the first counter set in the payment terminal and combined with the shared key pre-shared with the server. The second count dynamic password refers to the dynamic verification password generated by the server based on the second count value read from the second counter set in the server and combined with the shared key pre-shared with the payment terminal. The calculation methods of the first count dynamic password and the second count dynamic password are the same, and the only difference is that the calculation is performed on different device terminals.

[0137] The HMAC algorithm can be used to encrypt the shared key and the second count value to obtain the second count dynamic password, or the AES algorithm can be used to encrypt the shared key and the second count value to obtain the second count dynamic password. In this embodiment, the type of encryption algorithm is not specially limited, as long as the security and anti-tampering ability of the calculation process are ensured.

[0138] It can be understood that the "first" and "second" here are only used to distinguish the counters, the count values read from the counters, and the calculated count dynamic passwords in different device terminals, and have no special meaning, nor should they cause any special limitations to this example embodiment.

[0139] The count-based dynamic password authentication method combined with the count value of the counter and the shared key can effectively ensure the uniqueness and security of each payment request, reduce the dependence on time synchronization, and is particularly suitable for payment scenarios where the device clock may be inaccurate or in a weak network environment, further enhancing the applicability and robustness of the system.

[0140] Specifically, the matching verification of the first counted dynamic password and the second counted dynamic password can be implemented through the following steps, and the semi-offline authentication result can be determined based on the matching verification result, including:

[0141] When it is detected that the matching verification of the first counted dynamic password and the second counted dynamic password is successful, it can be determined that the semi-offline authentication result is authentication passed; or, when it is detected that the matching verification of the first counted dynamic password and the second counted dynamic password fails, the second counter can be readjusted within a preset adjustment range to obtain a new second count value, and a new second counted dynamic password can be calculated based on the new second count value, and matching verification is performed according to the new second counted dynamic password. If the verification is successful within the maximum number of retry verifications, it is determined that the semi-offline authentication result is authentication passed, otherwise it is determined that the semi-offline authentication result is authentication failed.

[0142] During the matching verification process, by comparing whether the first counted dynamic password and the second counted dynamic password are the same, if they are the same, the verification passes; if they are different, the counter value of the server can be readjusted according to the preset counter adjustment range, and a new dynamic password is calculated for re-matching. This adjustment mechanism allows for counter deviations within a certain range, effectively avoiding the problem that the counters of the payment side and the server may be out of sync. If the matching is completed within the maximum number of retries, the verification passes; otherwise, the verification fails and an error status is returned.

[0143] Through the counter adjustment and retry mechanism, the dynamic adjustment and fault tolerance of the authentication process can be improved, the problem that the counters of the payment side and the server may be out of sync can be effectively solved, the verification failure rate can be reduced, the authentication efficiency can be improved, and at the same time, the security of the authentication process is ensured through the limit of the number of retries.

[0144] In an alternative embodiment, the semi-offline authentication method may include an authentication method based on public key infrastructure, and the identity authentication logic for the payment side can be called through the authentication interface corresponding to the authentication method based on public key infrastructure through the steps in Figure 5 Specifically, it may include: Figure 5 As shown in

[0145] Step S510, obtaining the signature information and digital certificate included in the payment verification request, where the signature information is obtained by the payment side encrypting the received original challenge message;

[0146] Step S520, if the validity verification of the digital certificate passes, decrypt the signature information using the public key stored in the digital certificate to obtain decrypted challenge information;

[0147] Step S530: Match and verify the decryption challenge information and the original challenge message, and determine the semi-offline authentication result based on the match verification result.

[0148] The original challenge message refers to the message sent to the payment end when it is in a networked environment, which serves as a random seed for encryption. The decryption challenge information refers to the message obtained by the server after encrypting based on the signature information and digital certificate provided by the payment end, which is used to prevent data tampering and impersonation attacks.

[0149] The verification method based on public key infrastructure refers to the method of implementing identity authentication through digital signature and public key verification. In the payment verification request, the payment end will attach signature information and digital certificate. The signature information is generated by the payment end encrypting the original challenge message with the private key. After receiving the payment verification request initiated by the payment end, the validity of the digital certificate can be verified first, including whether the issuing authority of the certificate is legal, whether the certificate has expired, etc.; if the digital certificate passes the verification, the public key stored in the digital certificate is extracted to decrypt the signature information to obtain the decrypted decryption challenge message. The decryption challenge message can be compared with the original challenge message. If the comparison is successful, the identity authentication is confirmed to pass; if the comparison fails, the verification fails. This method can effectively prevent data tampering and impersonation while ensuring security.

[0150] The verification method based on public key infrastructure by combining digital certificate and signature verification effectively realizes the high security and anti-forgery of identity authentication, can effectively prevent data tampering and impersonation, and is particularly suitable for high-risk payment scenarios such as large-value payments and cross-border payments. In addition, the verification method based on public key infrastructure combines the validity verification of digital certificates to enhance the credibility of the payment verification process.

[0151] In this embodiment, the semi-offline identity verification method can at least include time-synchronized one-time password verification method, count-based dynamic password verification method, and verification method based on public key infrastructure. It can be understood that the semi-offline identity verification method can also be other types of semi-offline identity verification methods. With the update and iteration of technology, the semi-offline identity verification method in this specification will also be updated and iterated. The semi-offline identity verification methods exemplified above should not impose any special limitations on this embodiment.

[0152] In an optional embodiment, the identity seamless verification method provided in the embodiments of this specification can be implemented as an identity seamless verification platform in a weak network environment. Refer to Figure 6 As shown, the identity seamless verification platform 600 in a weak network environment can be provided with a platform layer and a product layer.

[0153] Specifically, the platform layer may be provided with a unified verification framework 610, a dynamic adaptation module 620, a non-sensing verification module 630, and an extended implementation module 640. Among them, the unified verification framework 610 can be used to manage and call the authentication methods provided in the product layer, such as the time-synchronized one-time password verification method 650, the count-based dynamic password verification method 660, the public key infrastructure-based verification method 670, etc. in the product layer. The authentication logics of the authentication methods in the product layer can be encapsulated through a unified interface standard protocol and stored, retrieved, and called through an authentication support library provided in the unified verification framework 610. Through the unified verification framework 610, the platform can integrate multiple authentication methods together, simplify the development and deployment processes, and improve the compatibility and maintainability of the system; the dynamic adaptation module 620 can be used to dynamically select the most suitable authentication method according to the requirements of specific payment verification scenarios, or combine multiple authentication methods to provide a better authentication solution; the non-sensing verification module 630 can be used to automatically identify the user's behavior patterns and risk levels for non-sensing authentication, improving the user experience while ensuring security; the extended implementation module 640 can be used to add new authentication methods to the unified verification framework 610, enabling the platform to have good scalability and quickly adapt to the development of new authentication technologies and the requirements of new payment scenarios, continuously improving the verification ability and security level.

[0154] It can be understood that, due to the different requirements and applicability of authentication methods in different payment scenarios, different authentication means can be combined and used according to the scenario feature data of specific payment scenarios through the identity non-sensing verification platform 600 under a weak network environment. For example, assuming that the payment scenario recognition result is the NFC cabinet offline payment scenario, the combination strategy of the time-synchronized one-time password verification method 650 and the count-based dynamic password verification method 660 can be combined to authenticate the payment terminal to ensure the uniqueness and security of each payment operation; assuming that the payment scenario recognition result is the digital currency offline payment scenario, the public key infrastructure-based verification method 670 can be used to perform high-security authentication on the payment terminal to ensure the security of the e-wallet and transactions and avoid fund theft; assuming that the payment scenario recognition result is the QR code offline reverse scan payment scenario, the time-synchronized one-time password verification method 650 can be used to generate a dynamic QR code, and the payment terminal (user) can display it to the server (merchant) for scanning in an offline state to improve payment security; assuming that the payment scenario recognition result is the aircraft offline payment scenario, the combined verification strategy of the time-synchronized one-time password verification method 650 and the public key infrastructure-based verification method 670 can be used to authenticate the payment terminal to ensure the security and reliability of payment operations even in the absence of a network.

[0155] In summary, for the identity seamless verification method in a weak network environment provided in the embodiments of this specification, when a payment verification request triggered when the payment terminal is in a weak network environment is detected, the payment scenario recognition result corresponding to the payment verification request can be determined, and the risk assessment result of the payment verification request can be determined according to the payment scenario recognition result; furthermore, at least one semi-offline identity verification method can be determined based on the payment scenario recognition result and the risk assessment result, and the payment terminal can be authenticated through the most suitable semi-offline identity verification method screened, and the semi-offline identity verification result can be determined, so as to complete the payment verification request through the semi-offline identity verification result. On the one hand, by combining the payment scenario recognition result corresponding to the payment verification request and the risk assessment result, at least one semi-offline identity verification method in the current payment scenario can be dynamically adapted to implement identity verification, effectively avoiding the limitation of relying on a fixed or single identity verification method when the network is unstable, improving the flexibility of the identity verification method to meet the needs of various complex payment scenarios; on the other hand, through the real-time detection and assessment of the payment scenario and risk, the system can automatically adjust the complexity of identity verification according to the type of payment scenario and the actual risk, avoiding user experience problems caused by over-verification or under-verification, and ensuring the security of payment verification while improving the identity verification efficiency of the payment process; on the one hand, by combining the dynamically adapted semi-offline identity verification method, the dependence of the payment verification process on the network environment of the payment terminal can be reduced, the reliability and success rate of identity verification can be improved, and the fluency of the payment verification process can be ensured, so that users can complete the payment verification in a short time, avoid long waiting, and improve the overall payment experience.

[0156] Please refer to Figure 7 , which is a schematic structural diagram of an identity seamless verification device in a weak network environment provided in the embodiments of this specification. As Figure 7 shown, the identity seamless verification device 700 in the weak network environment can be implemented as all or part of an electronic device through software, hardware, or a combination of both. According to some embodiments, the identity seamless verification device 700 in the weak network environment includes a payment scenario recognition module 710, a payment risk assessment module 720, an identity verification adaptation module 730, and an identity seamless verification module 740, specifically including:

[0157] The payment scenario recognition module 710 is configured to respond to a payment verification request triggered when the payment terminal is in a weak network environment, and determine the payment scenario recognition result corresponding to the payment verification request;

[0158] The payment risk assessment module 720 is configured to determine the risk assessment result of the payment verification request according to the payment scenario recognition result;

[0159] An identity authentication adaptation module 730, configured to determine at least one semi-offline identity authentication method based on the payment scenario identification result and the risk assessment result;

[0160] The senseless identity verification module 740 is used to authenticate the payment terminal through the semi-offline identity verification method, determine the semi-offline identity verification result, and complete the payment verification request through the semi-offline identity verification result.

[0161] Optionally, the identity authentication adapter module 730 may be configured as follows:

[0162] Determine scene feature data of the payment scene recognition result;

[0163] According to the scenario feature data, matching and determining candidate semi-offline identity authentication methods from a preset identity authentication support library;

[0164] The candidate semi-offline identity authentication methods are filtered based on the risk assessment result to obtain at least one semi-offline identity authentication method for verifying the payment terminal.

[0165] Optionally, the identity verification module 740 may include:

[0166] A verification identification determination unit, used to determine the verification method identification data corresponding to the semi-offline identity authentication method;

[0167] An identity authentication unit is used to call the identity authentication interface corresponding to the semi-offline identity authentication method according to the authentication method identification data, so as to authenticate the payment terminal by calling the identity authentication logic through the identity authentication interface.

[0168] Optionally, the semi-offline identity authentication method may include a time synchronization one-time password authentication method, and the identity authentication unit includes a time synchronization one-time password authentication subunit, and the time synchronization one-time password authentication subunit is configured as follows:

[0169] Acquire a first time dynamic password included in the payment verification request, where the first time dynamic password is generated by the payment terminal based on a first timestamp, a preset time window and a shared key;

[0170] Calculate a second time dynamic password according to the preset time window, the shared key and the collected second timestamp;

[0171] The first-time dynamic password and the second-time dynamic password are matched and verified, and a semi-offline identity authentication result is determined according to the matching verification result.

[0172] Optionally, the time-synchronized one-time password authentication subunit is configured as:

[0173] Determine a time window number according to the second timestamp and the preset time window;

[0174] Perform data encryption on the shared key and the time window number, and calculate to obtain the second time dynamic password.

[0175] Optionally, the time synchronization one-time password verification subunit is configured to:

[0176] If the matching verification of the first time dynamic password and the second time dynamic password is successful, determine that the semi-offline authentication result is authentication passed;

[0177] If the matching verification of the first time dynamic password and the second time dynamic password fails, recalculate a new second time dynamic password within a nearby time window, and perform matching verification according to the new second time dynamic password. If the verification is successful within the maximum number of retry verifications, determine that the semi-offline authentication result is authentication passed, otherwise determine that the semi-offline authentication result is authentication failed.

[0178] Optionally, the semi-offline authentication method includes a count-based dynamic password verification method, the authentication unit includes a count-based dynamic password verification subunit, and the count-based dynamic password verification subunit is configured to:

[0179] Obtain the first count dynamic password included in the payment verification request, where the first count dynamic password is generated by the payment terminal based on the first count value of the first counter and the shared key;

[0180] Read the second count value of the second counter, and calculate the second count dynamic password according to the second count value and the shared key;

[0181] Perform matching verification on the first count dynamic password and the second count dynamic password, and determine the semi-offline authentication result through the matching verification result.

[0182] Optionally, the count-based dynamic password verification subunit is configured to:

[0183] If the matching verification of the first count dynamic password and the second count dynamic password is successful, determine that the semi-offline authentication result is authentication passed;

[0184] If the matching verification of the first counted dynamic password and the second counted dynamic password fails, then the second counter is readjusted within a preset adjustment range to obtain a new second count value, and a new second counted dynamic password is calculated based on the new second count value, and matching verification is performed according to the new second counted dynamic password. If the verification is successful within the maximum number of retry verifications, it is determined that the semi-offline authentication result is authentication passed; otherwise, it is determined that the semi-offline authentication result is authentication failed.

[0185] Optionally, the semi-offline authentication method includes an authentication method based on a public key infrastructure, and the authentication unit includes an authentication subunit based on a public key infrastructure. The authentication subunit based on a public key infrastructure is configured to:

[0186] Obtain the signature information and digital certificate included in the payment verification request, where the signature information is obtained by encrypting the original challenge message received by the payment terminal;

[0187] If the validity verification of the digital certificate passes, the public key stored in the digital certificate is used to decrypt the signature information to obtain decrypted challenge information;

[0188] Perform matching verification on the decrypted challenge information and the original challenge message, and determine the semi-offline authentication result based on the matching verification result.

[0189] Optionally, the payment risk assessment module 720 is configured to:

[0190] Obtain the historical payment behavior data associated with the payment verification request;

[0191] Determine the risk assessment result of the payment verification request based on the payment scenario recognition result and the historical payment behavior data.

[0192] Optionally, the payment risk assessment module 720 is further configured to:

[0193] Construct a multi-dimensional payment feature vector based on the payment scenario recognition result and the historical behavior data;

[0194] Input the multi-dimensional payment feature vector into a payment risk assessment model to obtain a risk assessment score, and determine the payment risk level based on the risk assessment score;

[0195] Determine the risk assessment result of the payment verification request based on the payment risk level.

[0196] The above device embodiments correspond to the method embodiments. For specific descriptions, reference can be made to the descriptions in the method embodiment section, which will not be elaborated here. The device embodiments are obtained based on the corresponding method embodiments and have the same technical effects as the corresponding method embodiments. For specific descriptions, reference can be made to the corresponding method embodiments.

[0197] The embodiments of this specification also provide a computer storage medium, which can store multiple instructions. The instructions are suitable for being loaded and executed by a processor to perform the method as described in the embodiments of this specification. The specific execution process can be referred to the specific descriptions in the embodiments of this specification and will not be elaborated here.

[0198] The embodiments of this specification also provide a computer program product, which stores at least one instruction. The at least one instruction is loaded and executed by the processor to perform the method as described in the embodiments of this specification. The specific execution process can be referred to the specific descriptions in the embodiments of this specification and will not be elaborated here.

[0199] The embodiments of this specification also provide Figure 8 the structural schematic diagram of the electronic device shown. As Figure 8 , at the hardware level, the electronic device includes a processor, an internal bus, a network interface, a memory, and a non-volatile memory. Of course, it may also include other hardware required for other services. The processor reads the corresponding computer program from the non-volatile memory into the memory and then runs it to implement the above-mentioned voice activity detection method.

[0200] Of course, in addition to the software implementation, this specification does not exclude other implementation manners, such as logical devices or a combination of software and hardware. That is to say, the execution subject of the following processing flow is not limited to each logical unit and can also be hardware or a logical device.

[0201] The improvement of a technology can be clearly distinguished as either a hardware improvement (e.g., improvement of circuit structures such as diodes, transistors, switches, etc.) or a software improvement (improvement of method flows). However, with the development of technology, many improvements of method flows today can be regarded as direct improvements of hardware circuit structures. Almost all designers obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that an improvement of a method flow cannot be implemented with a hardware entity module. For example, a programmable logic device (PLD) (such as a field programmable gate array (FPGA)) is such an integrated circuit whose logic function is determined by the user's programming of the device. The designer can program by himself / herself to "integrate" a digital system on a piece of PLD, without having to ask the chip manufacturer to design and fabricate a dedicated integrated circuit chip. Moreover, nowadays, instead of manually fabricating integrated circuit chips, this programming is mostly implemented using "logic compiler" software, which is similar to the software compiler used in program development and writing. The original code before compilation also has to be written in a specific programming language, which is called a hardware description language (HDL), and there is not only one kind of HDL, but many kinds, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used ones currently are VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also be clear that only by slightly logically programming the method flow with the above-mentioned several hardware description languages and programming it into the integrated circuit can the hardware circuit implementing the logical method flow be easily obtained.

[0202] The controller can be implemented in any suitable manner. For example, the controller can take the form of, for example, a microprocessor or a processor and a computer-readable medium storing computer-readable program code (such as software or firmware) executable by the (micro)processor, logic gates, switches, an application specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller. Examples of the controller include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art also know that in addition to implementing the controller in the form of pure computer-readable program code, it is entirely possible to logically program the method steps to enable the controller to be implemented in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers, etc. to achieve the same functions. Therefore, such a controller can be considered a hardware component, and the devices included therein for implementing various functions can also be regarded as the structures within the hardware component. Or even, the devices for implementing various functions can be regarded as either software modules for implementing the method or structures within the hardware component.

[0203] The systems, devices, modules, or units illustrated in the above embodiments can be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, the computer can be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0204] For the convenience of description, when describing the above devices, they are described separately as various units according to their functions. Of course, when implementing this specification, the functions of each unit can be implemented in the same or multiple software and / or hardware.

[0205] Those skilled in the art should understand that the embodiments of this specification can be provided as a method, a system, or a computer program product. Therefore, this specification can take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware aspects. Moreover, this specification can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk memories, CD-ROMs, optical memories, etc.) containing computer-usable program code.

[0206] This specification is described with reference to the flowcharts and / or block diagrams of methods, apparatuses (systems), and computer program products according to embodiments of the specification. It should be understood that each flow and / or block in the flowchart and / or block diagram, and the combination of flows and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device to generate a machine, such that the instructions executed by the processor of the computer or other programmable data processing device produce a means for implementing the specified function in one or more of the flows Figure 1 one or more of the flows and / or blocks Figure 1 or means for implementing the specified function in one or more of the blocks.

[0207] These computer program instructions can also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, such that the instructions stored in the computer-readable memory produce a manufactured article including instruction means for implementing the specified function in one or more of the flows Figure 1 one or more of the flows and / or blocks Figure 1 or means for implementing the specified function in one or more of the blocks.

[0208] These computer program instructions can also be loaded onto a computer or other programmable data processing device, such that a series of operation steps are executed on the computer or other programmable device to generate a computer-implemented process, and thus the instructions executed on the computer or other programmable device provide steps for implementing the specified function in one or more of the flows Figure 1 one or more of the flows and / or blocks Figure 1 or means for implementing the specified function in one or more of the blocks.

[0209] In a typical configuration, a computing device includes one or more processors (CPUs), an input / output interface, a network interface, and memory.

[0210] The memory may include non-permanent memory in the form of computer-readable media, random access memory (RAM), and / or non-volatile memory such as read-only memory (ROM) or flash memory (flash RAM). The memory is an example of computer-readable media.

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

[0212] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity 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, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0213] Those skilled in the art will appreciate that the embodiments of this specification may be provided as methods, systems or computer program products. Therefore, this specification may take the form of a complete hardware embodiment, a complete software embodiment or an embodiment combining software and hardware. Moreover, this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0214] This specification may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. This specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules may be located in local and remote computer storage media, including storage devices.

[0215] Each embodiment in this specification is described in a progressive manner. For the same or similar parts among the embodiments, reference can be made to each other. 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 for the relevant parts, reference can be made to the partial description of the method embodiment.

[0216] The above description is only for the embodiments of this specification and is not intended to limit this specification. For those skilled in the art, various modifications and changes can be made to this specification. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of this specification shall be included within the scope of the claims of this specification.

Claims

1. A method for non-sensing identity verification in a weak network environment, the method comprising: Responding to a payment verification request triggered by a payment terminal in a weak network environment, and determining a payment scenario recognition result corresponding to the payment verification request; Determining a risk assessment result of the payment verification request according to the payment scenario identification result; Determining at least one semi-offline identity authentication method based on the payment scenario identification result and the risk assessment result; The payment terminal is authenticated by the semi-offline identity authentication method, and a semi-offline identity authentication result is determined, so as to complete the payment authentication request by means of the semi-offline identity authentication result.

2. According to the method for non-sense identity verification in a weak network environment of claim 1, the determining of at least one semi-offline identity verification method based on the payment scenario recognition result and the risk assessment result comprises: Determine scene feature data of the payment scene recognition result; According to the scenario feature data, matching and determining candidate semi-offline identity authentication methods from a preset identity authentication support library; The candidate semi-offline identity authentication methods are filtered based on the risk assessment result to obtain at least one semi-offline identity authentication method for verifying the payment terminal.

3. The method for non-sense identity verification in a weak network environment according to claim 1 or 2, wherein the identity verification of the payment terminal is performed by the semi-offline identity verification method, comprising: Determine the authentication method identification data corresponding to the semi-offline identity authentication method; The identity authentication interface corresponding to the semi-offline identity authentication method is called according to the verification method identification data, so as to authenticate the payment terminal by calling the identity authentication logic through the identity authentication interface.

4. According to the method for non-sense identity verification in a weak network environment of claim 3, the semi-offline identity verification method includes a time-synchronized one-time password verification method, and the identity verification logic is called through the identity verification interface corresponding to the time-synchronized one-time password verification method to authenticate the payment terminal, including: Acquire a first time dynamic password included in the payment verification request, where the first time dynamic password is generated by the payment terminal based on a first timestamp, a preset time window and a shared key; Calculate a second time dynamic password according to the preset time window, the shared key and the collected second timestamp; The first-time dynamic password and the second-time dynamic password are matched and verified, and a semi-offline identity authentication result is determined according to the matching verification result.

5. According to the method for non-sense identity verification in a weak network environment of claim 4, the step of calculating the second time dynamic password according to the preset time window, the shared key and the collected second timestamp comprises: Determine a time window number according to the second timestamp and the preset time window; The shared key and the time window number are encrypted to obtain the second time dynamic password.

6. According to the method for non-sense identity verification in a weak network environment of claim 4, the matching and verification of the first time dynamic password and the second time dynamic password, and determining the semi-offline identity verification result by the matching and verification result, comprises: If the first-time dynamic password and the second-time dynamic password match and are successfully verified, determining that the semi-offline identity authentication result is identity authentication passed; If the matching verification of the first-time dynamic password and the second-time dynamic password fails, a new second-time dynamic password is recalculated within a nearby time window, and a matching verification is performed based on the new second-time dynamic password. If the verification is successful within the maximum number of retry verifications, the semi-offline identity authentication result is determined to be identity authentication passed; otherwise, the semi-offline identity authentication result is determined to be identity authentication failed.

7. According to the method for non-sense identity verification in a weak network environment of claim 3, the semi-offline identity verification method includes a counting-based dynamic password verification method, and the identity verification logic is called through the identity verification interface corresponding to the counting-based dynamic password verification method to authenticate the payment terminal, including: Acquire a first counting dynamic password included in the payment verification request, where the first counting dynamic password is generated by the payment end based on a first count value of a first counter and a shared key; Reading a second count value of a second counter, and calculating a second counting dynamic password according to the second count value and the shared key; The first counting dynamic password and the second counting dynamic password are matched and verified, and a semi-offline identity authentication result is determined according to the matching verification result.

8. According to the method for non-sense identity verification in a weak network environment of claim 7, the matching and verification of the first counting dynamic password and the second counting dynamic password, and determining the semi-offline identity verification result by the matching and verification result, comprises: If the first counting dynamic password and the second counting dynamic password match and are verified successfully, determining that the semi-offline identity authentication result is identity authentication passed; If the matching verification of the first counting dynamic password and the second counting dynamic password fails, the second counter is readjusted within the preset adjustment range to obtain a new second counting value, and a new second counting dynamic password is calculated according to the new second counting value, and a matching verification is performed according to the new second counting dynamic password. If the verification is successful within the maximum number of retry verifications, the semi-offline identity authentication result is determined to be identity authentication passed, otherwise the semi-offline identity authentication result is determined to be identity authentication failed.

9. According to the method for non-sense identity verification in a weak network environment of claim 3, the semi-offline identity verification method includes an authentication method based on a public key infrastructure, and the authentication logic is called through the authentication interface corresponding to the authentication method based on the public key infrastructure to authenticate the payment terminal, including: Obtaining signature information and a digital certificate contained in the payment verification request, wherein the signature information is obtained by the payment terminal encrypting the received original challenge message; If the validity verification of the digital certificate passes, the signature information is decrypted using the public key stored in the digital certificate to obtain decryption challenge information; The decrypted challenge information and the original challenge message are matched and verified, and a semi-offline identity authentication result is determined based on the matching verification result.

10. According to the method for non-sense identity verification in a weak network environment of claim 1, the step of determining the risk assessment result of the payment verification request according to the payment scenario recognition result comprises: Obtaining historical payment behavior data associated with the payment verification request; The risk assessment result of the payment verification request is determined based on the payment scenario identification result and the historical payment behavior data.

11. According to the method for non-sense identity verification in a weak network environment of claim 10, the step of determining the risk assessment result of the payment verification request by using the payment scenario recognition result and the historical behavior data comprises: Constructing a multi-dimensional payment feature vector through the payment scenario recognition result and the historical behavior data; Inputting the multi-dimensional payment feature vector into a payment risk assessment model to obtain a risk assessment score, and determining the payment risk level according to the risk assessment score; A risk assessment result of the payment verification request is determined based on the payment risk level.

12. A non-sensing identity verification device in a weak network environment, the device comprising: A payment scenario recognition module, used to respond to a payment verification request triggered by a payment terminal in a weak network environment, and determine a payment scenario recognition result corresponding to the payment verification request; A payment risk assessment module, used to determine a risk assessment result of the payment verification request according to the payment scenario identification result; An identity authentication adaptation module, configured to determine at least one semi-offline identity authentication method based on the payment scenario identification result and the risk assessment result; The senseless identity verification module is used to authenticate the payment terminal through the semi-offline identity verification method, determine the semi-offline identity verification result, and complete the payment verification request through the semi-offline identity verification result.

13. A storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 11 are implemented.

14. An electronic device, characterized in that: include: A processor and a memory; wherein the memory stores a computer program, and the computer program is suitable for being loaded by the processor and executing the steps of the method as claimed in any one of claims 1 to 11.

15. A computer program product having at least one instruction stored thereon, characterized in that: When the at least one instruction is executed by the processor, the steps of the method described in any one of claims 1 to 11 are implemented.

Images