A method and device for binding account information

Abstract

The present application relates to the field of communication technologies, and in particular, to a method and apparatus for binding account information. The third-party payment server receives an account information binding request sent by a third-party payment client; sends the bank payment account information associated with the account information binding request to the third-party payment client for display; receives a verification code acquisition request sent by the third-party payment client, and sends a generated verification code to the communication account corresponding to the bank payment account information, where the verification code acquisition request is sent by the third-party payment client after receiving a confirmation operation for the bank payment account information; receives the input verification code sent by the third-party payment client, and determines that the input verification code passes the verification according to the generated verification code, and then determines that the binding between the bank payment account information and the account identification information of the third-party payment client is successful, improving the binding efficiency and success rate.

Description

Technical Field

[0001] This application relates to the field of communication technologies, and in particular, to a method and device for binding account information. Background Art

[0002] Currently, mobile payment has been relatively popular. For example, users can make payments through third-party payment applications installed on terminals such as mobile phones. Users only need to bind a bank card and set a payment password in the third-party payment application, and each payment can be completed through the bank card. In the binding solutions in related technologies, it is mainly initiated by the third-party payment application, and users need to input multiple pieces of information such as bank card numbers and ID numbers, which is relatively cumbersome and error-prone in information input. There may also be a situation where the bank card is not around and the user doesn't remember the bank card number, resulting in relatively low overall binding efficiency and binding success rate, and also a high loss rate of binding bank cards in the third-party payment application. Summary of the Invention

[0003] Embodiments of this application provide a method and device for binding account information to improve the binding efficiency.

[0004] The specific technical solutions provided by the embodiments of this application are as follows:

[0005] In one embodiment of this application, a method for binding account information is provided, including:

[0006] The third-party payment server receives an account information binding request sent by the third-party payment client.

[0007] Send the bank payment account information associated with the account information binding request to the third-party payment client for display, where the bank payment account information is sent by the bank server to the third-party payment server after determining that the user triggers a binding operation on the bank client.

[0008] Receive a verification code acquisition request sent by the third-party payment client, and send a generated verification code to the communication account corresponding to the bank payment account information, where the verification code acquisition request is sent by the third-party payment client after receiving a confirmation operation for the bank payment account information.

[0009] Receive the input verification code sent by the third-party payment client, and after determining that the input verification code passes the verification according to the generated verification code, determine that the bank payment account information is successfully bound to the account identification information of the third-party payment client.

[0010] In another embodiment of this application, a method for binding account information is provided, including:

[0011] The third-party payment client sends an account information binding request to the third-party payment server;

[0012] Receives the bank payment account information associated with the account information binding request returned by the third-party payment server, and displays the bank payment account information;

[0013] In response to a confirmation operation for the bank payment account information, sends a verification code acquisition request to the third-party payment server;

[0014] Obtains the input verification code entered by the user, and sends the input verification code to the third-party payment server, so that after the third-party payment server determines that the input verification code passes the verification, it determines that the binding of the bank payment account information and the account identification information of the third-party payment client is successful.

[0015] In another embodiment of the present application, a device for binding account information is provided, which is applied to a third-party payment server and includes:

[0016] A first receiving module, configured to receive an account information binding request sent by a third-party payment client;

[0017] A first sending module, configured to send the bank payment account information associated with the account information binding request to the third-party payment client for display, where the bank payment account information is sent by the bank server to the third-party payment server after determining that the user triggers a binding operation on the bank client;

[0018] A second receiving module, configured to receive a verification code acquisition request sent by the third-party payment client;

[0019] A second sending module, configured to send a generated verification code to the communication account corresponding to the bank payment account information, where the verification code acquisition request is sent by the third-party payment client after receiving a confirmation operation for the bank payment account information;

[0020] A third receiving module, configured to receive the input verification code sent by the third-party payment client;

[0021] A first determination module, configured to determine that the binding of the bank payment account information and the account identification information of the third-party payment client is successful after determining that the input verification code passes the verification according to the generated verification code.

[0022] Optionally, further includes:

[0023] A fourth receiving module, configured to receive the binding address acquisition request sent by the bank server, where the binding address acquisition request includes at least user identity information and bank payment account information; the binding address acquisition request is sent by the bank server after receiving the QR code request sent by the bank client, and the QR code request is sent by the bank client after responding to the triggered binding operation;

[0024] A third sending module, configured to generate a binding address and return the binding address to the bank server, so that the bank server sends the binding address to the bank client to generate and display a QR code including the binding address.

[0025] Optionally, the account information binding request is sent by the third-party payment client to the third-party payment server after scanning the QR code displayed by the bank client.

[0026] Optionally, it further includes:

[0027] A fifth receiving module, configured to receive the binding operation request sent by the bank server, where the binding operation request includes at least user identity information and bank payment account information, and the binding operation request is sent by the bank server after determining that the user triggers a binding operation on the bank client;

[0028] A fourth sending module, configured to generate a binding message for the binding operation request and send it to the third-party payment client for display.

[0029] Optionally, the account information binding request is sent by the third-party payment client after responding to the click operation on the binding message.

[0030] Optionally, before determining that the bank payment account information is successfully bound to the user identification information of the third-party payment client, it further includes:

[0031] A second determination module, configured to determine that the payment password input by the third-party payment client is correct, where the payment password is received by the third-party payment client after displaying a payment password input prompt message and receiving user input.

[0032] In another embodiment of the present application, a device for binding account information is provided, which is applied to a third-party payment client and includes:

[0033] A first sending module, configured to send an account information binding request to a third-party payment server;

[0034] A first receiving module, configured to receive the bank payment account information associated with the account information binding request returned by the third-party payment server;

[0035] The first display module is used to display the bank payment account information;

[0036] The second sending module is used to send a verification code acquisition request to the third-party payment server in response to a confirmation operation on the bank payment account information;

[0037] The second receiving module is used to obtain the input verification code entered by the user;

[0038] The third sending module is used to send the input verification code to the third-party payment server, so that after the third-party payment server determines that the input verification code passes the verification, it determines that the binding of the bank payment account information and the account identification information of the third-party payment client is successful.

[0039] Optionally, the first sending module is specifically used for:

[0040] Scan the QR code displayed by the bank client, and after parsing the QR code, send an account information binding request to the third-party payment server;

[0041] Wherein, the QR code is generated by the bank client based on the binding address obtained from the bank server, and the binding address is generated by the third-party payment server and sent to the bank server after the bank server sends a binding address acquisition request to the third-party payment server. The binding address acquisition request includes at least user identity information and bank payment account information, and the binding QR code request is sent by the bank client in response to a triggered binding operation.

[0042] Optionally, the first sending module is specifically used for:

[0043] In response to a binding message click operation, send an account information binding request to the third-party payment server, wherein the binding message is generated by the third-party payment server for the binding operation request sent by the bank server and sent to the third-party payment client, and the binding operation request includes at least user identity information and bank payment account information.

[0044] Optionally, it further includes:

[0045] The second display module is used to display input payment password prompt information and send the input payment password to the third-party payment server for payment password verification.

[0046] Optionally, before sending the verification code acquisition request to the third-party payment server, it further includes:

[0047] The third display module is used to display set payment password prompt information;

[0048] A third receiving module, configured to receive an input first payment password;

[0049] A fourth display module, configured to display input payment password prompt information;

[0050] A fourth receiving module, configured to receive an input second payment password;

[0051] A confirmation module, configured to confirm that the first payment password is the same as the second payment password.

[0052] In another embodiment of the present application, an electronic device is provided, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the program, the steps of any of the above methods for binding account information are implemented.

[0053] In another embodiment of the present application, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above methods for binding account information are implemented.

[0054] In an embodiment of the present application, after the bank server determines that the user triggers a binding operation on the bank client, it sends bank payment account information to the third-party payment server. Then, when the third-party payment server receives an account information binding request sent by the third-party payment client, it sends the bank payment account information associated with the account information binding request to the third-party payment client for display. After the third-party payment client receives a confirmation operation for the bank payment account information, it sends a verification code acquisition request. The third-party payment server sends a generated verification code to the communication account corresponding to the bank payment account information, and receives the input verification code sent by the third-party payment client. After determining that the input verification code passes the verification based on the generated verification code, it determines that the binding of the bank payment account information and the account identification information of the third-party payment client is successful. In this way, the user does not need to manually input the bank payment account information on the third-party payment client, but it is sent by the bank server to the third-party payment server and displayed on the third-party payment client. The user only needs to confirm that the information is correct, avoiding the situation of information input errors, and the operation is simple, improving the overall binding efficiency and success rate of the bank payment account information. Moreover, since the binding is initiated by the bank side, it can improve the utilization rate of the user traffic on the bank side and bring more binding traffic of bank payment account information to the third-party payment client. BRIEF DESCRIPTION OF THE DRAWINGS

[0055] Figure 1 It is a schematic application architecture diagram of the method for binding account information in an embodiment of the present application;

[0056] Figure 2 It is a flowchart of a method for binding account information in an embodiment of the present application;

[0057] Figure 3 Schematic flow diagram of another method for binding account information in the embodiments of the present application;

[0058] Figure 4 Interaction timing diagram of the method for binding account information in the embodiments of the present application;

[0059] Figure 5 Schematic diagram of the interface for adding a binding operation function in the bank client in the embodiments of the present application;

[0060] Figure 6 Schematic diagram of the interface for displaying a QR code in the bank client in the embodiments of the present application;

[0061] Figure 7 Schematic diagram of the interface for displaying bank card information in the third-party payment client in the embodiments of the present application;

[0062] Figure 8 Schematic diagram of the interface for displaying a verification code input in the third-party payment client in the embodiments of the present application;

[0063] Figure 9 Schematic diagram of the page for successfully binding a card in the third-party payment client in the embodiments of the present application;

[0064] Figure 10 Schematic diagram of the structure of a device for binding account information in the embodiments of the present application;

[0065] Figure 11 Schematic diagram of the structure of another device for binding account information in the embodiments of the present application;

[0066] Figure 12 Schematic diagram of the structure of an electronic device in the embodiments of the present application. Detailed implementation manners

[0067] Next, the technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.

[0068] For the convenience of understanding the embodiments of the present application, several concepts will be briefly introduced below:

[0069] Mobile payment: Also known as mobile phone payment, it is a service method that allows users to use their mobile terminals (usually smartphones) to make financial payments for the goods or services they consume. For example, the currently widely used method is to make payments through a third-party payment client. The third-party payment platform cooperates with banks. Users only need to bind a bank card and set a payment password in the third-party payment client. Each payment only requires verifying the payment password to complete the payment. In addition, it also supports small-amount password-free payment.

[0070] Four elements of a bank card: It refers to the four static information of the bank card number, ID number, name, and mobile phone number reserved in the bank that need to be verified for mobile payment.

[0071] Bank payment account: In the embodiments of this application, it represents any payment account opened by a user in a bank. For example, the bank payment account is a bank card.

[0072] Communication account: In the embodiments of this application, this communication account is, for example, a mobile phone number.

[0073] Binding a card: In the embodiments of this application, it means binding a bank card in a third-party payment client, that is, binding the bank payment account information with the account identification information of the third-party payment client.

[0074] In the binding solutions in the related technologies, it is mainly initiated by the third-party payment client, and users need to input multiple pieces of information such as the bank card number and ID number, or they can take a photo of the bank card for identification and binding. However, this method is relatively cumbersome and information input is prone to errors. There may also be situations where the bank card is not around and the user does not remember the bank card number or cannot take a photo, resulting in a low overall binding efficiency and success rate of bank cards, and also a high loss rate of bank card binding in the third-party payment client.

[0075] Therefore, in the embodiments of the present application, a new method for binding account information is provided to address the above problems. In the embodiments of the present application, considering the card-opening scenario at the bank, which is the source scenario, it is very necessary to seize the card-opening scenario. Therefore, a one-key binding operation function is implemented in the bank client, enabling users to more quickly and conveniently bind the bank card to the third-party payment client after completing scenarios such as card opening and card activation. Specifically, when the user triggers a binding operation in the bank client, the bank server sends the bank payment account information to the third-party payment server. Subsequently, when the third-party payment server receives an account information binding request sent by the third-party payment client, it sends the bank payment account information associated with the account information binding request to the third-party payment client for display. After receiving a confirmation operation for the bank payment account information, the third-party payment client sends a verification code acquisition request. The third-party payment server sends a generated verification code to the communication account corresponding to the bank payment account information and receives the verification code input by the third-party payment client. After determining that the input verification code passes the verification based on the generated verification code, it is determined that the binding between the bank payment account information and the account identification information of the third-party payment client is successful. In this way, the user does not need to manually input the bank payment account information in the third-party payment client. Instead, it is sent by the bank server to the third-party payment server and displayed in the third-party payment client. The user only needs to confirm that the information is correct and then perform verification code verification to complete the binding. The operation is simple and convenient, improving the binding efficiency and success rate. Moreover, since the binding is initiated by the bank side, it can improve the utilization rate of user traffic on the bank side. By adding a new user traffic scenario, it can also bring more binding traffic to the third-party payment client.

[0076] Refer to Figure 1 As shown, it is an application architecture schematic diagram of the method for binding account information in the embodiments of the present application, including a bank client 100, a bank server 200, a third-party payment client 300, and a third-party payment server 400.

[0077] Both the bank client 100 and the third - party payment client 300 are user - oriented application programs that can be installed on smart devices. Specifically, the bank client 100 is the user - oriented application program provided by the bank. For example, it can be installed on the bank's offline smart devices, such as self - service counters, handheld tablets (pads), teller counter devices, etc. Of course, it can also be applied to various online scenarios, that is, it can be non - bank offline smart devices, such as smartphones, laptops, desktop computers, etc. In the embodiments of this application, there is no limitation. For example, a bank application (Application, APP) can be installed on a smartphone, and a function for binding account information is provided in the bank APP. When the user clicks on this binding operation function, the binding is initiated. Another example is that the bank client 100 can also be integrated into other application programs, such as public accounts, mini - programs, etc. By opening the bank client 100 through this other application program, the binding can be initiated through the binding operation function provided in the bank client 100.

[0078] The third - party payment client 300 is the user - oriented application program provided by the third - party payment platform. For example, it can be installed on smartphones, tablets, laptops, desktop computers, smart speakers, smart watches, etc., but it is not limited to this. For example, in the embodiments of this application, the third - party payment client 300 can provide a payment function and can also have a scanning code function, etc.

[0079] The bank server 200 and the third - party payment server 400 are both corresponding background servers. The bank server 200 is the background server of the bank client 100, and the third - party payment server 400 is the background server of the third - party payment client 300. They can respectively provide various network services for the bank client 100 and the third - party payment client 300.

[0080] Among them, the bank server 200 and the third - party payment server 400 can be independent physical servers, or a server cluster or distributed system composed of multiple physical servers. They can also be cloud servers that provide basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, Content Delivery Network (CDN), and big data and artificial intelligence platforms.

[0081] The bank client 100 and the bank server 200, as well as the third - party payment client 300 and the third - party payment server 400 can be respectively communicatively connected through the Internet. And the bank server 200 can also be communicatively connected to the third - party payment server 400 through the Internet, thereby realizing data communication between each other.

[0082] Optionally, the above-mentioned Internet uses standard communication technologies and / or protocols. The Internet is usually the Internet, but it can also be any network, including but not limited to any combination of a Local Area Network (LAN), a Metropolitan Area Network (MAN), a Wide Area Network (WAN), a mobile, wired or wireless network, a private network or a virtual private network. In some embodiments, technologies and / or formats including Hyper Text Mark-up Language (HTML), Extensible Markup Language (XML), etc. are used to represent the data exchanged through the network. In addition, conventional encryption technologies such as Secure Socket Layer (SSL), Transport Layer Security (TLS), Virtual Private Network (VPN), Internet Protocol Security (IPsec), etc. can be used to encrypt all or some of the links. In other embodiments, customized and / or dedicated data communication technologies can also be used to replace or supplement the above-mentioned data communication technologies.

[0083] The application architecture diagram in the embodiments of the present application is for more clearly illustrating the technical solutions in the embodiments of the present application, and does not constitute a limitation on the technical solutions provided in the embodiments of the present application. For other application architectures, the technical solutions provided in the embodiments of the present application are equally applicable to similar problems.

[0084] Each embodiment of the present application is applied to Figure 1 the application architecture diagram shown for illustrative purposes.

[0085] Based on the above embodiments, refer to Figure 2 As shown, it is a flowchart of a method for binding account information in the embodiments of the present application, which is applied to a third-party payment server. The method includes:

[0086] Step 200: The third-party payment server receives an account information binding request sent by the third-party payment client.

[0087] In the embodiments of the present application, binding account information means binding bank payment account information in the third-party payment client, such as a bank card. And in the embodiments of the present application, the binding trigger process is initiated from the bank side to the third-party payment platform side. Specifically, the third-party payment client is triggered to send an account information binding request to the third-party payment server. Several possible implementation manners are provided in the embodiments of the present application:

[0088] The first method: The account information binding request is sent to the third-party payment server after the third-party payment client scans the QR code displayed by the bank client.

[0089] The QR code displayed by the bank client in the embodiment of the present application at least includes a binding address for the user identity information. The QR code is also displayed to the user only after the user triggers the binding operation on the bank client. Specifically, with respect to the generation and display process of the QR code, a possible implementation method is provided in the embodiment of the present application:

[0090] 1) The third-party payment server receives the binding address acquisition request sent by the bank server.

[0091] Among them, the binding address acquisition request includes at least user identity information and bank payment account information; the binding address acquisition request is sent by the bank server after receiving the QR code request sent by the bank client, and the QR code request is sent by the bank client in response to the triggered binding operation.

[0092] That is to say, in the embodiment of the present application, the bank client provides a binding operation trigger function, for example, a binding operation button is displayed, and the user clicks the binding operation button. The bank client sends a binding QR code request to the bank server, and the bank server initiates a binding address acquisition request to the third-party payment server, requesting to obtain the binding address. At this time, the bank server will also send the bank payment account information and user identity information to the third-party payment server. Since the bank payment account is opened on the bank side, the bank server is able to obtain the user identity information and bank payment account information, and it is sent by the bank side to the third-party payment platform side, which is also safer and more accurate.

[0093] 2) Generate a binding address and return the binding address to the bank server, so that the bank server sends the binding address to the bank client to generate and display a QR code containing the binding address.

[0094] After the third-party payment server receives the binding address acquisition request sent by the bank server, it can generate a binding address for the user identity information and bank payment account information in the binding address acquisition request, and send it to the bank server. The bank server sends the binding address to the bank client. The bank client generates a QR code specific to the user based on the binding address and displays the QR code to the user.

[0095] The user then scans the QR code through the third-party payment client, and the third-party payment client parses the QR code and sends an account information binding request to the third-party payment server.

[0096] The second method: The account information binding request is sent by the third-party payment client after responding to the click operation on the binding message.

[0097] That is, in the embodiment of the present application, this second method does not require generating a QR code or scanning the code. After the binding operation is triggered on the bank client, the bank side pushes the user identity information and the bank payment account information to the payment platform side, and then the binding message is displayed on the third-party payment client. The user can click on this binding message to perform the binding. Specifically for the process of the binding message, the embodiment of the present application provides a possible implementation method:

[0098] 1) Receive the binding operation request sent by the bank server.

[0099] Among them, the binding operation request includes at least the user identity information and the bank payment account information. The binding operation request is sent by the bank server after determining that the user triggers the binding operation on the bank client.

[0100] 2) Generate a binding message for the binding operation request and send it to the third-party payment client for display.

[0101] Specifically, the third-party payment server can perform a matching search according to the user identity information in the binding operation request, determine the account identification information of the third-party payment client corresponding to the user identity information, and then send the binding message to the third-party payment client corresponding to the account identification information. The third-party payment client displays the binding message.

[0102] Among them, the user identity information can be an ID number, a mobile phone number, etc., and the embodiment of the present application does not limit it.

[0103] In the embodiment of the present application, after the user clicks the binding operation button on the bank client, the bank client sends the message triggered by the binding operation to the bank server. After receiving it, the bank server sends a binding operation request to the third-party payment server. The third-party payment server generates a binding message, for example, a message including a binding-related link, and sends the binding message to the third-party payment client. The third-party payment client displays the binding message. For example, the binding message can be pushed to the payment public account in the third-party payment client, without limitation.

[0104] Then the user clicks on this binding message on the third-party payment client, and the third-party payment client sends an account information binding request to the third-party payment server.

[0105] Further, if a user has multiple bank payment accounts in the same bank, the bank side can determine which bank payment account to bind at this time. For example, each bank payment account owned by the user is displayed in the bank client, and each displayed bank payment account corresponds to a binding operation button. When the user selects and clicks the binding operation button of a certain bank payment account, it is to determine to bind the corresponding bank payment account, and the bank server will only send the information of the corresponding bank payment account to the third-party payment server. Another example is that only one binding operation button is displayed in the bank client. After the user clicks the binding operation button, a list of all the bank payment accounts owned by the user is popped up, and the user selects one bank payment account from it. Then, the bank server will also only send the information of the selected bank payment account to the third-party payment server.

[0106] Step 210: Send the bank payment account information associated with the account information binding request to the third-party payment client for display, where the bank payment account information is sent by the bank server to the third-party payment server after determining that the user triggers a binding operation in the bank client.

[0107] Among them, the bank payment account information can be, for example, the number of the bank payment account, the affiliated type, the user's name, the corresponding reserved communication account, etc., without limitation. Further, to ensure security, when the third-party payment client displays the bank payment account information, it can be displayed encrypted. For example, only part of the number of the bank payment account is displayed, and only part of the characters in the user's name is displayed.

[0108] In the embodiment of the present application, after receiving the account information binding request sent by the third-party payment client, the third-party payment server can determine the bank payment account information associated with the account information binding request based on the binding address, the user identity information corresponding to the third-party payment client, etc., and send the bank payment account information to the third-party payment client. The third-party payment client can then display a binding page for the user and display the bank payment account information on the binding page. The user only needs to confirm whether the bank payment account information is correct, without the need for the user to input, which reduces the complexity of the operation and also reduces the possibility of errors in the information input by the user.

[0109] Step 220: Receive the verification code acquisition request sent by the third-party payment client, and send a generated verification code to the communication account corresponding to the bank payment account information, where the verification code acquisition request is sent by the third-party payment client after receiving a confirmation operation for the bank payment account information.

[0110] Among them, the communication account is, for example, a mobile phone number, without limitation.

[0111] For example, the third-party payment client displays the bank payment account information. If the user confirms that the bank payment account information is correct, the user can click the "Next" operation button. At this time, the third-party payment client determines that it has received the confirmation operation for the bank payment account information, sends a verification code acquisition request to the third-party payment server, and the subsequent operation interface is displayed by jumping on the third-party payment client. Furthermore, after receiving the verification code acquisition request, the third-party payment server generates a verification code and sends the generated verification code to the communication account corresponding to the bank payment account information.

[0112] Step 230: Receive the input verification code sent by the third-party payment client. After determining that the input verification code passes the verification according to the generated verification code, determine that the binding between the bank payment account information and the account identification information of the third-party payment client is successful.

[0113] Specifically, the third-party payment client displays a verification code input interface. The user inputs the verification code at the corresponding position in the verification code input interface. Furthermore, the third-party payment server determines whether the input verification code is consistent with the previously issued generated verification code. If it is determined to be consistent, that is, it is determined that the input verification code passes the verification, and then it is determined that the binding between the bank payment account information and the account identification information of the third-party payment client is successful.

[0114] In the embodiment of the present application, the purpose of using the verification code is mainly for identity authentication, which can ensure security.

[0115] Furthermore, in the embodiment of the present application, to improve security, the payment password also needs to be verified during binding. Specifically, the following possible implementation manners are provided in the embodiment of the present application:

[0116] 1) If the third-party payment client has set a payment password.

[0117] Before determining that the binding between the bank payment account information and the user identification information of the third-party payment client is successful, it further includes: determining that the payment password input by the third-party payment client is correct, where the payment password is received from the user after the third-party payment client displays the payment password input prompt information.

[0118] For example, after receiving the confirmation operation for the bank payment account information, the third-party payment client can display an interface containing the payment password input prompt information before sending the verification code acquisition request. The user inputs the payment password of the third-party payment client. After the third-party payment server verifies that the input payment password is correct, it returns a payment password correct response message to the third-party payment client. Furthermore, the third-party payment client jumps to the interface containing the payment password input prompt information, displays the verification code input interface, and sends a verification code acquisition request to the third-party payment server.

[0119] For another example, after the verification code is verified correctly, the third-party payment client can also display an interface containing a prompt message for entering the payment password to verify the payment password.

[0120] Of course, the payment password can also be verified at other times during the binding process, and the embodiments of the present application do not limit this.

[0121] 2) If the third-party payment client does not set a payment password.

[0122] At this time, when the third-party payment client verifies the payment password, it first displays an interface containing a prompt message for setting the payment password. The user first sets the payment password. After the user enters the set payment password, the third-party payment client then displays an interface containing a prompt message for entering the payment password. The user enters the set payment password again. If the two entered payment passwords are the same, it is determined that the payment password verification is passed.

[0123] Similarly, in this case, the embodiments of the present application do not limit the timing of payment password verification either.

[0124] Furthermore, the third-party payment server can also return binding result messages to the bank server and the third-party payment client respectively. For example, after determining that the binding is successful, it notifies the bank server that the binding is successful and notifies the third-party payment client. The third-party payment client displays a binding success page to the user.

[0125] In the embodiment of the present application, when a user triggers a binding operation on a bank client, the bank server sends bank payment account information to a third-party payment server. Subsequently, after the third-party payment server receives an account information binding request sent by a third-party payment client, it sends the bank payment account information associated with the account information binding request to the third-party payment client for display. Moreover, after the third-party payment client receives a confirmation operation for the bank payment account information, it sends a verification code acquisition request. When the third-party payment server receives the verification code acquisition request sent by the third-party payment client, it sends a generated verification code to the communication account corresponding to the bank payment account information. Subsequently, when receiving the input verification code sent by the third-party payment client, after determining that the input verification code passes the verification based on the generated verification code, it determines that the binding between the bank payment account information and the account identification information of the third-party payment client is successful. In this way, after the third-party payment client sends an account information binding request, the third-party payment server sends the bank payment account information obtained from the bank server to the third-party payment client for display. The user only needs to confirm whether the bank payment account information is correct on the third-party payment client, without the need for the user to input the bank payment account information or the user identity information. The operation is simpler, improving the binding efficiency and also enhancing the binding success rate. Furthermore, it reduces the binding churn rate of the third-party payment platform. And the initiating end is the bank side, which can bring more binding traffic of bank payment accounts from the bank side, effectively occupying the source scenarios of bank payment accounts, such as card opening or card activation scenarios, and providing great convenience for subsequent users to use bank payment accounts for payment on the third-party payment client.

[0126] Based on the above embodiment, refer to Figure 3 As shown, it is a schematic flowchart of another method for binding account information in the embodiment of the present application, which is applied to a third-party payment client. The method includes:

[0127] Step 300: The third-party payment client sends an account information binding request to the third-party payment server.

[0128] When performing step 300, several possible implementation manners are provided in the embodiment of the present application:

[0129] The first manner: The third-party payment client sends an account information binding request to the third-party payment server, specifically including: scanning a two-dimensional code displayed on the bank client, and after parsing the two-dimensional code, sending an account information binding request to the third-party payment server.

[0130] Among them, the two-dimensional code at least includes a binding address, and the third-party payment server records the bank payment account information and user identity information corresponding to the binding address.

[0131] Specifically, the QR code is generated by the bank client based on the binding address obtained from the bank server. The binding address is generated by the third-party payment server and sent to the bank server after the bank server sends a binding address acquisition request to the third-party payment server. The binding address acquisition request includes at least user identity information and bank payment account information. The binding QR code request is sent by the bank client in response to the triggered binding operation.

[0132] The second way: The third-party payment client sends an account information binding request to the third-party payment server, specifically including: sending an account information binding request to the third-party payment server in response to a binding message click operation.

[0133] Among them, the binding message is generated by the third-party payment server for the binding operation request sent by the bank server and sent to the third-party payment client. Among them, the binding operation request includes at least user identity information and bank payment account information.

[0134] Step 310: Receive the bank payment account information associated with the account information binding request returned by the third-party payment server, and display the bank payment account information.

[0135] For example, in the embodiment of the present application, the bank client displays a binding operation function button. After the user clicks the binding operation function button, the bank client further displays a QR code containing the binding address. The user scans the QR code through the third-party payment client. The third-party payment client sends an account information binding request to the third-party payment server. The third-party payment server returns the bank payment account information corresponding to the binding address in the account information binding request to the third-party payment client, and the third-party payment client displays the bank payment account information.

[0136] Another example is that the bank client displays a binding operation function button. After the user clicks the binding operation function button, the third-party payment client further displays a binding message. When the user clicks the binding message, the bank payment account information confirmation page can be opened to display the bank payment account information.

[0137] Step 320: In response to the confirmation operation for the bank payment account information, send a verification code acquisition request to the third-party payment server.

[0138] For example, after the user confirms that the bank payment account information is correct in the third-party payment client, the user can click the "Next" function button, which is the confirmation operation.

[0139] Step 330: Obtain the input verification code entered by the user and send the input verification code to the third-party payment server, so that after the third-party payment server determines that the input verification code passes the verification, it determines that the bank payment account information is successfully bound to the account identification information of the third-party payment client.

[0140] Specifically, after receiving the verification code acquisition request, the third-party payment server sends a generated verification code to the communication account corresponding to the bank payment account information, such as a mobile phone number. The third-party payment client displays an interface for inputting the verification code. The user inputs the verification code, and the third-party payment client acquires the input verification code and sends it to the third-party payment server. The third-party payment server determines whether the generated verification code and the input verification code are consistent. When they are determined to be consistent, it is determined that the verification code verification has passed.

[0141] In this way, by scanning the QR code or clicking the binding message through the third-party payment client, the one-key binding process can be initiated. After the user confirms that the bank payment account information is correct in the third-party payment client, only by passing the verification code verification of the communication account can the binding of the bank account information be completed, and the user does not need to input information.

[0142] Furthermore, during the binding process, it is also necessary to verify the payment password. Specifically, there are the following two ways:

[0143] The first way: Display a prompt message for inputting the payment password, and send the input payment password to the third-party payment server for payment password verification.

[0144] The second way: Before sending the verification code acquisition request to the third-party payment server, it further includes: displaying a prompt message for setting the payment password, receiving the input first payment password; displaying a prompt message for inputting the payment password, receiving the input second payment password, and confirming that the first payment password and the second payment password are the same.

[0145] In addition, the verification of the payment password is not limited to before the verification code verification, and it can also be at other times during the binding process. The embodiments of the present application do not limit this.

[0146] In the embodiments of the present application, the third-party payment client sends an account information binding request to the third-party payment server, receives the bank payment account information associated with the account information binding request returned by the third-party payment server, and displays the bank payment account information. In response to the confirmation operation for the bank payment account information, a verification code acquisition request is sent to the third-party payment server, and then the input verification code entered by the user is obtained and sent to the third-party payment server for verification code verification. After passing, it is determined that the bank payment account information is successfully bound to the account identification information of the third-party payment client. In this way, the bank client can access the one-key account information binding ability of the third-party payment platform, which can provide a more efficient binding ability. Initiated from the bank side, the bank payment account information is sent to the third-party payment platform side and then displayed on the third-party payment client. The user does not need to input information. As long as the displayed bank payment account information is confirmed to be correct and the input verification code passes the verification, the binding of the bank account information can be completed, avoiding the situation of incorrect information input and operation complexity, and thus improving the binding efficiency and success rate.

[0147] The following uses a specific application scenario to illustrate by taking binding through scanning a QR code and performing payment password verification before verifying the verification code. Refer to Figure 4 As shown, it is the method interaction timing diagram for binding account information in the embodiments of the present application. The method includes:

[0148] Step 400: The user clicks the one-key binding operation function in the bank client.

[0149] For example, taking the bank payment account as a bank card, a one-key binding operation function is provided in the bank client. After the user opens or activates the card in the bank client of the bank's offline intelligent device, at this time the bank server knows the user's identity information and bank card information. When clicking the one-key binding operation function, the bank client requests the bank server to generate a QR code.

[0150] Step 401: The bank client sends a QR code request to the bank server.

[0151] Step 402: The bank server sends a binding address acquisition request to the third-party payment server.

[0152] Among them, the binding address acquisition request includes at least the user identity information and the bank payment account information.

[0153] Step 403: The third-party payment server returns the binding address to the bank server.

[0154] Step 404: The bank server sends the binding address to the bank client.

[0155] Step 405: The bank client generates a QR code containing the bound address.

[0156] Step 406: The bank client shows the QR code to the user.

[0157] Step 407: The user uses the third-party payment client to scan the QR code shown by the bank client.

[0158] Step 408: The third-party payment client parses the QR code.

[0159] Step 409: The third-party payment client sends an account information binding request to the third-party payment server.

[0160] Step 410: The third-party payment server obtains the login state information.

[0161] Among them, the login state information includes the account identification information of the third-party payment client, user identity information, etc.

[0162] This is because, usually, the third-party payment client not only includes payment functions. For example, if the third-party payment client is an instant messaging APP, it not only integrates payment functions but also provides chat communication functions, etc. For more effective management, different functions are developed by different development departments, so different functions may correspond to different back-end servers. Therefore, considering this application scenario here, the third-party payment server is the back-end server for payment functions, and for the account identification information of the third-party payment client, etc., it needs to be obtained from the corresponding other back-end servers. Furthermore, the third-party payment server can obtain the account identification information, user identity information, etc. corresponding to the third-party payment client.

[0163] Step 411: The third-party payment server sends the login state information and bank payment account information to the third-party payment client.

[0164] Step 412: The third-party payment client shows a page containing bank payment account information.

[0165] For example, it shows information such as bank card number, card type, cardholder name, etc., and for improving security during display, in the embodiments of the present application, it is displayed in an encrypted manner.

[0166] Step 413: The user triggers a confirmation operation for the bank payment account information in the third-party payment client.

[0167] Step 414: The third-party payment client shows an encryption verification page.

[0168] Among them, the encryption verification page prompts the user to enter the payment password.

[0169] Step 415: The user enters the payment password in the third-party payment client.

[0170] Step 416: The third-party payment client verifies the payment password.

[0171] Step 417: After the third-party payment client confirms that the payment password verification is passed, it sends a verification code acquisition request to the third-party payment server.

[0172] Step 418: The third-party payment server sends a generated verification code to the communication account corresponding to the bank payment account information.

[0173] For example, if the communication account is a mobile phone number, the third-party payment server sends a SMS verification code to this mobile phone number.

[0174] Step 419: The user enters the verification code on the third-party payment client.

[0175] Step 420: The third-party payment client sends the entered verification code to the third-party payment server.

[0176] Step 421: The third-party payment server determines that the generated verification code is the same as the entered verification code, and determines that the verification code verification is passed.

[0177] Step 422: The third-party payment server sends a binding success message to the bank server.

[0178] Step 423: The third-party payment server sends a binding success message to the third-party payment client.

[0179] Step 424: The third-party payment client displays a binding success page.

[0180] In this way, in the embodiment of the present application, initiated by the bank side, the bank client adds a one-key binding function. After the user triggers the one-key binding function, the bank server sends a binding request to the third-party payment server, obtains the binding address, and then converts the binding address into a specific two-dimensional code for the user to display. After the user scans the code through the third-party payment client, the third-party payment client can be pulled up for binding, the bank payment account information can be confirmed, and after verification through the payment password and verification code, the binding can be successful, improving the binding efficiency and success rate.

[0181] Next, a specific application scenario is used to illustrate the method for binding account information in the embodiment of the present application from the product side. In the embodiment of the present application, a binding operation function is provided in the bank client, which can be applied to offline intelligent devices in bank branches, or can be applied to various online scenarios, such as bank APPs, official accounts, etc. Taking the bank payment account as a bank card as an example for illustration, for the sake of convenience of description, the binding operation function is the card-binding function, the binding address is described as the card-binding address, and the bank payment account information is described as the bank card information.

[0182] 1) For example, after a user completes card opening or card activation on an offline intelligent device of a bank, an operation function of one - key binding is displayed to the user on this offline intelligent device of the bank. Refer to Figure 5 As shown in Figure 5 This is a schematic diagram of the interface for adding a binding operation function in the bank client in an embodiment of this application. As shown in

[0183] , after the user finishes handling the business, a business completion page can be displayed to remind the user to take away the bank card, and an "One - Key Bind Card" operation function button is displayed on this page. The user can click this "One - Key Bind Card" operation function button. Figure 6 As shown in

[0184] 2) After the user clicks the "One - Key Bind Card" operation function button, the bank client requests the bank server to generate a QR code. The bank server sends bank card information, user identity information, etc. to the third - party payment server, requests card binding and obtains the one - key bind card address. Then, a QR code for one - key binding is displayed in the bank client. For example, refer to Figure 7 This is a schematic diagram of the interface for displaying the QR code in the bank client in an embodiment of this application. As shown in Figure 7 Figure 7 , the third - party payment client can be launched by scanning this QR code. The third - party payment client parses the QR code and sends it to the third - party payment server to obtain the bank card information and display the bank card information. For example, refer to

[0185] , a card - binding page is displayed in the third - party payment client. Information such as the bank card number, card type, cardholder, etc. can be included in the card - binding page, and the user is prompted "Please confirm whether to add the current bank card". After the user confirms that the information is correct, the user can click the "Next" operation button. Figure 8 Figure 8 , a password verification page is then displayed in the third - party payment client. After the user enters the payment password and the third - party payment server determines that the payment password verification is passed, the third - party payment server sends a verification code to the mobile phone number reserved for the bank card. For example, refer to Figure 9 This is a schematic diagram of the interface for displaying the verification code input in the third - party payment client in an embodiment of this application. The user can enter the received verification code and click the "Complete" button after entering. The third - party payment client will send the entered verification code to the third - party payment server for verification code verification. After the third - party payment server determines that the verification is passed, it determines that the card binding is successful, and can send a card - binding success message to the third - party payment client. The third - party payment client displays a card - binding success page to the user. For example, refer to

[0186] In this way, the method for binding account information in the embodiments of the present application does not require the user to input bank card information and user identity information, avoiding the situation of incorrect information input, and the card binding operation is simpler and more convenient, improving the card binding efficiency and success rate.

[0187] Based on the same inventive concept, an apparatus for binding account information is further provided in the embodiments of the present application. The apparatus for binding account information may be, for example, the third-party payment server in the foregoing embodiments. The apparatus for binding account information may be a hardware structure, a software module, or a combination of a hardware structure and a software module. Based on the above embodiments, refer to Figure 10 As shown, an apparatus for binding account information in the embodiments of the present application specifically includes:

[0188] A first receiving module 1000, configured to receive an account information binding request sent by a third-party payment client;

[0189] A first sending module 1010, configured to send the bank payment account information associated with the account information binding request to the third-party payment client for display, where the bank payment account information is sent by the bank server to the third-party payment server after determining that the user triggers a binding operation on the bank client;

[0190] A second receiving module 1020, configured to receive a verification code acquisition request sent by the third-party payment client;

[0191] A second sending module 1030, configured to send a generated verification code to the communication account corresponding to the bank payment account information, where the verification code acquisition request is sent by the third-party payment client after receiving a confirmation operation for the bank payment account information;

[0192] A third receiving module 1040, configured to receive the input verification code sent by the third-party payment client;

[0193] A first determination module 1050, configured to determine that the bank payment account information is successfully bound to the account identification information of the third-party payment client after determining that the input verification code passes the verification according to the generated verification code.

[0194] Optionally, it further includes:

[0195] A fourth receiving module 1060, configured to receive a binding address acquisition request sent by the bank server, where the binding address acquisition request at least includes user identity information and bank payment account information; the binding address acquisition request is sent by the bank server after receiving a two-dimensional code request sent by the bank client, and the two-dimensional code request is sent by the bank client in response to a triggered binding operation;

[0196] A third sending module 1070, configured to generate a binding address and return the binding address to the bank server, so that the bank server sends the binding address to the bank client to generate and display a two-dimensional code containing the binding address.

[0197] Optionally, the account information binding request is sent by the third-party payment client to the third-party payment server after scanning the two-dimensional code displayed by the bank client.

[0198] Optionally, it further includes:

[0199] A fifth receiving module 1080, configured to receive a binding operation request sent by the bank server, where the binding operation request at least includes user identity information and bank payment account information, and the binding operation request is sent by the bank server after determining that the user triggers a binding operation on the bank client;

[0200] A fourth sending module 1090, configured to generate a binding message for the binding operation request and send it to the third-party payment client for display.

[0201] Optionally, the account information binding request is sent by the third-party payment client in response to a click operation on the binding message.

[0202] Optionally, before determining that the bank payment account information is successfully bound to the user identification information of the third-party payment client, it further includes:

[0203] A second determination module 1091, configured to determine that the payment password input by the third-party payment client is correct, where the payment password is received by the third-party payment client after displaying a payment password input prompt message and receiving user input.

[0204] Based on the same inventive concept, an apparatus for binding account information is further provided in an embodiment of the present application. The apparatus for binding account information may be, for example, the third-party payment client in the foregoing embodiment, and the apparatus for binding account information may be a hardware structure, a software module, or a combination of a hardware structure and a software module. Based on the above embodiment, refer to Figure 11 As shown, another apparatus for binding account information in an embodiment of the present application specifically includes:

[0205] A first sending module 1100, configured to send an account information binding request to a third-party payment server;

[0206] A first receiving module 1110, configured to receive bank payment account information associated with the account information binding request returned by the third-party payment server;

[0207] The first display module 1120 is configured to display the bank payment account information;

[0208] The second sending module 1130 is configured to send a verification code acquisition request to the third-party payment server in response to a confirmation operation for the bank payment account information;

[0209] The second receiving module 1140 is configured to obtain the input verification code entered by the user;

[0210] The third sending module 1150 is configured to send the input verification code to the third-party payment server, so that after the third-party payment server determines that the input verification code passes the verification, it determines that the binding between the bank payment account information and the account identification information of the third-party payment client is successful.

[0211] Optionally, the first sending module 1100 is specifically configured to:

[0212] Scan the QR code displayed by the bank client, and after parsing the QR code, send an account information binding request to the third-party payment server;

[0213] Wherein, the QR code is generated by the bank client based on the binding address obtained from the bank server, and the binding address is generated by the third-party payment server and sent to the bank server after the bank server sends a binding address acquisition request to the third-party payment server. The binding address acquisition request includes at least user identity information and bank payment account information, and the binding QR code request is sent by the bank client in response to a triggered binding operation.

[0214] Optionally, the first sending module 1100 is specifically configured to:

[0215] In response to a binding message click operation, send an account information binding request to the third-party payment server, wherein the binding message is generated by the third-party payment server for a binding operation request sent by the bank server and sent to the third-party payment client, and the binding operation request includes at least user identity information and bank payment account information.

[0216] Optionally, it further includes:

[0217] The second display module 1160 is configured to display input payment password prompt information and send the input payment password to the third-party payment server for payment password verification.

[0218] Optionally, before sending the verification code acquisition request to the third-party payment server, it further includes:

[0219] The third display module 1170 is configured to display the prompt information for setting the payment password;

[0220] The third receiving module 1180 is configured to receive the input first payment password;

[0221] The fourth display module 1190 is configured to display the prompt information for inputting the payment password;

[0222] The fourth receiving module 1191 is configured to receive the input second payment password;

[0223] The confirmation module 1192 is configured to confirm that the first payment password and the second payment password are the same.

[0224] Based on the above embodiments, refer to Figure 12 The following is a schematic structural diagram of the electronic device in the embodiment of the present application.

[0225] The embodiment of the present application provides an electronic device, which may be the third-party payment server or the third-party payment client in the foregoing embodiments. The electronic device may include a processor 1210 (Center Processing Unit, CPU), a memory 1220, an input device 1230, an output device 1240, and the like.

[0226] The memory 1220 may include a read-only memory (ROM) and a random access memory (RAM), and provide the program instructions and data stored in the memory 1220 to the processor 1210. In the embodiment of the present application, the memory 1220 may be used to store the program of any method for binding account information in the embodiment of the present application.

[0227] By calling the program instructions stored in the memory 1220, the processor 1210 is configured to execute any method for binding account information in the embodiment of the present application according to the obtained program instructions.

[0228] Based on the above embodiments, in the embodiment of the present application, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, the method for binding account information in any of the above method embodiments is implemented.

[0229] Those of ordinary skill in the art can understand that all or part of the steps to implement the above method embodiments can be completed by hardware related to program instructions. The foregoing program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps including those of the above method embodiments; and the foregoing storage medium includes: removable storage devices, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical discs and other various media that can store program codes.

[0230] Alternatively, if the above integrated units of the present invention are implemented in the form of software function modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on such an understanding, the technical solutions of the embodiments of the present invention, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the methods described in the various embodiments of the present invention. And the foregoing storage medium includes: removable storage devices, ROM, RAM, magnetic disks, or optical discs and other various media that can store program codes.

Claims

1. A method for binding account information, characterized in that Applied to a third-party payment server, including: The third-party payment server receives an account information binding request sent by a third-party payment client; the account information binding request is sent by the third-party payment client after scanning a two-dimensional code displayed by a bank client and parsing the two-dimensional code; the two-dimensional code is generated by the bank client based on a binding address obtained from a bank server, and the binding address is generated by the third-party payment server and sent to the bank server after the bank server sends a binding address acquisition request to the third-party payment server. The binding address acquisition request includes at least user identity information and bank payment account information; the binding address acquisition request is sent by the bank server after receiving a two-dimensional code request sent by the bank client, and the two-dimensional code request is sent by the bank client in response to a triggered binding operation; Send the bank payment account information associated with the account information binding request to the third-party payment client for display, where the bank payment account information is sent by the bank server to the third-party payment server after determining that the user has triggered a binding operation on the bank client; Receive a verification code acquisition request sent by the third-party payment client, and send a generated verification code to the communication account corresponding to the bank payment account information, where the verification code acquisition request is sent by the third-party payment client after receiving a confirmation operation for the bank payment account information; Receive the input verification code sent by the third-party payment client, and after determining that the input verification code passes the verification according to the generated verification code, determine that the bank payment account information is successfully bound to the account identification information of the third-party payment client.

2. The method according to claim 1, wherein Further includes: Receive a binding address acquisition request sent by the bank server; Generate a binding address and return the binding address to the bank server, so that the bank server sends the binding address to the bank client to generate and display a two-dimensional code containing the binding address.

3. The method according to claim 1, characterized in that Before determining that the bank payment account information is successfully bound to the user identification information of the third-party payment client, further includes: Determine that the payment password input by the third-party payment client is correct, where the payment password is received by the third-party payment client after displaying a payment password input prompt message and receiving user input.

4. A method for binding account information, characterized in that, Applied to a third-party payment client, including: The third - party payment client scans the QR code displayed by the bank client, and after parsing the QR code, sends an account information binding request to the third - party payment server; the QR code is generated by the bank client based on the binding address obtained from the bank server, and the binding address is generated by the third - party payment server and sent to the bank server after the bank server sends a binding address acquisition request to the third - party payment server. The binding address acquisition request includes at least user identity information and bank payment account information; the binding address acquisition request is sent by the bank server after receiving the QR code request sent by the bank client, and the QR code request is sent by the bank client in response to a triggered binding operation; Receive the bank payment account information associated with the account information binding request returned by the third - party payment server, and display the bank payment account information; wherein, the bank payment account information is sent by the bank server to the third - party payment server after determining that the user triggers a binding operation on the bank client; In response to a confirmation operation for the bank payment account information, send a verification code acquisition request to the third - party payment server, so that the third - party payment server sends a generated verification code to the communication account corresponding to the bank payment account information; Obtain the input verification code entered by the user, and send the input verification code to the third - party payment server, so that the third - party payment server determines that the input verification code is verified through according to the generated verification code, and then determines that the binding of the bank payment account information and the account identification information of the third - party payment client is successful.

5. The method according to claim 4, wherein Further includes: Display a prompt message for entering the payment password, and send the entered payment password to the third - party payment server for payment password verification.

6. The method according to claim 4, wherein Before sending a verification code acquisition request to the third - party payment server, further includes: Display a prompt message for setting the payment password, and receive the entered first payment password; Display a prompt message for entering the payment password, receive the entered second payment password, and confirm that the first payment password and the second payment password are the same.

7. A device for binding account information, characterized in that, Applied to the third - party payment server, includes: A first receiving module, configured to receive an account information binding request sent by the third - party payment client; the account information binding request is sent by the third - party payment client after scanning the QR code displayed by the bank client and parsing the QR code; the QR code is generated by the bank client based on the binding address obtained from the bank server, and the binding address is generated by the third - party payment server and sent to the bank server after the bank server sends a binding address acquisition request to the third - party payment server. The binding address acquisition request includes at least user identity information and bank payment account information; the binding address acquisition request is sent by the bank server after receiving the QR code request sent by the bank client, and the QR code request is sent by the bank client in response to a triggered binding operation; The first sending module is configured to send the bank payment account information associated with the account information binding request to the third-party payment client for display, where the bank payment account information is sent by the bank server to the third-party payment server after determining that the user triggers a binding operation on the bank client; The second receiving module is configured to receive the verification code acquisition request sent by the third-party payment client; The second sending module is configured to send a generated verification code to the communication account corresponding to the bank payment account information, where the verification code acquisition request is sent by the third-party payment client after receiving a confirmation operation for the bank payment account information; The third receiving module is configured to receive the input verification code sent by the third-party payment client; The first determination module is configured to determine that after the input verification code is verified to be passed according to the generated verification code, the bank payment account information is successfully bound to the account identification information of the third-party payment client.

8. A device for binding account information, characterized in that, Applied to the third-party payment client, it includes: The first sending module is configured to scan the two-dimensional code displayed by the bank client, and after parsing the two-dimensional code, send an account information binding request to the third-party payment server; the two-dimensional code is generated by the bank client based on the binding address obtained from the bank server, and the binding address is generated and sent by the third-party payment server to the bank server after the bank server sends a binding address acquisition request to the third-party payment server, and the binding address acquisition request includes at least user identity information and bank payment account information; the binding address acquisition request is sent by the bank server after receiving the two-dimensional code request sent by the bank client, and the two-dimensional code request is sent by the bank client in response to the triggered binding operation; The first receiving module is configured to receive the bank payment account information associated with the account information binding request returned by the third-party payment server; where the bank payment account information is sent by the bank server to the third-party payment server after determining that the user triggers a binding operation on the bank client; The first display module is configured to display the bank payment account information; The second sending module is configured to, in response to a confirmation operation for the bank payment account information, send a verification code acquisition request to the third-party payment server, so that the third-party payment server sends a generated verification code to the communication account corresponding to the bank payment account information; The second receiving module is configured to obtain the input verification code input by the user; The third sending module is configured to send the input verification code to the third-party payment server, so that the third-party payment server determines that after the input verification code is verified to be passed according to the generated verification code, the bank payment account information is successfully bound to the account identification information of the third-party payment client.

9. An electronic device, comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the method according to any one of claims 1-3 or 4-6.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by the processor, it implements the steps of the method according to any one of claims 1-3 or 4-6.

Images