Account management methods, terminals, servers, electronic devices and storage media

Abstract

This application discloses an account management method, terminal, server, electronic device, and storage medium. The method includes: a client obtaining the type of a payment operation; generating a corresponding client signature based on the client's user identifier and the type of payment operation; sending an authentication request for the payment operation and the client signature to a server, so that the server performs payment authentication based on at least one client signature; and receiving a virtual payment account returned by the server after successful authentication. Through the above methods, this application enables more secure and flexible management of virtual payment accounts.

Description

Technical Field

[0001] This application relates to the field of online payment technology, and in particular to an account management method, terminal, server, electronic device and storage medium. Background Technology

[0002] UPI (Unify Payment Interface) is a mainstream payment method that is becoming increasingly popular in India. Third-party payment platforms need to build business scenarios (such as phone bill top-ups, water, electricity, and gas bill payments) on top of UPI's basic payment capabilities. When a user makes a payment, they first pay the third-party platform, which then obtains the corresponding VPA (Virtual Payment Account) for that business scenario and completes the top-up based on the VPA. Summary of the Invention

[0003] The first aspect of this application provides an account management method, which includes: a client obtaining the type of a payment operation; generating a corresponding client signature based on the client's user identifier and the type of payment operation; sending an authentication request for the payment operation and the client signature to a server, so that the server performs payment authentication based on at least one client signature; and receiving a virtual payment account returned by the server after successful authentication by the server.

[0004] A second aspect of this application provides an account management method, which includes: a server receiving an authentication request for a payment operation and a client signature sent by a client; wherein the client signature is generated based on the client's user identifier and the type of payment operation; performing payment authentication based on at least one client signature; and sending a virtual payment account to the client upon successful authentication.

[0005] A third aspect of this application provides a mobile terminal, comprising: an acquisition module for acquiring the type of a payment operation; a signature module for generating a corresponding client signature based on the client's user identifier and the type of payment operation; a sending module for sending an authentication request for the payment operation and the client signature to a server, so that the server performs payment authentication based on at least one client signature; and a receiving module for receiving a virtual payment account returned by the server after successful authentication.

[0006] A fourth aspect of this application provides a server comprising: a receiving module for receiving an authentication request for a payment operation and a client signature sent by a client; wherein the client signature is generated based on the client's user identifier and the type of payment operation; an authentication module for performing payment authentication based on at least one client signature; and a sending module for sending a virtual payment account to the client upon successful authentication.

[0007] The fifth aspect of this application provides an electronic device including a processor and a memory connected to the processor, the memory being used to store program data and the processor being used to execute the program data to implement the aforementioned method.

[0008] A sixth aspect of this application provides a computer-readable storage medium storing program data, which, when executed by a processor, is used to implement the aforementioned method.

[0009] The beneficial effects of this application are as follows: Unlike existing technologies, this application obtains the type of payment operation through the client, then generates a corresponding client signature based on the client's user identifier and the type of payment operation, and sends the authentication request for the payment operation and the client signature to the server. This allows the server to perform payment authentication based on at least one client signature. After successful server authentication, the application receives a virtual payment account returned by the server. The client signature generated based on the client's user identifier and the type of payment operation binds the user's identity to the payment operation. Therefore, when the server performs payment authentication based on the client signature, it can verify the payment operation to prevent bypassing intermediate steps and improve payment security. Furthermore, the server can add corresponding virtual payment accounts for new service providers without requiring client version updates, resulting in greater flexibility. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in this application, the accompanying drawings required in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. Among them:

[0011] Figure 1 This is a flowchart illustrating an embodiment of the account management method of this application;

[0012] Figure 2 These are schematic diagrams of the display interfaces corresponding to the three payment operations in this application;

[0013] Figure 3 yes Figure 1 A flowchart illustrating another embodiment of step S102;

[0014] Figure 4 yes Figure 3 A flowchart illustrating another embodiment of step S1022;

[0015] Figure 5This is a flowchart illustrating another embodiment of the account management method of this application;

[0016] Figure 6 This is a flowchart illustrating yet another embodiment of the account management method of this application;

[0017] Figure 7 yes Figure 6 A flowchart illustrating another embodiment of step S302;

[0018] Figure 8 This is a flowchart illustrating another embodiment of the account management method of this application;

[0019] Figure 9 This is a sequence diagram of the interaction between the client and the server in this application;

[0020] Figure 10 This is a schematic block diagram of the structure of a mobile terminal according to an embodiment of this application;

[0021] Figure 11 This is a schematic block diagram of the structure of an embodiment of the server in this application;

[0022] Figure 12 This is a schematic block diagram of the structure of an embodiment of the electronic device of this application;

[0023] Figure 13 This is a schematic block diagram of an embodiment of a computer-readable storage medium of this application. Detailed Implementation

[0024] In this application, the reference to "embodiment" means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0025] The terms "first" and "second" in this application are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such processes, methods, products, or apparatus.

[0026] Currently, third-party platforms (such as Paytm, Google Pay, MiPay, and PhonePE) mainly use the following two methods to obtain VPAs: One method is to hardcode the VPA in the client. However, in this method, the VPA is easily tampered with and changed to other accounts. In addition, the client needs to update its version every time a new service provider is introduced, which is costly and inflexible. The other method is to encrypt the VPA on the server side and then send it to the client. The encryption key is fixed. This method can easily pull all VPAs directly in one interface, causing VPA leakage.

[0027] Based on this, this application provides a secure and flexible account management method for managing Virtual Payment Accounts (VPAs). Specifically, the client generates a corresponding client signature based on the user identifier and the type of payment operation, and then uses this client signature to authenticate the payment with the server. Only after successful payment authentication by the server will the corresponding VPA be issued, resulting in higher security. Secondly, the server considers the client's user identifier and the type of payment operation during authentication, ensuring that each user and each type of payment operation uniquely corresponds to a client signature, rather than directly issuing the VPA when the client requests it, further enhancing security. Furthermore, the server can add corresponding VPAs for new service providers without requiring client version updates, providing greater flexibility.

[0028] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0029] Please see Figures 1-2 , Figure 1 This is a flowchart illustrating an embodiment of the account management method of this application. Figure 2 This is a schematic diagram of the display interface corresponding to the three payment operations of this application. In this embodiment, the executing entity is a client, such as a mobile terminal like a mobile phone, tablet computer, personal computer, or smart wearable device.

[0030] The method may include the following steps:

[0031] Step S101: The client obtains the type of payment operation.

[0032] Payment operations refer to the actions performed by the user during the payment process.

[0033] Generally, in a standard payment process, the user first selects the type of service to be paid for, then creates an order, and finally pays for the order. Correspondingly, in some implementations, the types of payment operations include, but are not limited to, at least one of the following: selecting a service type, creating an order, and paying for an order. In other implementations, the types of payment operations can be categorized according to the actual situation. For example, in some application scenarios, the user automatically pays for the order when creating it, and in this case, the user no longer needs to perform a separate payment operation; therefore, the user's payment operation can be divided into creating and paying for an order.

[0034] Among them, the operation of selecting a business type is, for example, selecting a business entry for the user; the operation of creating an order is, for example, selecting an order for a certain scenario for the user; and the operation of paying an order is, for example, clicking the payment button for the user.

[0035] In one specific implementation, such as Figure 2 As shown, time points t1, t2, and t3 correspond to three payment operations, respectively. Taking a mobile phone as an example, the display interface 11 of mobile phone 10 displays the content corresponding to the three payment operations at the three time points. Specifically, time point t1 corresponds to the operation of selecting a service type, time point t2 corresponds to the operation of creating an order, and time point t3 corresponds to the operation of paying for an order. In this implementation scenario, when the user clicks the "Electricity Bill Recharge" button, it means that the user has selected the service type of electricity bill recharge. Correspondingly, the type of payment operation obtained by the client is the operation of selecting a service type. Furthermore, the display interface displays the content of the "Electricity Bill Recharge" service, including multiple recharge amounts, such as 30 yuan, 50 yuan, etc. When the user clicks the "50 yuan" button, it means that the user has confirmed the creation of a 50 yuan phone bill recharge order. Correspondingly, the type of payment operation obtained by the client is the operation of creating an order. Furthermore, the display interface displays the content of the payment order, including the recharge amount, service type, etc. When the user clicks the "Pay Now" button, it means that the user has paid for the order. Correspondingly, the type of payment operation obtained by the client is the operation of paying for an order.

[0036] Step S102: Generate the corresponding client signature based on the client's user identifier and the type of payment operation.

[0037] The User Identifier (UID), or User Identity, is a unique identifier for each user. A User Identifier can be the account used to log in to the client (including an ID card number, mobile phone number, etc.), or a pre-set identifier used to uniquely identify the user.

[0038] In some implementations, each payment operation corresponds to an identifier, so that the client's user identifier and the identifier corresponding to the type of payment operation can be used as part of the authentication request interface for the corresponding payment operation to generate a client signature.

[0039] In one specific implementation, the client's user identifier and the identifier corresponding to the type of payment operation can be concatenated and then used as the salt value part of the authentication request interface for the corresponding payment operation to generate the client signature corresponding to the payment operation.

[0040] Step S103: Send an authentication request for the payment operation and the client signature to the server so that the server can perform payment authentication based on at least one client signature.

[0041] Understandably, each payment operation corresponds to a client signature. Since different payment operations have a time sequence, the client can generate the corresponding client signature in the order in which each payment operation is obtained, and then send the corresponding client signature when sending the authentication request for the corresponding payment operation.

[0042] Specifically, the operation of selecting a business type corresponds to a first client signature, the operation of creating an order corresponds to a second client signature, and the operation of paying for an order corresponds to a third client signature. The client sends these three client signatures to the server in sequence. Correspondingly, the server can perform payment authentication based on at least one of these client signatures. In some implementations, the server can perform payment authentication based on only one client signature. Once the client signature is verified, the server determines that the authentication is successful and returns a virtual payment account to the client. In other implementations, the server can perform payment authentication based on multiple client signatures (such as the first, second, and third client signatures). Only after all multiple client signatures have been verified is the server determined that the authentication is successful and returns a virtual payment account to the client. This allows for verification of the entire payment process, preventing missing intermediate payment operations and improving payment security.

[0043] Step S104: After successful server authentication, receive the virtual payment account returned by the server.

[0044] Specifically, the server can encrypt the virtual payment account before returning it to the client to prevent the virtual payment account from being leaked. The encryption algorithm and key can be selected as needed and are not limited here.

[0045] The above scheme obtains the type of payment operation from the client, then generates a corresponding client signature based on the client's user identifier and the type of payment operation, and sends the payment operation authentication request and client signature to the server. This allows the server to perform payment authentication based on at least one client signature. After successful server authentication, the system receives a virtual payment account returned by the server. The client signature generated based on the client's user identifier and the type of payment operation binds the user's identity to the payment operation. Consequently, when the server performs payment authentication based on the client signature, it can verify the payment operation to prevent bypassing intermediate steps and improve payment security.

[0046] Please see Figure 3 , Figure 3 yes Figure 1 A flowchart illustrating another embodiment of step S102.

[0047] Step S102: Generate a corresponding client signature based on the client's user identifier and the type of payment operation, which may include sub-steps S1021 to S1023:

[0048] Step S1021: Based on the type of payment operation, call the corresponding function and obtain the function's offset address.

[0049] Each payment operation has a corresponding function. For example, selecting a business type, creating an order, and paying for an order each have corresponding functions. These payment operation functions can be stored in a dynamic link library (DLL). A DLL might be an SO (Android Executable Library), a dynamic library developed in C / C++ for Android. The offset addresses of the payment operation functions differ in different versions of the DLL.

[0050] In some implementations, when the dynamic link library SO is loaded and the corresponding function (e.g., a function to select a business type, a function to create an order, or a function to pay for an order) is called, the called function obtains its own offset address. The offset address is, for example, 0x0abdfc09, represented as the hexadecimal number 0abdfc09.

[0051] Step S1022: Concatenate the function's offset address and the client's user identifier to obtain the corresponding client identification code.

[0052] Understandably, the client identification code is used to bind the user identifier to the offset address of the function corresponding to each payment operation. The offset address represents the type of payment operation, thus enabling the binding of the user identifier to the payment operation. Therefore, the payment operation can be authenticated to determine whether the user is using the UPI payment function through legitimate channels.

[0053] In this implementation, the result of concatenating the function's offset address and the client's user identifier can be directly used as the client identification code. For example, if the offset address corresponding to the business type function is selected as 0x0abdfc09 and the user identifier UID is 9018902, then the two can be concatenated byte by byte to obtain the corresponding client identification code 1802229859018902, where 180222985 is the decimal representation of 0abdfc09. Alternatively, the user identifier can be concatenated first, followed by the offset address, such as 9018902180222985.

[0054] In other implementations, to enhance transmission security, the concatenation of the function's offset address and the client's user identifier can be further complicated. Even if the processed result is leaked during transmission, the function's offset address and the client's user identifier cannot be obtained. Please refer to [link to relevant documentation]. Figure 4 , Figure 4 yes Figure 3 A flowchart illustrating another embodiment of step S1022.

[0055] Specifically, step S1022 may also include sub-steps S10221 and S10222:

[0056] Step S10221: Concatenate the function's offset address and the client's user identifier, then perform a hash operation to obtain the corresponding hash value.

[0057] For example, a hash algorithm can be used to process the offset address of the concatenated function and the user identifier of the client to obtain the corresponding hash value.

[0058] A hash algorithm is a cryptographic algorithm that can only encrypt, not decrypt. Therefore, even if the hashed concatenation structure is leaked, it is difficult to obtain the original information before encryption (i.e., the function's offset address and the client's user identifier). It can convert information of arbitrary length into a fixed-length string. The five algorithms in the SHA family are SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512; the latter four can be collectively referred to as SHA-2.

[0059] In this embodiment, a suitable hash algorithm can be selected as needed to process the offset address of the concatenated function and the user identifier of the client. In some implementations, the concatenated string 1802229859018902 can be processed using the SHA-2 algorithm to obtain a 32-byte sequence number EFABJKI90933KKKUIOPLNCDJANMJKLD.

[0060] Step S10222: Extract characters from the hash value to form the corresponding client identification code.

[0061] In some implementations, strings can be extracted from the hash value and concatenated to form the corresponding client identification code, with each string spaced one character apart. For example, the 32-byte sequence number mentioned above can yield a 16-byte identifier EAJI03KKIPNDAMKD, which is the client identification code, denoted as PIN (Personal Identification Number). In other implementations, the number of spaces can be chosen according to actual needs; for example, characters can be extracted from the hash value with two or three spaces to form the corresponding client identification code. Of course, the hash value obtained after hashing can also be used directly as the client identification code.

[0062] Step S1023: Generate the corresponding client signature based on the client identification code.

[0063] Specifically, the client identification code can be used as the salt value in the authentication request interface for the corresponding payment operation to generate the corresponding client signature. The client stores a private key, which can be used to encrypt the client signature before sending it to the server.

[0064] Please see Figure 5 , Figure 5 This is a flowchart illustrating another embodiment of the account management method of this application. The executing entity in this embodiment is the client.

[0065] The method may include the following steps:

[0066] Step S201: The client obtains the type of payment operation. The type of payment operation includes at least one of the following: selecting business type operation, creating order operation, and paying order operation.

[0067] In this embodiment, when the payment operation type obtained by the client is a selection of business type operation, steps S202 and S203 are executed:

[0068] Step S202: Generate the corresponding first client signature based on the client's user identifier and the selected business type operation.

[0069] In this embodiment, the dynamic link library stores functions corresponding to the payment operation, including at least a function for selecting the business type, a function for creating an order, and a function for paying the order.

[0070] Specifically, when the payment operation is a business type selection operation, the corresponding business type selection function is called by loading the dynamic link library. When the business type selection function is called, it obtains its own offset address. Then, by concatenating the offset address of the business type selection function with the client's user identifier, the corresponding first client identification code, denoted as PIN-B, is obtained. The first client identification code is then used as the salt value part of the business type selection authentication request interface to generate the first client signature.

[0071] It is understood that there are similar parts in the client signature generation method in this application, so for more details about this step and subsequent similar steps, please refer to steps S1021 to S1023, which will not be repeated here.

[0072] Step S203: Send an authentication request for selecting the business type operation and the first client signature to the server.

[0073] At this point, the client can communicate with the server and send an authentication request for selecting a business type operation and a first client signature to the server, so that the server can verify the authentication request for selecting a business type operation based on the first client signature.

[0074] In this embodiment, when the payment operation type obtained by the client is an order creation operation, steps S204 and S205 are executed:

[0075] Step S204: Generate the corresponding second client signature based on the client's user identifier and the order creation operation.

[0076] Specifically, when the payment operation type is an order creation operation, the corresponding order creation function is called by loading the dynamic link library. When the order creation function is called, the order creation function obtains its own offset address. Then, by concatenating the offset address of the order creation function with the client's user identifier, the corresponding second client identification code is obtained, denoted as PIN-O. Then, by using the second client identification code as the salt value part of the order creation authentication request interface, a second client signature is generated.

[0077] Step S205: Send an authentication request for the order creation operation and a second client signature to the server.

[0078] At this point, the client can communicate with the server and send an authentication request for creating an order and a second client signature to the server, so that the server can verify the authentication request for creating an order based on the second client signature and retain the verification result.

[0079] In this embodiment, when the payment operation type obtained by the client is a payment order operation, steps S206 and S207 are executed:

[0080] Step S206: Generate the corresponding third-party client signature based on the client's user identifier and payment order operation.

[0081] Specifically, when the payment operation type is a payment order operation, the corresponding payment order function is called by loading the dynamic link library. When the payment order function is called, the payment order function obtains its own offset address. Then, by concatenating the offset address of the payment order function with the client's user identifier, the corresponding third client identification code is obtained, denoted as PIN-P. Then, the third client identification code is used as the salt value part of the authentication request interface of the payment order operation to generate a third client signature.

[0082] Step S207: Send the authentication request for the payment order operation and the third client signature to the server.

[0083] At this point, the client can communicate with the server and send an authentication request for the payment order operation and a third-party client signature to the server, so that the server can verify the authentication request for the payment order operation based on the third-party client signature.

[0084] Step S208: After the server successfully authenticates the client based on the first client signature, the second client signature, and the third client signature, it receives the virtual payment account returned by the server.

[0085] Finally, after the server verifies the signatures based on the first client's signature, the second client's signature, and the third client's signature, the server determines that the authentication is successful and sends the virtual payment account to the client. A detailed description of the server-side authentication process can be found in the server-side implementation examples below, and will not be elaborated upon here.

[0086] In some implementations, receiving a virtual payment account returned by the server includes: decrypting the encrypted data returned by the server using at least one client identification code and a user identifier to obtain the virtual payment account. Specifically, the server can encrypt the virtual payment account using the server identification code and the user identifier; correspondingly, the client can decrypt the encrypted data returned by the server using the client identification code and the user identifier. When the decryption key and the encryption key are the same, decryption is successful, and the virtual payment account is obtained. The use of a combination of the identification code and the user identifier as the key allows different users to use different keys, improving the security of virtual payment account transmission.

[0087] Please see Figure 6 , Figure 6 This is a flowchart illustrating another embodiment of the account management method of this application. In this embodiment, the entity executing the account management method is a server, such as a server.

[0088] The method may include the following steps:

[0089] Step S301: The server receives the authentication request for the payment operation and the client's signature sent by the client; wherein, the client signature is generated based on the client's user identifier and the type of payment operation.

[0090] In some implementations, the payment operation types include, but are not limited to, at least one of the following: selecting a service type, creating an order, and paying for an order. The server may receive authentication requests and a first client signature for selecting a service type, creating an order, and paying for an order from the client, respectively.

[0091] The first client signature is generated based on the client's user identifier and the selected business type operation; the second client signature is generated based on the client's user identifier and the order creation operation; and the third client signature is generated based on the client's user identifier and the payment order operation.

[0092] Step S302: Perform payment authentication based on at least one client signature.

[0093] The server can perform payment authentication based on one or more client signatures. For example, the server can verify the authentication request for a payment order operation based on the signature of a third client; if the verification passes, the authentication is considered successful. Alternatively, the server can verify the authentication request for the corresponding payment operation based on the signatures of a first, second, and third client respectively; the server only determines successful authentication when all three authentication requests pass verification, thus validating the entire payment process.

[0094] Step S303: After successful authentication, send the virtual payment account to the client.

[0095] After the server confirms successful authentication, it can encrypt the virtual payment account to obtain encrypted data, and then send the encrypted data containing the virtual payment account to the client. The encryption algorithm and key used to encrypt the virtual payment account can be selected according to requirements; for example, AES (Advanced Encryption Standard) can be used.

[0096] In the above scheme, the server receives the authentication request and client signature from the client for a payment operation. The client signature is generated based on the client's user identifier and the type of payment operation. Payment authentication is then performed based on at least one client signature. Upon successful authentication, a virtual payment account is sent to the client. The client signature is generated according to the user identifier and the type of payment operation, thus binding the user's identity to the payment operation. This allows the server to verify the payment operation during client signature authentication, preventing bypassing of intermediary steps and improving payment security.

[0097] Please see Figure 7 , Figure 7 yes Figure 6 A flowchart illustrating another embodiment of step S302. Step S302 may include sub-steps S3021 to S3025:

[0098] Step S3021: Process the client signature to obtain the client's user identifier.

[0099] The server stores the public key corresponding to the client's private key, where the private key is used for encryption of the signature. Specifically, the server can use the public key to decrypt the client's signature to obtain the client's user identifier.

[0100] Step S3022: Based on the client's user identifier, obtain the offset address corresponding to the payment operation.

[0101] The server can pre-store the offset address of at least one payment operation corresponding to the user identifier of the client.

[0102] In some implementations, the function corresponding to the payment operation is stored in a dynamic link library. In this embodiment, the client can extract the offset address of the function corresponding to the payment operation in the dynamic link library and then send it to the server. After receiving the offset address sent by the client, the server can associate and store the client's user identifier with the offset address, for example, in a database.

[0103] In some implementations, when the dynamic link library (DLL) is updated, the server can receive and store the offset address sent by the client. This offset address is the offset address of the function corresponding to the payment operation in the latest version of the DLL. Because the offset address of the same function differs in different versions of the DLL, the offset address stored on the server also needs to be updated when the DLL is updated to ensure consistency between the corresponding offset addresses on the client and server.

[0104] Specifically, for example, if the user identifier on the user side is 123, multiple offset addresses (A, B, C) corresponding to the user identifier 123 can be found in the database, and then the offset address (e.g., A) corresponding to the current payment operation (e.g., selecting a business type) can be obtained.

[0105] Step S3023: Generate the corresponding server identification code based on the offset address corresponding to the payment operation and the user identifier of the client.

[0106] Understandably, the way the server generates its server-side identifier is similar to how the client generates its client-side identifier, the difference being that the offset address is a pre-stored offset address on the server. For example, the offset address of the function corresponding to the payment operation can be concatenated with the client's user identifier to obtain the corresponding client-side identifier. Specifically, the function's offset address and the client's user identifier can be concatenated and then hashed to obtain the corresponding hash value. Characters from the hash value can then be extracted to form the corresponding client-side identifier.

[0107] Specifically, if either the offset address or the user identifier sent by the client is tampered with, the server-side identifier generated by the server will be inconsistent with the client-side identifier generated by the client, and thus the signatures generated using the same method will also be inconsistent.

[0108] Step S3024: Generate the corresponding server signature based on the server identification code.

[0109] Specifically, the same method as for the client can be used to process the server identification code to generate the corresponding server signature.

[0110] Based on the above steps SS3021 to S3024, the operation of selecting a business type generates a first server identification code and a first server signature, the operation of creating an order generates a second server identification code and a second server signature, and the operation of paying for an order generates a third server identification code and a third server signature.

[0111] Step S3025: When the client signature corresponding to the payment operation matches the server signature, the authentication is confirmed to be successful.

[0112] Specifically, if the client signature corresponding to the payment operation matches the server signature, it means that the client has not been cracked; otherwise, it means that the client has been cracked.

[0113] Please see Figure 8 , Figure 8 This is a flowchart illustrating another embodiment of the account management method of this application. In this embodiment, the entity executing the account management method is a server, such as a server.

[0114] The method may include the following steps:

[0115] Step S401: The server receives the authentication request for the selected service type operation and the first client signature sent by the client; wherein, the first client signature is generated based on the client's user identifier and the selected service type operation.

[0116] Step S402: Generate a first server identification code and a first server signature corresponding to the operation of selecting the business type based on the first client signature.

[0117] For a description of this step, please refer to steps S3021 to S3025, which will not be repeated here.

[0118] Step S403: When the first server signature corresponding to the selected business type operation is consistent with the first client signature, a mapping between the user identifier and the first server identification code is generated in memory.

[0119] When the first server signature corresponding to the selected business type operation matches the first client signature, it means that the authentication request for the selected business type operation has passed the signature verification. Thus, the user identifier (UID) and the first offset address can be associated and stored in memory, so that after the order is created, the order number can be associated and stored with the first offset address.

[0120] Step S404: Receive the authentication request for the create order operation and the second client signature sent by the client; wherein the second client signature is generated based on the client's user identifier and the create order operation.

[0121] Step S405: Generate a second server identification code and a second server signature corresponding to the order creation operation based on the second client signature.

[0122] For a description of this step, please refer to steps S3021 to S3025, which will not be repeated here.

[0123] Step S406: When the second server signature corresponding to the order creation operation is consistent with the second client signature, the order number, the first server identification code, and the second server identification code are associated and stored.

[0124] When the second server signature corresponding to the order creation operation matches the second client signature, it means that the authentication request for the order creation operation has passed the signature verification, and the order number, the first server identification code, and the second server identification code can be associated and stored in the database.

[0125] Step S407: Receive the authentication request for the payment order operation sent by the client and the third client signature; wherein, the third client signature is generated based on the client's user identifier and the payment order operation.

[0126] Step S408: Generate a third-server identification code and a third-server signature corresponding to the payment order operation based on the third-client signature.

[0127] For a description of this step, please refer to steps S3021 to S3025, which will not be repeated here.

[0128] Step S409: When the third-party server signature corresponding to the payment order operation matches the third-party client signature, the third-party server identification code is associated with and stored with the order number.

[0129] When the third-party server signature corresponding to the payment order operation matches the third-party client signature, it means that the authentication request for the payment order operation has passed the signature verification, and the third-party server identification code can also be associated with and stored with the order number.

[0130] Step S410: When there is a server identification code in the server identification code associated with the order number that matches the first server identification code, the second server identification code, and the third server identification code corresponding to the user identifier, the authentication is confirmed to be successful.

[0131] For example, the server-side identification codes associated with order number 789 include PIN-B and PIN-O. The first server-side identification code is PIN-B, the second server-side identification code is PIN-O, and the third server-side identification code is PIN-P. It can be seen that among the server-side identification codes associated with order number 789, only PIN-B and PIN-O, which are consistent with the first and second server-side identification codes, exist. PIN-P, which is consistent with the third server-side identification code, does not exist. This indicates that the order lacks a payment order operation or the payment order operation failed to verify the signature. Because a key operation in the payment process is missing, the authentication fails. Conversely, if the server-side identification codes associated with order number 789 are consistent with PIN-B, PIN-O, and PIN-P, then the authentication is confirmed to be successful.

[0132] Step S411: After successful authentication, send the virtual payment account to the client.

[0133] In this embodiment, the virtual payment account can be encrypted using at least one server identification code and a user identifier to obtain encrypted data; the encrypted data containing the virtual payment account is then sent to the client. Specifically, the virtual payment account (VPA) can be encrypted using the AES algorithm and the key sha2 (PIN-B, PIN-O, PIN-P, UID) to obtain encrypted data. Correspondingly, after receiving the encrypted data, the client can use the key sha2 (PIN-B, PIN-O, PIN-P, UID) in the client to decrypt the virtual payment account (VPA).

[0134] Please see Figure 9 , Figure 9 This is a sequence diagram of the interaction between the client and the server in this application.

[0135] In this embodiment, the account management method includes the following steps:

[0136] Step S501: The client obtains the type of payment operation. The type of payment operation includes at least one of the following: selecting business type operation, creating order operation, and paying order operation.

[0137] Step S502: The client generates the corresponding first client signature based on the client's user identifier and the selected business type operation.

[0138] Step S503: The client sends an authentication request for selecting the business type operation and the first client signature to the server.

[0139] Step S504: Generate a first server identification code and a first server signature corresponding to the operation of selecting the business type based on the first client signature.

[0140] Step S505: When the first server signature corresponding to the selected business type operation is consistent with the first client signature, the server generates a mapping between the user identifier and the first server identification code in memory.

[0141] Step S506: The client generates a corresponding second client signature based on the client's user identifier and the order creation operation.

[0142] Step S507: The client sends an authentication request for creating an order and a second client signature to the server.

[0143] Step S508: Generate a second server identification code and a second server signature corresponding to the order creation operation based on the second client signature.

[0144] Step S509: When the second server signature corresponding to the order creation operation is consistent with the second client signature, the order number, the first server identification code, and the second server identification code are associated and stored.

[0145] Step S510: The client generates a corresponding third-party client signature based on the client's user identifier and payment order operation.

[0146] Step S511: The client sends an authentication request for the payment order operation and a third-party client signature to the server.

[0147] Step S512: Generate a third-server identification code and a third-server signature corresponding to the payment order operation based on the third client signature.

[0148] Step S513: When the third server signature corresponding to the payment order operation matches the third client signature, the server will associate and store the third server identification code with the order number.

[0149] Step S514: When there is a server identification code in the server identification code associated with the order number that matches the first server identification code, the second server identification code, and the third server identification code corresponding to the user identifier, the authentication is confirmed to be successful.

[0150] Step S515: After successful authentication, the server sends a virtual payment account to the client.

[0151] For a description of the above steps, please refer to the foregoing embodiments, which will not be repeated here.

[0152] Through the above embodiments, this application generates a client identification code (PIN code) using a dynamic function library (SO), thus eliminating the need to hardcode any keys or fixed values ​​on the client side. Furthermore, the client identification code is associated with the user identifier, allowing each user to have a different key, enhancing security during the payment authentication process. Each user also has multiple keys, eliminating the need for additional key management costs. Moreover, the client identification code is associated with the type of payment operation. When the server verifies, authentication is only confirmed if the offset address corresponding to the order number contains an offset address that matches the first, second, and third offset addresses. This ensures that the entire critical process is verified without bypassing intermediate steps, guaranteeing payment security. Furthermore, the server can add VPA accounts for future service providers without releasing a new client version, making the addition of VPA accounts more flexible.

[0153] Please see Figure 10 , Figure 10 This is a schematic block diagram of the structure of a mobile terminal according to an embodiment of this application.

[0154] In this embodiment, the mobile terminal 100 may include an acquisition module 110, a signature module 120, a sending module 130, and a receiving module 140. The acquisition module 110 is used to acquire the type of payment operation; the signature module 120 is used to generate a corresponding client signature based on the client's user identifier and the type of payment operation; the sending module 130 is used to send the authentication request and client signature of the payment operation to the server so that the server can perform payment authentication based on at least one client signature; and the receiving module 140 is used to receive the virtual payment account returned by the server after the server successfully authenticates the payment.

[0155] In some implementations, the signature module 120 is further configured to call the corresponding function and obtain the offset address of the function according to the type of payment operation; concatenate the offset address of the function with the user identifier of the client to obtain the corresponding client identification code; and generate the corresponding client signature based on the client identification code.

[0156] In some implementations, the signature module 120 is also used to concatenate the function's offset address and the client's user identifier, perform a hash operation to obtain the corresponding hash value, and extract characters from the hash value to form the corresponding client identification code.

[0157] In some implementations, the receiving module 140 is also used to decrypt the encrypted data returned by the server using at least one client identification code and user identifier to obtain a virtual payment account.

[0158] In some implementations, the function corresponding to the payment operation is stored in a dynamic link library, wherein the offset address of the function corresponding to the payment operation is different in different versions of the dynamic link library.

[0159] In some implementations, the types of payment operations include at least one of the following: selecting a business type operation, creating an order operation, and paying for an order operation.

[0160] In some implementations, the signature module 120 is further configured to generate a corresponding first client signature based on the client's user identifier and the selected business type operation. Sending the authentication request and client signature for the payment operation to the server includes: sending the authentication request and first client signature for the selected business type operation to the server; and / or generating a corresponding client signature based on the client's user identifier and the type of payment operation, including: generating a corresponding second client signature based on the client's user identifier and the order creation operation; sending the authentication request and client signature for the payment operation to the server includes: sending the authentication request and second client signature for the order creation operation to the server; and / or generating a corresponding client signature based on the client's user identifier and the type of payment operation, including: generating a corresponding third client signature based on the client's user identifier and the payment order operation; sending the authentication request and client signature for the payment operation to the server includes: sending the authentication request and third client signature for the payment order operation to the server.

[0161] Please see Figure 11 , Figure 11 This is a schematic block diagram of the structure of an embodiment of the server in this application.

[0162] In this embodiment, the server 200 may include a receiving module 210, an authentication module 220, and a sending module 230. The receiving module 210 is used to receive an authentication request for a payment operation and a client signature sent by the client. The client signature is generated based on a client identification code, which is generated according to the client's user identifier and the type of payment operation. The authentication module 220 is used to perform payment authentication based on at least one client signature. The sending module 230 is used to send a virtual payment account to the client after successful authentication.

[0163] In some implementations, the authentication module 220 is further configured to process the client signature to obtain the client's user identifier; obtain the offset address corresponding to the payment operation based on the client's user identifier; generate a corresponding server identifier based on the offset address corresponding to the payment operation and the client's user identifier; generate a corresponding server signature based on the server identifier; and determine that the authentication is successful when the client signature corresponding to the payment operation matches the server signature.

[0164] In some implementations, the function corresponding to the payment operation is stored in a dynamic link library. The receiving module 210 is also used to receive and store the offset address sent by the client when the version of the dynamic link library is updated. The offset address is the offset address of the function corresponding to the payment operation in the latest version of the dynamic link library.

[0165] In some implementations, the payment operation includes at least one of the following: selecting a business type, creating an order, and paying an order, wherein the selecting a business type operation corresponds to generating a first server identifier and a first server signature, the creating an order operation corresponds to generating a second server identifier and a second server signature, and the paying an order operation corresponds to generating a third server identifier and a third server signature.

[0166] In some implementations, the authentication module 220 is further configured to: generate a mapping between the user identifier and the first server identifier in memory when the first server signature corresponding to the business type selection operation matches the first client signature; when the second server signature corresponding to the order creation operation matches the second client signature, associate and store the order number, the first server identifier, and the second server identifier; when the third server signature corresponding to the payment order operation matches the third client signature, associate and store the third server identifier with the order number; and determine successful authentication when the server identifiers associated with the order number contain a server identifier that matches the first server identifier, the second server identifier, and the third server identifier corresponding to the user identifier.

[0167] In some implementations, the sending module 230 is further configured to encrypt the virtual payment account using at least one server identification code and a user identifier to obtain encrypted data; and send the encrypted data containing the virtual payment account to the client.

[0168] Please see Figure 12 , Figure 12 This is a schematic block diagram of the structure of an embodiment of the electronic device of this application.

[0169] The electronic device 300 may include a memory 310 and a processor 320 coupled to each other. The memory 310 is used to store program data, and the processor 320 is used to execute the program data to implement the steps in any of the above method embodiments.

[0170] Electronic device 300 may include, but is not limited to: televisions, desktop computers, laptop computers, handheld computers, wearable devices, head-mounted displays, e-reader devices, portable music players, portable game consoles, laptops, ultra-mobile personal computers (UMPCs), netbooks, as well as mobile phones, personal digital assistants (PDAs), augmented reality (AR) devices, and virtual reality (VR) devices.

[0171] Specifically, processor 320 controls itself and memory 310 to implement the steps in any of the above method embodiments. Processor 320 may also be referred to as a CPU (Central Processing Unit). Processor 320 may be an integrated circuit chip with signal processing capabilities. Processor 320 may also be a general-purpose processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component. A general-purpose processor may be a microprocessor or any conventional processor. Furthermore, processor 320 may be implemented by multiple integrated circuit chips.

[0172] Please see Figure 13 , Figure 13 This is a schematic block diagram of an embodiment of a computer-readable storage medium of this application.

[0173] The computer-readable storage medium 400 stores program data 410, which, when executed by a processor, is used to implement the steps in any of the above method embodiments.

[0174] The computer-readable storage medium 400 can be a medium that can store computer programs, such as a USB flash drive, portable hard drive, read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk. It can also be a server that stores the computer program, which can send the stored computer program to other devices for execution or run the stored computer program itself.

[0175] In the several embodiments provided in this application, it should be understood that the disclosed methods and apparatus can be implemented in other ways. For example, the apparatus implementations described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0176] The units described as separate components may or may not be physically separate. 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 units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0177] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0178] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods of various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0179] The above description is merely an embodiment of this application and does not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. An account management method characterized by comprising: The method comprises the following steps: The client obtains the type of the payment operation; According to the type of the payment operation, a corresponding function stored in a dynamic link library is called and the offset address of the function is obtained; wherein the offset address of the function corresponding to the payment operation is different in different versions of the dynamic link library; The offset address of the function and the user identifier of the client are concatenated to obtain a corresponding client identification code; Based on the client identification code, a corresponding client signature is generated; the authentication request of the payment operation and the client signature are sent to the server to enable the server to perform authentication based on at least one client signature; When the server authentication is successful, the virtual payment account returned by the server is received.

2. The method of claim 1, wherein, The offset address of the function and the user identifier of the client are concatenated to obtain a corresponding client identification code, which comprises the following steps: After the offset address of the function and the user identifier of the client are concatenated, a hash operation is performed to obtain a corresponding hash value; The characters in the hash value are extracted to form a corresponding client identification code.

3. The method of claim 1, wherein, The virtual payment account returned by the server is received, which comprises the following steps: At least one client identification code and the user identifier are used to decrypt the encrypted data returned by the server to obtain a virtual payment account.

4. The method of claim 1, wherein, The type of the payment operation comprises at least one of the following: a selection business type operation, a creation order operation and a payment order operation.

5. The method according to claim 4, wherein The client signature corresponding to the user identifier of the client and the type of the payment operation is generated, which comprises the following steps: the first client signature corresponding to the user identifier of the client and the selection business type operation is generated; the authentication request of the payment operation and the client signature are sent to the server, which comprises the following steps: the authentication request of the selection business type operation and the first client signature are sent to the server; and / or The client signature corresponding to the user identifier of the client and the type of the payment operation is generated, which comprises the following steps: the second client signature corresponding to the user identifier of the client and the creation order operation is generated; the authentication request of the payment operation and the client signature are sent to the server, which comprises the following steps: the authentication request of the creation order operation and the second client signature are sent to the server; and / or The client signature corresponding to the user identifier of the client and the type of the payment operation is generated, which comprises the following steps: the third client signature corresponding to the user identifier of the client and the payment order operation is generated; the authentication request of the payment operation and the client signature are sent to the server, which comprises the following steps: the authentication request of the payment order operation and the third client signature are sent to the server.

6. An account management method characterized by comprising: The method comprises the following steps: The server receives the authentication request of the payment operation and the client signature sent by the client; wherein the client signature is generated according to the user identifier of the client and the type of the payment operation; The client signature is processed to obtain the user identifier of the client; Based on the user identification of the client, an offset address of a function corresponding to the payment operation is obtained; wherein the function corresponding to the payment operation is stored in a dynamic link library; when the version of the dynamic link library is updated, the server receives and stores the offset address sent by the client; the offset address is the offset address of the function corresponding to the payment operation in the latest version of the dynamic link library; Based on the offset address corresponding to the payment operation and the user identification of the client, a corresponding server identification code is generated; Based on the server identification code, a corresponding server signature is generated; When the client signature and the server signature corresponding to the payment operation are consistent, it is determined that the authentication is successful; After the authentication is successful, a virtual payment account is sent to the client.

7. The method of claim 6, wherein, The payment operation includes at least one of the following: a business type selection operation, an order creation operation, and a payment order operation, wherein the business type selection operation corresponds to generate a first server identification code and a first server signature, the order creation operation corresponds to generate a second server identification code and a second server signature, and the payment order operation corresponds to generate a third server identification code and a third server signature.

8. The method of claim 7, wherein, When the client signature and the server signature corresponding to the payment operation are consistent, it is determined that the authentication is successful, including: When the first server signature corresponding to the business type selection operation is consistent with the first client signature, a mapping of the user identification and the first server identification code is generated in the memory; When the second server signature corresponding to the order creation operation is consistent with the second client signature, the order number, the first server identification code, and the second server identification code are stored in association; When the third server signature corresponding to the payment order operation is consistent with the third client signature, the third server identification code and the order number are stored in association; When the order number associated with the server identification code exists in the first server identification code, the second server identification code, and the third server identification code corresponding to the user identification, it is determined that the authentication is successful.

9. The method as claimed in claim 6, wherein, When the authentication is successful, a virtual payment account is sent to the client, including: Encrypting the virtual payment account using at least one of the server identification codes and the user identification to obtain encrypted data; Sending the encrypted data containing the virtual payment account to the client.

10. A mobile terminal, characterized by Including: An acquisition module for acquiring the type of a payment operation; A signature module for generating a corresponding client signature based on the user identification of the client and the type of the payment operation; A sending module for sending an authentication request of the payment operation and the client signature to the server, so that the server performs authentication based on at least one of the client signatures; A receiving module for receiving a virtual payment account returned by the server when the server authentication is successful; The mobile terminal is configured to perform the account management method of any one of claims 1 to 5.

11. A server, characterized by Including: The receiving module is configured to receive a payment operation authentication request and a client signature sent by a client, wherein the client signature is generated according to a user identifier of the client and a type of the payment operation; The authentication module is configured to perform payment authentication based on at least one of the client signatures; The sending module is configured to send a virtual payment account to the client when the authentication is successful. The server is configured to perform the account management method according to any one of claims 6-9.

12. An electronic device, comprising: The electronic device comprises a memory and a processor coupled to each other, the memory is configured to store program data, and the processor is configured to execute the program data to implement the method according to any one of claims 1-9.

13. A computer-readable storage medium, characterized in that, The computer readable storage medium stores program data, and the program data, when executed by a processor, is used to implement the method according to any one of claims 1-9.

Images