An OTP authentication method, device and electronic equipment for financial services

Abstract

The application discloses an OTP verification method and device for financial services and electronic equipment, and the method comprises the following steps: obtaining financial service data sent by a merchant background; analyzing the financial service data to obtain and record financial service parameters, and generating an OTP token based on the financial service parameters, and returning the OTP token to the merchant background; obtaining financial service parameters, an OTP token, an OTP verification code and a service interface to be called sent by the merchant background, and judging whether the OTP verification code is verified; if the OTP verification result is verified, the financial service parameters and the OTP verification parameters are forwarded to the corresponding service interface; obtaining the service result returned by the service interface, and returning the service result to the merchant background. The application can realize the unification of the OTP verification standard, and the user only needs to make an OTP authentication once to complete the whole process connection, thereby avoiding the problems of large-area information leakage and SMS attack caused by SMS bomb errors.

Description

Technical Field

[0001] This invention relates to the field of financial business technology, and in particular to an OTP verification method, apparatus and electronic device for financial business. Background Technology

[0002] Preventing SMS bombing in financial business systems is an important technology in the research and development field. It involves using certain methods to control the application's OTP (One-Time Password) algorithm and logic, and ensuring that authorized multi-party systems can complete the interaction process of integrated business.

[0003] Currently, there is no unified standard or feasible solution for preventing SMS bombing in the financial sector. Traditional OTP solutions are insufficient to protect the security of enterprise applications. Furthermore, these solutions are too simplistic and have limitations when dealing with numerous downstream systems in the financial industry. They require wrapping each interface according to the downstream interfaces, and traditional solutions cannot address the issue of sequentially calling two interfaces with OTP authentication.

[0004] Existing OTP verification methods face risks of data security and data leakage, and are prone to SMS bombing issues.

[0005] Therefore, existing technologies still need to be improved and developed. Summary of the Invention

[0006] In view of the shortcomings of the prior art, the present invention provides an OTP verification method, device and electronic device for financial business, aiming to solve the problems of data security and data leakage risks, and the easy occurrence of SMS bombing problems in the existing OTP verification methods.

[0007] The technical solution of the present invention is as follows:

[0008] The first embodiment of the present invention provides an OTP verification method for financial transactions, the method comprising:

[0009] Obtain financial business data sent from the merchant's backend;

[0010] The financial business data is parsed to obtain financial business parameters, the financial business parameters are recorded, an OTP token is generated, and the OTP token is returned to the merchant backend.

[0011] Obtain the financial business parameters, OTP token, OTP verification code, and business interface to be called sent by the merchant's backend, and determine whether to verify the OTP verification code based on the financial business parameters.

[0012] If the OTP verification code is verified, the OTP verification result and OTP verification parameters are obtained. If the OTP verification result is successful, the financial business parameters and OTP verification parameters are forwarded to the corresponding business interface.

[0013] Obtain the business result returned by the business interface and return the business result to the merchant backend.

[0014] Furthermore, the acquisition of financial transaction data sent from the merchant's backend includes:

[0015] An OTP token acquisition instruction from the merchant's backend is detected. Based on this OTP token acquisition instruction, the financial business data sent by the merchant's backend is obtained. The OTP token acquisition instruction is used to call the interface for sending OTP.

[0016] Further, the process of parsing the financial business data to obtain financial business parameters, recording the financial business parameters, generating an OTP token, and returning the OTP token to the merchant backend includes:

[0017] The financial business data is analyzed to obtain the business parameters, channel number, scenario code, and mobile phone number corresponding to the financial business.

[0018] Determine whether to search for the user's bound mobile phone number based on the scene code;

[0019] To find a user's bound mobile phone number, determine whether the sent mobile phone number is the same as the bound mobile phone number;

[0020] If the sent mobile number is the same as the bound mobile number, then the financial business parameters are recorded according to the channel number, scenario code, and mobile number, and an OTP token is generated according to the financial business parameters.

[0021] Return the OTP token to the merchant backend.

[0022] Furthermore, the step of obtaining the financial business parameters, OTP token, OTP verification code, and business interface to be called sent by the merchant's backend, and determining whether to verify the OTP verification code based on the financial business parameters, includes:

[0023] Obtain the financial business parameters, OTP token, OTP verification code and business interface to be called sent by the merchant's backend, and obtain the financial business scenario based on the scenario code;

[0024] The OTP verification is performed based on the financial business scenario.

[0025] Furthermore, if the OTP verification code is verified, the OTP verification result and OTP verification parameters are obtained. If the OTP verification result is successful, the financial business parameters and OTP verification parameters are forwarded to the corresponding business interface, including:

[0026] If the OTP verification code is verified, the verification result, OTP transaction number, and OTP session identifier are obtained. If the OTP verification result is successful, the verification result is returned to the merchant backend, and the financial business parameters and OTP transaction number are forwarded to the corresponding business interface.

[0027] Furthermore, the step of obtaining the financial business parameters, OTP token, OTP verification code, and business interface to be called sent by the merchant's backend, and determining whether to verify the OTP verification code based on the financial business parameters, further includes:

[0028] If OTP verification is not required, the financial service parameters are forwarded to the corresponding service interface.

[0029] Furthermore, the step of obtaining the financial business parameters, OTP token, OTP verification code, and business interface to be called sent by the merchant's backend, and determining whether to verify the OTP verification code based on the financial business parameters, further includes:

[0030] If the OTP verification code is verified, the OTP verification result and OTP verification parameters are obtained. If the OTP verification result is a verification failure, the merchant's backend is prohibited from calling the business interface.

[0031] Another embodiment of the present invention provides an OTP verification device for financial transactions, the device comprising:

[0032] The data acquisition module is used to acquire financial business data sent by the merchant's backend.

[0033] The data parsing and recording module is used to parse the financial business data, obtain financial business parameters, record the financial business parameters, generate an OTP token, and return the OTP token to the merchant backend.

[0034] The judgment module is used to obtain the financial business parameters, OTP token, OTP verification code and business interface to be called sent by the merchant's backend, and determine whether to verify the OTP verification code based on the financial business parameters.

[0035] The verification module is used to obtain the OTP verification result and OTP verification parameters if the OTP verification code is verified, and forward the financial business parameters and OTP verification parameters to the corresponding business interface if the OTP verification result is successful.

[0036] The business result return module is used to obtain the business result returned by the business interface and return the business result to the merchant backend.

[0037] Another embodiment of the present invention provides an electronic device, the electronic device including at least one processor; and,

[0038] A memory communicatively connected to the at least one processor; wherein,

[0039] The memory stores instructions that can be executed by the at least one processor, which enables the at least one processor to perform the aforementioned OTP verification method for financial transactions.

[0040] Another embodiment of the present invention provides a non-volatile computer-readable storage medium storing computer-executable instructions that, when executed by one or more processors, cause the one or more processors to perform the above-described OTP verification method for financial transactions.

[0041] Beneficial Effects: The OTP verification method for financial transactions in this invention achieves a unified OTP verification standard and can be directly ported to other financial systems. Furthermore, by employing a unified OTP authentication algorithm, users only need to perform OTP authentication once to complete the entire process, avoiding large-scale information leakage and SMS attacks caused by SMS bombing errors or malicious behavior. Attached Figure Description

[0042] The present invention will be further described below with reference to the accompanying drawings and embodiments. In the accompanying drawings:

[0043] Figure 1 This is a flowchart of a preferred embodiment of an OTP verification method for financial business according to the present invention;

[0044] Figure 2 This is a schematic diagram of the functional modules of a preferred embodiment of an OTP verification device for financial business according to the present invention;

[0045] Figure 3 This is a schematic diagram of the hardware structure of a preferred embodiment of an electronic device according to the present invention. Detailed Implementation

[0046] To make the objectives, technical solutions, and effects of this invention clearer and more explicit, the invention is further described in detail below. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0047] The embodiments of the present invention will be described below with reference to the accompanying drawings.

[0048] To address the aforementioned issues, embodiments of the present invention provide an OTP verification method for financial transactions. Please refer to [link / reference]. Figure 1 , Figure 1 This is a flowchart illustrating a preferred embodiment of an OTP verification method for financial transactions according to the present invention. Figure 1 As shown, it includes:

[0049] Step S100: Obtain financial business data sent by the merchant's backend;

[0050] Step S200: Parse the financial business data to obtain financial business parameters, record the financial business parameters, generate an OTP token, and return the OTP token to the merchant backend;

[0051] Step S300: Obtain the financial business parameters, OTP token, OTP verification code and business interface to be called sent by the merchant backend. Determine whether to verify the OTP verification code based on the financial business parameters. If yes, proceed to step S400; otherwise, proceed to step S500.

[0052] Step S400: Obtain the OTP verification result and OTP verification parameters. If the OTP verification result is successful, forward the financial business parameters and OTP verification parameters to the corresponding business interface.

[0053] Step S500: Forward the financial business parameters to the corresponding business interface;

[0054] Step S600: Obtain the business result returned by the business interface and return the business result to the merchant backend.

[0055] In specific implementation, this embodiment of the invention is applied to detect the OTP interface call instruction of the merchant's backend, obtain the financial business data sent by the merchant's backend; parse the financial business data, record the financial business parameters, generate an OTP token based on the financial business parameters, and return the OTP token to the merchant's backend;

[0056] Based on the merchant backend calling the business interface, the financial business parameters, OTP token and OTP verification code and the business interface to be called are forwarded.

[0057] Determine whether OTP verification is required based on financial business parameters; if verification is required, strictly compare the OTP data sent and verify the OTP result; return the verification result, serial number, and OTP session identifier; based on the verification result, determine whether to call the business interface; if the business interface needs to be called, upload the business parameters and OTP serial number to the corresponding business interface; obtain the data returned by the business interface and send it to the merchant backend.

[0058] By establishing an OTP authentication security strategy, for a single system interface containing multiple atomic interfaces, a logical algorithm is used to process them into a unified OTP authentication. This allows users to complete the entire process with only one OTP authentication, effectively solving the problem of SMS bombing. A complete, standard, secure, and reliable OTP solution for preventing SMS bombing is provided.

[0059] In one embodiment, obtaining financial transaction data sent by the merchant's backend includes:

[0060] An OTP token acquisition instruction from the merchant's backend is detected. Based on this OTP token acquisition instruction, the financial business data sent by the merchant's backend is obtained. The OTP token acquisition instruction is used to call the interface for sending OTP.

[0061] In practice, when a merchant's backend wants to call the OTP sending interface, it calls the OTP sending interface to send financial business data to the access gateway.

[0062] In one embodiment, the financial transaction data is parsed to obtain financial transaction parameters, the financial transaction parameters are recorded, an OTP token is generated, and the OTP token is returned to the merchant backend, including:

[0063] The financial business data is analyzed to obtain the business parameters, channel number, scenario code, and mobile phone number corresponding to the financial business.

[0064] Determine whether to search for the user's bound mobile phone number based on the scene code;

[0065] To find a user's bound mobile phone number, determine whether the sent mobile phone number is the same as the bound mobile phone number;

[0066] If the sent mobile number is the same as the bound mobile number, then the financial business parameters are recorded according to the channel number, scenario code, and mobile number, and an OTP token is generated according to the financial business parameters.

[0067] Return the OTP token to the merchant backend.

[0068] In practice, after the access gateway verifies and decrypts the signature, it obtains financial business parameters such as business parameters, channel number, scenario code, and mobile phone number. The data is then sent to the open API via Dubbo.

[0069] The open API determines whether to look up the user's bound mobile phone number based on the scenario and sends the data to the OTP public component. If it is necessary to look up the user's bound mobile phone number, it obtains the appid, scenario code, and mobile phone number from the OTP public component, records the business parameters, and returns the OTP token to the merchant's backend via the open API.

[0070] In one embodiment, obtaining financial business parameters, OTP token, OTP verification code, and the business interface to be called sent by the merchant's backend, and determining whether to verify the OTP verification code based on the financial business parameters, includes:

[0071] Obtain the financial business parameters, OTP token, OTP verification code and business interface to be called sent by the merchant's backend, and obtain the financial business scenario based on the scenario code;

[0072] The OTP verification is performed based on the financial business scenario.

[0073] In practice, the system obtains the financial business parameters, OTP token, OTP verification code, and business interface to be called sent by the merchant's backend, and obtains the financial business scenario based on the scenario code.

[0074] Depending on the specific business scenario, merchants can choose whether to submit data. If the security level is low and the system already has data, submission is not required. If the business scenario has high security requirements, the system supports proactive inspection and strict comparison, resulting in better system flexibility and security.

[0075] In one embodiment, if the OTP verification code is verified, the OTP verification result and OTP verification parameters are obtained. If the OTP verification result is successful, the financial business parameters and OTP verification parameters are forwarded to the corresponding business interface, including:

[0076] If the OTP verification code is verified, the verification result, OTP transaction number, and OTP session identifier are obtained. If the OTP verification result is successful, the verification result is returned to the merchant backend, and the financial business parameters and OTP transaction number are forwarded to the corresponding business interface.

[0077] In practical implementation, to prevent SMS bombing, multiple modes are supported. Different restriction policies can be implemented based on factors such as the number of merchant interface calls, the number of OTPs sent from the same mobile number, and the number of verification errors. Dynamic security restriction policies are supported; for example, if the number of verification errors exceeds N within a unit of time, the system can be locked for a certain period of time before re-verification is allowed.

[0078] If the OTP verification result is successful, the verification result will be returned to the merchant backend, and the financial business parameters and OTP serial number will be forwarded to the corresponding business interface.

[0079] In one embodiment, after obtaining the financial business parameters, OTP token, OTP verification code, and business interface to be called sent by the merchant's backend, and determining whether to verify the OTP verification code based on the financial business parameters, the method further includes:

[0080] If the OTP verification code is verified, the OTP verification result and OTP verification parameters are obtained. If the OTP verification result is a verification failure, the merchant's backend is prohibited from calling the business interface.

[0081] In practice, if the verification fails, the merchant's backend will not be allowed to call the business interface.

[0082] The present invention also provides a specific embodiment of an OTP verification method for financial transactions, as detailed below:

[0083] The merchant's backend calls the sending interface, including business parameters, but without the token and OTP verification code, and sends it to the access gateway;

[0084] After the access gateway verifies and decrypts the signature, it obtains parameters such as business parameters, channel number, scene code, and mobile phone number. The access gateway then sends these parameters to the open API via a Dubbo call.

[0085] The open API determines whether to look up the user's bound mobile phone number based on the scenario. If the bound mobile phone number is found, the parameters are sent to the OTP public component.

[0086] The OTP public component records business parameters based on the appid channel code, scenario code, and mobile phone number, and returns an OTP token to the open API.

[0087] The open API returns an OTP token to the access gateway;

[0088] The access gateway returns an OTP token to the merchant's backend;

[0089] The merchant backend calls the actual business interface, sending the business parameters, OTP token, and OTP verification code to the access gateway;

[0090] The access gateway forwards data to the open API via Dubbo;

[0091] Send business parameters, OTP tokens, and OTP verification codes to the OTP public component via the open API;

[0092] The OTP public components were rigorously compared to verify the OTP results.

[0093] The OTP public component returns the verification result, OTP serial number, and OTP session identifier;

[0094] The open API determines whether to call the business interface based on the verification result.

[0095] If the open API calls a business interface, it sends the business parameters and OTP serial number to the business interface.

[0096] The business results obtained from the business interface are returned to the merchant's backend.

[0097] This invention supports multiple scenarios and multiple verification modes. OTP transmission and verification are uniformly provided by the system security component. It also supports downstream atomic interface OTP functionality, where transmission and verification are handled by the downstream interface. The basic platform does not participate in OTP authentication but only performs parameter transmission, resulting in high system flexibility and loose coupling.

[0098] Business parameters can be customized according to the business scenario code. When sending OTP verification, the system automatically records the business parameters. When verifying the OTP token, the system supports automatic comparison and verification.

[0099] The OTP verification method for financial business in this invention forms a complete, standard, and universal solution for preventing SMS bombing in financial business systems. It supports multiple verification strategies and can implement dynamic security restrictions through custom strategies such as the number of merchant interface calls, the number of OTPs sent from the same mobile number, and the number of verification errors. The overall security and availability of the application can be improved by 80%.

[0100] The system is highly flexible and loosely coupled, which greatly reduces the threshold for developing and applying OTP in the field. At the same time, the solution does not depend on upstream and downstream systems. At the system level, the pluggable mode reduces the difficulty of connecting upstream and downstream systems, and the manpower cost of connection can be reduced by 70%.

[0101] Achieving a unified OTP authentication standard allows for direct portability to other financial systems. Furthermore, employing a unified logical algorithm for OTP authentication enables users to complete the entire process with only a single OTP authentication, preventing widespread information leaks and SMS attacks caused by SMS bombing errors or malicious activity.

[0102] It should be noted that there is no necessary order between the above steps. Those skilled in the art will understand from the description of the embodiments of the present invention that the above steps may have different execution orders in different embodiments, that is, they may be executed in parallel or in turn, etc.

[0103] Another embodiment of the present invention provides an OTP verification device for financial transactions, such as... Figure 2 As shown, device 1 includes:

[0104] Data acquisition module 11 is used to acquire financial business data sent by the merchant's backend;

[0105] The data parsing and recording module 12 is used to parse the financial business data, obtain financial business parameters, record the financial business parameters, generate an OTP token, and return the OTP token to the merchant backend.

[0106] The judgment module 13 is used to obtain the financial business parameters, OTP token, OTP verification code and business interface to be called sent by the merchant's backend, and to determine whether to verify the OTP verification code based on the financial business parameters.

[0107] The verification module 14 is used to obtain the OTP verification result and OTP verification parameters if the OTP verification code is verified, and forward the financial business parameters and OTP verification parameters to the corresponding business interface if the OTP verification result is successful.

[0108] The business result return module 15 is used to obtain the business result returned by the business interface and return the business result to the merchant backend.

[0109] For specific implementation details, please refer to the method embodiment; they will not be repeated here.

[0110] In one embodiment, the data acquisition module 11 is specifically used for:

[0111] An OTP token acquisition instruction from the merchant's backend is detected. Based on this OTP token acquisition instruction, the financial business data sent by the merchant's backend is obtained. The OTP token acquisition instruction is used to call the interface for sending OTP.

[0112] For specific implementation details, please refer to the method embodiment; they will not be repeated here.

[0113] In one embodiment, the data parsing and recording module 12 is specifically used for:

[0114] The financial business data is analyzed to obtain the business parameters, channel number, scenario code, and mobile phone number corresponding to the financial business.

[0115] Determine whether to search for the user's bound mobile phone number based on the scene code;

[0116] To find a user's bound mobile phone number, determine whether the sent mobile phone number is the same as the bound mobile phone number;

[0117] If the sent mobile number is the same as the bound mobile number, then the financial business parameters are recorded according to the channel number, scenario code, and mobile number, and an OTP token is generated according to the financial business parameters.

[0118] Return the OTP token to the merchant backend.

[0119] For specific implementation details, please refer to the method embodiment; they will not be repeated here.

[0120] In one embodiment, the determination module 13 is specifically used for:

[0121] Obtain the financial business parameters, OTP token, OTP verification code and business interface to be called sent by the merchant's backend, and obtain the financial business scenario based on the scenario code;

[0122] The OTP verification is performed based on the financial business scenario.

[0123] For specific implementation details, please refer to the method embodiment; they will not be repeated here.

[0124] In one embodiment, the verification module 14 is specifically used for:

[0125] If the OTP verification code is verified, the verification result, OTP transaction number, and OTP session identifier are obtained. If the OTP verification result is successful, the verification result is returned to the merchant backend, and the financial business parameters and OTP transaction number are forwarded to the corresponding business interface.

[0126] For specific implementation details, please refer to the method embodiment; they will not be repeated here.

[0127] In one embodiment, the device further includes a parameter forwarding module, which is specifically used for:

[0128] If OTP verification is not required, the financial service parameters are forwarded to the corresponding service interface.

[0129] For specific implementation details, please refer to the method embodiment; they will not be repeated here.

[0130] In one embodiment, the apparatus further includes a control module, the control module being used for:

[0131] If the OTP verification code is verified, the OTP verification result and OTP verification parameters are obtained. If the OTP verification result is a verification failure, the merchant's backend is prohibited from calling the business interface.

[0132] For specific implementation details, please refer to the method embodiment; they will not be repeated here.

[0133] Another embodiment of the present invention provides an electronic device, such as... Figure 3 As shown, the electronic device 10 includes:

[0134] One or more processors 110 and memory 120, Figure 3 The following description uses a processor 110 as an example. The processor 110 and the memory 120 can be connected via a bus or other means. Figure 3 Taking the example of a connection between China and Israel via a bus.

[0135] Processor 110 is used to perform various control logics of electronic device 10. It can be a general-purpose processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), microcontroller, ARM (Acorn RISC Machine) or other programmable logic device, discrete gate or transistor logic, discrete hardware controls, or any combination of these components. Furthermore, processor 110 can also be any conventional processor, microprocessor, or state machine. Processor 110 can also be implemented as a combination of computing devices, such as a combination of DSP and microprocessor, multiple microprocessors, one or more microprocessors combined with a DSP core, or any other such configuration.

[0136] The memory 120, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the program instructions corresponding to the OTP verification method for financial business in the embodiments of the present invention. The processor 110 executes various functional applications and data processing of the device 10 by running the non-volatile software programs, instructions, and units stored in the memory 120, thereby implementing the OTP verification method for financial business in the above method embodiments.

[0137] The memory 120 may include a program storage area and a data storage area, wherein the program storage area may store applications required for operating the device and at least one function; and the data storage area may store data created according to the use of the device 10. Furthermore, the memory 120 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory 120 may optionally include memory remotely located relative to the processor 110, and these remote memories may be connected to the device 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0138] One or more units are stored in memory 120, and when executed by one or more processors 110, they perform the OTP verification method for financial business in any of the above method embodiments, for example, the method described above. Figure 1 The method steps S100 to S600.

[0139] This invention provides a non-volatile computer-readable storage medium storing computer-executable instructions that are executed by one or more processors, for example, to perform the operations described above. Figure 1 The method steps S100 to S600.

[0140] As an example, non-volatile storage media can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) as an external cache memory. By way of illustration and not limitation, RAM can be obtained in many forms such as synchronous RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), Synchronous ink DRAM (SLDRAM), and direct Rambus RAM (DRRAM). The memory controls or memories disclosed in the operating environment described herein are intended to include one or more of these and / or any other suitable types of memory.

[0141] Another embodiment of the present invention provides a computer program product comprising a computer program stored on a non-volatile computer-readable storage medium. The computer program includes program instructions that, when executed by a processor, cause the processor to perform the OTP verification method for financial transactions described in the above-described method embodiments. For example, performing the above-described... Figure 1 The method steps S100 to S600.

[0142] The embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0143] Through the description of the above embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus a general-purpose hardware platform, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the parts that contribute to the related technology, can be embodied in the form of a software product. This computer software product can exist in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods of various embodiments or some parts of embodiments.

[0144] Among other things, conditional language such as “can,” “may,” “may,” or “may,” unless otherwise specifically stated or otherwise understood as in the context in which they are used, is generally intended to convey that a particular implementation may include (but not others) certain features, elements, and / or operations. Therefore, such conditional language is also generally intended to imply that features, elements, and / or operations are necessary for one or more implementations in any way, or that one or more implementations must include logic for determining, with or without input or prompting, whether such features, elements, and / or operations are included or will be performed in any particular implementation.

[0145] The contents already described herein in this specification and accompanying drawings include examples of OTP verification methods and apparatus capable of providing financial transactions. It is certainly not possible to describe every conceivable combination of elements and / or methods for the purpose of describing the various features of this disclosure, but it will be appreciated that many other combinations and substitutions of the disclosed features are possible. Therefore, it will be apparent that various modifications can be made to this disclosure without departing from the scope or spirit of this disclosure. Furthermore, or in alternatives, other embodiments of this disclosure may become apparent from consideration of this specification and accompanying drawings and from the practice of this disclosure as presented herein. It is intended that the examples presented in this specification and accompanying drawings be considered illustrative rather than restrictive in all respects. Although specific terminology is used herein, it is used in a general and descriptive sense and is not intended for limiting purposes.

Claims

1. An OTP verification method for financial transactions, characterized in that... The method includes: Obtain financial business data sent from the merchant's backend; The financial business data is parsed to obtain financial business parameters, the financial business parameters are recorded, an OTP token is generated, and the OTP token is returned to the merchant backend. Based on the merchant backend calling the business interface, the financial business parameters, OTP token and OTP verification code and the called business interface are forwarded. Obtain the financial business parameters, OTP token, OTP verification code, and business interfaces to be called sent by the merchant's backend; Determine whether to verify the OTP verification code based on the aforementioned financial business parameters; If the business interface to be called is a single system interface and contains multiple atomic interfaces, then a logical algorithm is used to process it into a unified OTP authentication, and then the verification judgment is performed. If the OTP verification code is verified, the OTP verification result and OTP verification parameters are obtained. If the OTP verification result is successful, the financial business parameters and OTP verification parameters are forwarded to the corresponding business interface. Obtain the business result returned by the business interface and return the business result to the merchant backend; The acquisition of financial business data sent from the merchant's backend includes: An OTP token acquisition instruction from the merchant's backend is detected. Based on the OTP token acquisition instruction, financial transaction data sent by the merchant's backend is obtained. The OTP token acquisition instruction is used to call the interface for sending OTP. The process of parsing the financial business data to obtain financial business parameters, recording the financial business parameters, generating an OTP token, and returning the OTP token to the merchant backend includes: The financial business data is parsed to obtain the business parameters, channel number, scenario code, and mobile phone number corresponding to the financial business. Determine whether to search for the user's bound mobile phone number based on the scene code; To find a user's bound mobile phone number, determine whether the sent mobile phone number is the same as the bound mobile phone number; If the sent mobile number is the same as the bound mobile number, then the financial business parameters are recorded according to the channel number, scenario code, and mobile number, and an OTP token is generated according to the financial business parameters. Return the OTP token to the merchant backend.

2. The method according to claim 1, characterized in that, The process of obtaining the financial business parameters, OTP token, OTP verification code, and the business interface to be called sent by the merchant's backend, and determining whether to verify the OTP verification code based on the financial business parameters, includes: Obtain the financial business parameters, OTP token, OTP verification code and business interface to be called sent by the merchant's backend, and obtain the financial business scenario based on the scenario code; The OTP verification is performed based on the financial business scenario.

3. The method according to claim 2, characterized in that, If the OTP verification code is verified, the OTP verification result and OTP verification parameters are obtained. If the OTP verification result is successful, the financial business parameters and OTP verification parameters are forwarded to the corresponding business interface, including: If the OTP verification code is verified, the verification result, OTP serial number, and OTP session identifier can be obtained. If the OTP verification result is successful, the verification result will be returned to the merchant backend, and the financial business parameters and OTP serial number will be forwarded to the corresponding business interface.

4. The method according to claim 3, characterized in that, The process of obtaining the financial business parameters, OTP token, OTP verification code, and business interface to be called sent by the merchant's backend, and determining whether to verify the OTP verification code based on the financial business parameters, further includes: If OTP verification is not required, the financial service parameters are forwarded to the corresponding service interface.

5. The method according to claim 4, characterized in that, The process of obtaining the financial business parameters, OTP token, OTP verification code, and business interface to be called sent by the merchant's backend, and determining whether to verify the OTP verification code based on the financial business parameters, further includes: If the OTP verification code is verified, the OTP verification result and OTP verification parameters are obtained. If the OTP verification result is a verification failure, the merchant's backend is prohibited from calling the business interface.

6. An OTP verification device for financial transactions, characterized in that, The device includes: The data acquisition module is used to acquire financial business data sent by the merchant's backend. The data parsing and recording module is used to parse the financial business data, obtain financial business parameters, record the financial business parameters, generate an OTP token, and return the OTP token to the merchant backend. The judgment module is used to obtain the financial business parameters, OTP token, OTP verification code and business interface to be called sent by the merchant's backend, and determine whether to verify the OTP verification code based on the financial business parameters. The verification module is used to obtain the OTP verification result and the OTP if the OTP verification code is verified. Verify the parameters. If the OTP verification result is successful, forward the financial business parameters and OTP verification parameters to the corresponding business interface. The business result return module is used to obtain the business result returned by the business interface and return the business result to the merchant backend; The acquisition of financial business data sent from the merchant's backend includes: An OTP token acquisition instruction from the merchant's backend is detected. Based on the OTP token acquisition instruction, financial transaction data sent by the merchant's backend is obtained. The OTP token acquisition instruction is used to call the interface for sending OTP. The process of parsing the financial business data to obtain financial business parameters, recording the financial business parameters, generating an OTP token, and returning the OTP token to the merchant backend includes: The financial business data is parsed to obtain the business parameters, channel number, scenario code, and mobile phone number corresponding to the financial business. Determine whether to search for the user's bound mobile phone number based on the scene code; To find a user's bound mobile phone number, determine whether the sent mobile phone number is the same as the bound mobile phone number; If the sent mobile number is the same as the bound mobile number, then the financial business parameters are recorded according to the channel number, scenario code, and mobile number, and an OTP token is generated according to the financial business parameters. Return the OTP token to the merchant backend; Based on the merchant backend calling the business interface, the financial business parameters, OTP token and OTP verification code and the called business interface are forwarded. If the business interface to be called is a single system interface and contains multiple atomic interfaces, then a logical algorithm is used to process it into a unified OTP authentication, and then the verification judgment is performed.

7. An electronic device, characterized in that, The electronic device includes at least one processor; and a memory communicatively connected to the at least one processor; wherein... The memory stores instructions executable by the at least one processor, which, when executed, enable the at least one processor to perform the OTP verification method for financial transactions as described in any one of claims 1-5.

8. A non-volatile computer-readable storage medium, characterized in that, The non-volatile computer-readable storage medium stores computer-executable instructions that, when executed by one or more processors, cause the one or more processors to perform the OTP verification method for financial transactions as described in any one of claims 1-5.

Images