Non-card account binding method, device, server, system and storage medium

Abstract

The application discloses a non-card account binding method and device, a server, a system and a storage medium, and belongs to the field of data processing. The method comprises the following steps: receiving a first list including the identification of the third server from a second server; receiving the ciphertext information corresponding to the first target identification sent by the second server, wherein the first target identification includes the specified third server identification in the first list; and sending the ciphertext information to the target third server, so that the target third server requests the target payment token from the second server by using a token request message, and makes the payment channel server in the target third server and the first server execute the binding token request message of the target payment token and the target non-card account. The token request message includes the ciphertext information. According to the embodiment of the application, the difficulty of the non-card account payment through the payment channel party can be reduced.

Description

Technical Field

[0001] The present application relates to the field of data processing, and in particular to a non-card account binding method, device, server, system and storage medium. Background Art

[0002] With the rise of electronic payment technology, electronic payment methods are becoming increasingly diverse. In addition to using card accounts such as bank cards for payments, non-card accounts can also be used for payments. However, because the issuers of non-card accounts differ from those of card accounts, payments with non-card accounts require development and modification of both the issuer's system and the payment channel's system. This requires that the developed and modified non-card account issuer system and the payment channel system be compatible, enabling payments with non-card accounts through payment channels. However, this development and modification is complex and challenging, making it more difficult for non-card accounts to make payments through payment channels. Summary of the Invention

[0003] The embodiments of the present application provide a non-card account binding method, server, device, system and storage medium, which can reduce the difficulty of non-card accounts making payments through payment channels.

[0004] In a first aspect, an embodiment of the present application provides a non-card account binding method, which is applied to a first server, the first server including a non-card account server and a payment channel server, the method including: receiving a first list including a third server owner identifier sent by a second server, the third server including the non-card account server and the payment channel server; receiving ciphertext information corresponding to a first target identifier sent by the second server, the first target identifier including the third server owner identifier specified in the first list; sending ciphertext information to a target third server, so that the target third server uses a Token request message to request a target payment Token from the second server, so that the target third server and the payment channel server in the first server execute binding of the target payment Token with the target non-card account, the target third server including a third server corresponding to the first target identifier, the Token request message including ciphertext information, and the target non-card account including a designated non-card account managed by the non-card account server in the first server and the target third server.

[0005] In a second aspect, an embodiment of the present application provides a non-card account binding method, which is applied to a second server, the method comprising: sending a first list including a third server owner identifier to a first server, the first server including one of a non-card account server and a payment channel server, and the third server including the other of a non-card account server and a payment channel server; sending ciphertext information corresponding to a first target identifier to the first server, so that the first server sends ciphertext information to a target third server, the first target identifier including a third server owner identifier specified in the first list, and the target third server including a third server corresponding to the first target identifier; in response to a Token request message sent by the target third server, sending a target payment Token allocated for a target payment Token to a payment channel server in the first server and the target third server, so that the payment channel server executes binding of the target payment Token with a target non-card account, the Token request message including ciphertext information, and the target non-card account including a designated non-card account managed by the non-card account server in the first server and the target third server.

[0006] In a third aspect, an embodiment of the present application provides a non-card account binding method, which is applied to a third server, the third server including one of a non-card account server and a payment channel server, the method including: receiving encrypted information sent by a first server, the first server including the other of a non-card account server and a payment channel server, the encrypted information being sent by a second server to the first server according to a first target identifier, the first target identifier including a third server owner identifier of the third server in a first list sent by the second server to the first server; sending a Token request message to the second server so that the second server sends a target payment Token to the third server and the payment channel server in the first server, and enabling the payment channel server to execute the binding of the target payment Token with the target non-card account, the Token request message including encrypted information, and the target non-card account including a designated non-card account managed by the non-card account server in the first server and the third server.

[0007] In a fourth aspect, an embodiment of the present application provides a non-card account binding device, the non-card account binding device includes one of a non-card account server and a payment channel server, the non-card account binding device includes: a receiving module for receiving a first list including a third server owner identifier sent by a second server, the third server including the other of the non-card account server and the payment channel server, and for receiving ciphertext information corresponding to a first target identifier sent by the second server, the first target identifier including the third server owner identifier specified in the first list; a sending module for sending ciphertext information to a target third server, so that the target third server uses a Token request message to request a target payment Token from the second server, so that the target third server and the payment channel server in the first server execute binding of the target payment Token with the target non-card account, the target third server including the third server corresponding to the first target identifier, the Token request message including ciphertext information, and the target non-card account including the designated non-card account managed by the non-card account server in the first server and the target third server.

[0008] In a fifth aspect, an embodiment of the present application provides a non-card account binding device, including: a sending module for sending a first list including a third server owner identifier to a first server, the first server including one of a non-card account server and a payment channel server, the third server including the other of a non-card account server and a payment channel server, and for sending ciphertext information corresponding to a first target identifier to the first server, so that the first server sends ciphertext information to a target third server, the first target identifier including a third server owner identifier specified in the first list, and the target third server including a third server corresponding to the first target identifier; a receiving module for receiving a Token request message sent by the target third server; the sending module is also used to send a target payment Token allocated for a target payment Token to the payment channel server in the first server and the target third server in response to the Token request message, so that the payment channel server executes binding of the target payment Token with a target non-card account, the Token request message including ciphertext information, and the target non-card account including a designated non-card account managed by the non-card account server in the first server and the target third server.

[0009] In the sixth aspect, an embodiment of the present application provides a non-card account binding device, the non-card account binding device includes one of a non-card account server and a payment channel server, the non-card account binding device includes: a receiving module for receiving encrypted information sent by a first server, the first server includes the other of the non-card account server and the payment channel server, the encrypted information is sent by the second server to the first server according to the first target identifier, the first target identifier includes the non-card account binding device owner identifier of the non-card account binding device in the first list sent by the second server to the first server; a sending module for sending a Token request message to the second server, so that the second server sends a target payment Token to the non-card account binding device and the payment channel server in the first server, and enables the payment channel server to execute the binding of the target payment Token with the target non-card account, the Token request message includes encrypted information, and the target non-card account includes a designated non-card account managed by the first server and the non-card account server in the non-card account binding device.

[0010] In a seventh aspect, an embodiment of the present application provides a server comprising: a processor and a memory storing computer program instructions; when the processor executes the computer program instructions, the non-card account binding method of the first aspect is implemented.

[0011] In an eighth aspect, an embodiment of the present application provides a server comprising: a processor and a memory storing computer program instructions; when the processor executes the computer program instructions, the non-card account binding method of the second aspect is implemented.

[0012] In a ninth aspect, an embodiment of the present application provides a server comprising: a processor and a memory storing computer program instructions; when the processor executes the computer program instructions, the non-card account binding method of the third aspect is implemented.

[0013] In the tenth aspect, an embodiment of the present application provides a non-card account binding system, including the server of the seventh aspect, the server of the eighth aspect, and the server of the ninth aspect.

[0014] In the eleventh aspect, an embodiment of the present application provides a computer-readable storage medium, on which computer program instructions are stored. When the computer program instructions are executed by a processor, the non-card account binding method of the first aspect, the second aspect or the third aspect is implemented.

[0015] Embodiments of the present application provide a non-card account binding method, device, server, system, and storage medium. A first server obtains a first list including a third server owner identifier from a second server, and may also obtain ciphertext information corresponding to the third server owner identifier specified in the first list from the second server. The first server sends ciphertext information to a third server corresponding to the specified third server owner identifier, so that the third server uses the ciphertext information to request a target payment token from the second server. The second server may send the target payment token to the third server or a payment channel server in the first server, so that the payment channel server binds the target payment token to a selected target non-card account. After the target non-card account is bound to the target payment token, the target non-card account can use the target payment token to make payments through the payment channel server, i.e., the payment channel party. The target non-card account uses the target payment token to make payments in a similar manner to the card account uses the card token. Therefore, there is basically no need to modify or newly develop the issuer system and payment channel system of the non-card account, reducing the difficulty of non-card accounts making payments through payment channels. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0017] Figure 1 A schematic diagram of an example of an application scenario of the non-card account binding method provided in an embodiment of the present application;

[0018] Figure 2 A schematic diagram of another example of an application scenario of the non-card account binding method provided in an embodiment of the present application;

[0019] Figure 3 A flowchart of an embodiment of the non-card account binding method provided in the first aspect of the present application;

[0020] Figure 4 A flowchart of another embodiment of the non-card account binding method provided in the first aspect of the present application;

[0021] Figure 5 A flowchart of an embodiment of a non-card account binding method provided in the second aspect of the present application;

[0022] Figure 6 A flowchart of another embodiment of the non-card account binding method provided in the second aspect of the present application;

[0023] Figure 7A flowchart of an embodiment of a non-card account binding method provided in the third aspect of the present application;

[0024] Figure 8 This is a flowchart of an example of a non-card account binding process initiated by a non-card account server according to an embodiment of the present application;

[0025] Figure 9 A flowchart of an example of a non-card account payment process provided in an embodiment of the present application;

[0026] Figure 10 This is a flowchart of an example of a non-card account binding process initiated by a non-card account server according to an embodiment of the present application;

[0027] Figure 11 A schematic structural diagram of an embodiment of a non-card account binding device provided in the fourth aspect of the present application;

[0028] Figure 12 A schematic structural diagram of another embodiment of the non-card account binding device provided in the fourth aspect of the present application;

[0029] Figure 13 A schematic structural diagram of an embodiment of a non-card account binding device provided in the fifth aspect of the present application;

[0030] Figure 14 A schematic structural diagram of another embodiment of the non-card account binding device provided in the fifth aspect of the present application;

[0031] Figure 15 A schematic structural diagram of another embodiment of the non-card account binding device provided in the fifth aspect of the present application;

[0032] Figure 16 A schematic structural diagram of an embodiment of a non-card account binding device provided in the sixth aspect of the present application;

[0033] Figure 17 A schematic structural diagram of another embodiment of the non-card account binding device provided in the sixth aspect of the present application;

[0034] Figure 18 A schematic structural diagram of another embodiment of the non-card account binding device provided in the sixth aspect of the present application;

[0035] Figure 19 A structural diagram of an embodiment of a server provided in the seventh aspect of the present application. DETAILED DESCRIPTION

[0036] The features and exemplary embodiments of various aspects of the present application will be described in detail below. In order to make the purpose, technical solutions and advantages of the present application clearer, the present application will be further described in detail below in conjunction with the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain the present application, rather than to limit the present application. For those skilled in the art, the present application can be implemented without the need for some of these specific details. The following description of the embodiments is merely to provide a better understanding of the present application by illustrating the examples of the present application.

[0037] With the rise of electronic payment technology, electronic payment methods are becoming increasingly diverse. In addition to using bank cards and other card accounts for payment, non-card accounts can also be used for payment. Non-card accounts are accounts independent of bank cards. Non-card accounts can include accounts registered with applications that are not linked to bank cards, as well as public transportation accounts, merchant memberships, and other special recharge accounts, though this is not a limitation. Currently, payment channel systems are developed based on the card account issuer's system. However, since non-card account issuers differ from card account issuers, payments from non-card accounts require the development and modification of both the issuer's system and the payment channel system to ensure compatibility, enabling payments from non-card accounts through the payment channel. However, developing and modifying these systems is complex and challenging, making it more difficult for non-card accounts to make payments through the payment channel.

[0038] The embodiments of the present application provide a non-card account binding method, device, server, system and storage medium, which can allocate payment tokens to non-card accounts on different payment channels. By binding the non-card account with the payment token, the development and modification of the issuer system and the payment channel system of the non-card account is reduced or avoided, thereby reducing the difficulty of non-card accounts making payments through payment channels.

[0039] Figure 1 This is a schematic diagram of an example of an application scenario of the non-card account binding method provided in the embodiment of the present application. Figure 1 As shown, the non-card account binding method may involve a non-card account server 11 , a payment channel server 12 and an identification server 13 .

[0040] The non-card account server 11 is the server of the non-card account issuer. The number of non-card account servers 11 is not limited. A single non-card account issuer may deploy one or more non-card account servers 11. The non-card account servers 11 of different non-card account issuers may be different servers. The non-card account server 11 may include a physical server or a virtual server such as a cloud server, though this is not a limitation. The non-card account server 11 manages non-card accounts. In this embodiment of the present application, the non-card account server 11 may interact with the payment channel server 12 and the identification server 13.

[0041] The payment channel server 12 is a server of the payment channel party. The number of payment channel servers 12 is not limited. The same payment channel party may be configured with one or more payment channel servers 12. The payment channel servers 12 of different payment channel parties may be different servers. The payment channel server 12 may include a physical server or a virtual server such as a cloud server, which is not limited here. The payment channel server 12 provides a payment channel to facilitate payment. In the embodiment of the present application, the payment channel server 12 can interact with the non-card account server 11 and the identification server 13.

[0042] The identification server 13 is used to provide payment tokens, i.e., payment identifications, for non-card accounts that make payments through payment channels. That is, the identification server 13 can identify non-card accounts to obtain corresponding payment tokens. The identification server 13 can be specifically implemented as a token service provider (TSP) server, or as a server set including a TSP server and a server dedicated to providing payment tokens for non-card accounts, which is not limited here. The payment token of a non-card account can be composed of characters such as numbers, and can be used as a substitute value for a non-card account to complete payment of a non-card account. The number of identification servers 13 is not limited here. The identification server 13 may include a physical server, or a virtual server such as a cloud server, which is not limited here. In an embodiment of the present application, the identification server 13 can interact with the non-card account server 11 and the payment channel server 12.

[0043] In some embodiments, the non-card account binding method may also involve a user terminal. Figure 2 A schematic diagram of another example of an application scenario of the non-card account binding method provided in an embodiment of the present application. Figure 2 and Figure 1 The difference is that the non-card account binding method may also involve the user terminal 14.

[0044] The user terminal 14 may be configured with applications from non-card account issuers and payment channel providers. The number of non-card account issuer applications and payment channel applications in the user terminal 14 is not limited. The user terminal 14 interacts with the non-card account server 11 and the payment channel server 12 via the non-card account issuer applications and payment channel applications. The user terminal 14 can interact with different non-card account servers 11 and different payment channel servers 12, and this is not limited.

[0045] The specific contents of the non-card account server 11, the payment channel server 12 and the identification server 13 can be found in the above related descriptions and will not be repeated here.

[0046] The following describes the non-card account binding method, server, system and storage medium in the embodiments of the present application in turn.

[0047] The non-card account binding method provided in the embodiment of the present application involves a first server, a second server, and a third server. The first server, the second server, and the third server can interact with each other. The second server may include the identification server in the above example. The first server includes one of the non-card account server and the payment channel server, and the third server includes the other of the non-card account server and the payment channel server. For example, in the case where the first server includes the non-card account server in the above example, the third server includes the payment channel server in the above example. For another example, in the case where the first server includes the payment channel server in the above example, the third server includes the non-card account server in the above example.

[0048] A first aspect of the present application provides a non-card account binding method, which can be applied to a first server, that is, the non-card account binding method can be executed by the first server. Figure 3 This is a flow chart of an embodiment of the non-card account binding method provided in the first aspect of this application. Figure 3 As shown, the non-card account binding method may include steps S201 to S203.

[0049] In step S201, a first list including an identifier of a party to which a third server belongs is received from a second server.

[0050] The first server may obtain the first list from the second server. The first list may include an identifier of the third server. The identifier of the third server is used to identify the owner of the third server, i.e., the identifier of the third server is the identifier of the owner of the third server. For example, the identifier of the third server may include the name of the third server, the number of the third server, etc., which are not limited here. The identifier of the third server in the first list indicates that the owner of the third server supports the non-card account payment function. That is, the second server may provide the identifier of the owner of the third server that supports the non-card account payment function.

[0051] In some examples, the first server includes a non-card account server, and the third server includes a payment channel server. Correspondingly, the first list includes the identifier of the owner of the payment channel server that supports the non-card account payment function, and the owner of the third server includes the payment channel party in the above example.

[0052] In other examples, the first server includes a payment channel server, and the third server includes a non-card account server. Correspondingly, the first list includes the identification of the owner of the non-card account server that supports the non-card account payment function, and the owner of the third server includes the non-card account issuer in the above example.

[0053] In step S202, ciphertext information corresponding to the first target identifier is received from the second server.

[0054] The first target identifier is the identifier of the third server specified in the first list. The first target identifier can be specified by a user through a user terminal. The user terminal can send the user-specified first target identifier to the first server, and the first server can then send the first target identifier to the second server.

[0055] The second server can provide the first server with encrypted information corresponding to the first target identifier. This encrypted information can be used to apply for a payment token for a non-card account in a subsequent step. Specifically, this encrypted information not only corresponds to the first target identifier but also to the owner of the first server.

[0056] In some examples, the first server includes a non-card account server, and the third server includes a payment channel server. Correspondingly, the encrypted information received by the non-card account server corresponds to the owner of the payment channel server, and may also correspond to the owner of the non-card account server.

[0057] In other examples, the first server includes a payment channel server, and the third server includes a non-card account server. Accordingly, the encrypted information received by the payment channel server corresponds to the owner of the non-card account server and may also correspond to the owner of the payment channel server.

[0058] In step S203, the encrypted information is sent to the target third server so that the target third server uses the Token request message to request the target payment Token from the second server, so that the target third server and the payment channel server in the first server execute the binding of the target payment Token and the target non-card account.

[0059] The target third server includes a third server corresponding to the first target identifier, i.e., the target third server is a third server included in the party to which the designated third server belongs. The token request message includes ciphertext information. The first server sends the ciphertext information to the target third server, which can generate a token request message based on the ciphertext information. The token request message is used to request a target payment token from the second server. The target payment token is the payment token obtained using the token request message. In other words, the target payment token is the payment token used by the target non-card account to make payments through the party to which the payment channel server belongs. In response to the token request message, the second server can send the generated target payment token to the payment channel server among the first server and the target third server, which can then bind the target payment token to the target non-card account. In some examples, the first server includes a non-card account server and the third server includes a payment channel server. Accordingly, the second server can send the target payment token to the target third server, which can then bind the target payment token to the target non-card account. In other examples, the first server includes a payment channel server, and the third server includes a non-card account server. Correspondingly, the second server can send the target payment token to the first server, and the first server will perform the binding of the target payment token and the target non-card account.

[0060] It should be noted that the payment tokens corresponding to the same non-card account on different payment channel servers (i.e., different payment channel owners) are different. For example, the target payment token corresponding to target non-card account A1 on payment channel server owner B1 is Token a1, while the target payment token corresponding to target non-card account A1 on payment channel server owner B2 is Token a2.

[0061] The target non-card account includes a designated non-card account managed by a non-card account server on the first server and the target third server. The target non-card account is a designated non-card account, and the method for designating the target non-card account is not limited herein. For example, the target non-card account may include a non-card account of a user currently logged into the first server or the target third server. In another example, the target non-card account may include a non-card account designated by a user terminal to the first server or the target third server via a user operation.

[0062] In some examples, where the first server includes a non-card account server and the third server includes a payment channel server, the target non-card account may include triggering the payment channel server in the non-card account server to obtain a non-card account in the first list.

[0063] In other examples, when the first server includes a payment channel server and the third server includes a non-card account server, the target non-card account includes a designated non-card account managed by the non-card account server.

[0064] In an embodiment of the present application, the first server obtains a first list including an identifier of a party to which the third server belongs from the second server, and may also obtain ciphertext information corresponding to the identifier of the party to which the third server is specified in the first list from the second server. The first server sends ciphertext information to the third server corresponding to the identifier of the party to which the third server belongs, so that the third server uses the ciphertext information to request a target payment token from the second server. The second server may send the target payment token to the third server or the payment channel server in the first server, so that the payment channel server binds the target payment token to the selected target non-card account. After the target non-card account is bound to the target payment token, the target non-card account can use the target payment token to make payments through the party to which the payment channel server belongs, i.e., the payment channel party. The way the target non-card account pays using the target payment token is similar to the way the card account pays using the card token, so there is basically no need to modify or newly develop the issuer system and payment channel system of the non-card account, which reduces the difficulty for the non-card account to make payments through the payment channel party.

[0065] In some embodiments, the first server may request the first list and the ciphertext information from the second server by sending a request message. Figure 4 This is a flowchart of another embodiment of the non-card account binding method provided in the first aspect of this application. Figure 4 and Figure 3 The difference is that Figure 4 The non-card account binding method shown further includes step S204 and step S205.

[0066] In step S204, a list acquisition request message is sent to the second server.

[0067] The list retrieval request message is used to request the first list from the second server. Depending on the type of the first server, the content of the list retrieval request message sent by the first server to the second server may vary. For example, if the first server comprises a non-card account server and the third server comprises a payment channel server, the non-card account server may send a list retrieval request message to the second server. The list retrieval request message may include a non-card account server identifier and a first identifier, where the first identifier represents a request for the identifier of the party that owns the payment channel server. Based on the first identifier, the second server may feedback the first list including the identifier of the party that owns the payment channel server to the non-card account server indicated by the identifier of the non-card account server. For another example, if the first server comprises a payment channel server and the third server comprises a non-card account server, the payment channel server may send a list retrieval request message to the second server. The list retrieval request message may include a payment channel server identifier and a second identifier, where the second identifier represents a request for the identifier of the party that owns the non-card account server. Based on the second identifier, the second server may feedback the first list including the identifier of the party that owns the non-card account server to the payment channel server indicated by the identifier of the payment channel server.

[0068] In step S205, a ciphertext information request message is sent to the second server.

[0069] The ciphertext information request message is used to request ciphertext information from the second server. The ciphertext information corresponding to the same non-card account may differ depending on the payment channel server owner. The ciphertext information request message may include the payment channel server owner identifier, allowing the second server to allocate ciphertext information based on the payment channel server owner.

[0070] For the sake of convenience, the following specifically describes the contents of the non-card account binding process in the first aspect by taking the first server including the non-card account server and the third server including the payment channel server as an example, and taking the first server including the payment channel server and the third server including the non-card account server as an example.

[0071] The following first describes the non-card account binding process in the first aspect when the first server includes a non-card account server and the third server includes a payment channel server.

[0072] In the case where the first server includes a non-card account server and the third server includes a payment channel server, that is, when the non-card account binding process is initiated through the non-card account server, the encrypted information application message may include the first target identifier and the first original token of the target non-card account obtained in advance.

[0073] The first target identifier here may include the identifier of the designated payment channel server. The first original token may be generated by the second server simultaneously with or after the non-card account server activates the non-card account payment function for the target non-card account through the second server. After the second server generates the first original token, the first server (i.e., the non-card account server) may obtain the first original token of the target non-card account from the second server. In some examples, before step S202 above, the first server may obtain the first original token of the target non-card account from the second server.

[0074] The first original token corresponds one-to-one with the non-card account, meaning different non-card accounts correspond to different first original tokens. If the second server assigns ciphertext information to the target non-card account on the payment channel server, the second server can establish a correspondence between the ciphertext information and the first original token. Upon receiving the Token Request message, the second server can search for the first original token corresponding to the ciphertext information based on the ciphertext information in the Token Request message and generate the target payment token based on the first original token and the ciphertext information in the Token Request message.

[0075] In some examples, the ciphertext information application message may also include first payment authority information. The first payment authority information is used to indicate the payment authority of the target non-card account to pay through the payment channel server corresponding to the first target identifier. The payment channel server corresponding to the first target identifier is the payment channel server of the party to which the payment channel server represented by the first target identifier belongs. Payment authority may include payment limit authority, payment scenario authority, etc., which are not limited here. Payment limit authority may include single-day limit authority, single-month limit authority, single-quarter limit authority, single payment limit authority, etc., which are not limited here. Payment scenario authority can limit payment scenarios, such as transportation payment scenarios, payment scenarios at designated merchants, etc., which are not limited here.

[0076] During the process of applying for ciphertext information, the second server can establish a correspondence between the ciphertext information and the first payment authority information in the application ciphertext information, so that in the subsequent process of requesting the target Token using the Token request message including the ciphertext information, the second server can determine the payment authority of the target payment Token based on the ciphertext information, so that the payment authority of the target payment Token is consistent with the payment authority represented by the first payment authority information.

[0077] The first original token corresponds to the target non-card account. In some examples, the non-card account server can use the first original token to manage the target payment tokens corresponding to the target non-card account on different payment channel servers, and set the status, payment permissions, etc. of the target payment tokens corresponding to the target non-card account on different payment channel servers.

[0078] Specifically, the non-card account server may send a first token management message to the second server. The first token management message includes the first original token of the target non-card account. Based on the first original token, the second server may send a list of target payment tokens generated based on the first original token to the non-card account server. The target payment tokens generated based on the first original token are the target payment tokens bound to the target non-card account on the payment channel server. The non-card account server receives the first token list fed back by the second server in response to the first token management message. The first token list includes the target payment tokens generated based on the first original token. The non-card account server sends a first token setting message to the second server. The first token setting message is used to indicate the setting of the status and / or payment permissions of at least some of the target payment tokens in the first token list. The status of the target payment token may include, but is not limited to, a used status and a disabled status. The used status indicates that the target payment token can be used, and the disabled status indicates that the target payment token cannot be used. The specific details of the payment permissions can be found in the description of the first payment permission information above and are not further described here. Based on the first token setting message, the second server may set the status and / or payment permissions of at least some of the target payment tokens indicated in the first token setting message.

[0079] After binding the target non-card account with the target payment token, the target payment token can be used to make payments to the target non-card account through the payment channel server. When the token verification result information in the verification result message received by the target third server indicates that the verification of the payment information and the payment authority of the target payment token is successful, the first server, i.e., the non-card account server, receives the account payment message sent by the target third server. The account payment message includes payment information and the target payment token. The verification result message is obtained by the second server by verifying the payment information and the payment authority of the target payment token based on the payment verification message sent by the target third server. The payment verification message includes payment information and the target payment token. In response to the account payment message, the first server, i.e., the non-card account server, deducts the payment resources indicated by the payment information from the target non-card account bound to the target payment token.

[0080] Specifically, a user can input information into a user terminal, and through an application on the user terminal owned by the target third server (i.e., the payment channel server), trigger the target third server (i.e., the payment channel server) to send a payment verification message to the second server. The payment verification message includes payment information and a target payment token. The payment information may include information such as the payment initiator, payment recipient, payment resource amount, and payment time, but is not limited here. The second server verifies the payment information against the payment permissions of the target payment token and generates token verification result information. Verifying the payment information against the payment permissions of the target payment token verifies whether the payment information complies with the payment permissions of the target payment token. If the payment information complies with the payment permissions of the target payment token, it indicates that the current payment from the target non-card account is within the payment permissions of the target payment token, thus passing the verification. If the payment information does not comply with the payment permissions of the target payment token, it indicates that the current payment from the target non-card account exceeds the payment permissions of the target payment token, thus failing the verification. The token verification result information indicates whether the verification of the payment information against the payment permissions of the target payment token has succeeded. The second server generates a verification result message and sends it to the target third server (i.e., the payment channel server), which includes the token verification result information. If the token verification result information indicates that the verification is successful, the target third server (the payment channel server) sends an account payment message to the first server (the non-card account server). The first server (the non-card account server) deducts the payment resources indicated by the payment information from the target non-card account bound to the target payment token, completing the payment of the target non-card account through the party to which the payment channel server belongs.

[0081] The following is a detailed description of the non-card account binding process in the first aspect when the first server includes a payment channel server and the third server includes a non-card account server.

[0082] In the case where the first server includes a payment channel server and the third server includes a non-card account server, that is, when the non-card account binding process is initiated through the payment channel server, the Token request message also includes the payment channel server owner identifier and the pre-acquired second original Token of the target non-card account.

[0083] The payment channel server owner identifier here specifically refers to the owner identifier of the payment channel server that initiated the non-card account binding process. The second original token can be generated by the non-card account server simultaneously with or after the non-card account server activates the non-card account payment function for the target non-card account through the second server. After the second server generates the second original token, the target third server (i.e., the non-card account server) can obtain the second original token of the target non-card account from the second server.

[0084] The second original token corresponds one-to-one with the non-card account, meaning that different non-card accounts correspond to different second original tokens. In some examples, after step S202, the first server (i.e., the payment channel server) may send a non-card account designation message to the target third server (i.e., the non-card account server), causing the target third server (i.e., the non-card account server) to designate a target non-card account and obtain the second original token for the target non-card account. The target third server (i.e., the non-card account server) may send a non-card account selection trigger message to the user terminal, prompting the user terminal to prompt the user to designate a target non-card account. The user terminal may then send the designated target non-card account to the target third server (i.e., the non-card account server), allowing the target third server (i.e., the non-card account server) to determine the designated target non-card account. The method by which the target third server (i.e., the non-card account server) obtains the second original token may be determined based on whether the target non-card account has activated the non-card account payment function. For example, if the target non-card account has activated the non-card account payment function and the non-card account server has already obtained the second original token from the second server, the non-card account server may obtain the second original token for the target non-card account from within itself. For another example, if the target non-card account has not yet activated the non-card account payment function, the non-card account server may initiate a non-card account payment function activation request to the second server. The second server responds to the non-card account payment function activation request, allocates a second original Token to the target non-card account, and sends the second original Token to the non-card account server, that is, the non-card account server obtains the second original Token from the second server.

[0085] In some examples, the ciphertext information application message may include the user identity information corresponding to the target non-card account. The user identity information corresponding to the target non-card account may include the user identity information generated by the user terminal upon receiving the user's input and transmitted to the payment channel server. Specifically, after the payment channel server receives the ciphertext information, a correspondence may be established between the ciphertext information and the user identity information corresponding to the target non-card account. Before the non-card account server sends a Token request message to the second server, the non-card account server may verify whether the user identity information of the target non-card account and the user identity information corresponding to the ciphertext information are consistent. If they are consistent, the non-card account server then sends a Token request message to the second server.

[0086] In some examples, the token request message may also include second payment permission information. This second payment permission information is used to indicate the target non-card account's payment permission through the first server, i.e., the payment channel server. The second payment permission information may also be used to indicate the target non-card account's payment permission through other payment channel servers owned by the same party as the first server. The specific details of the payment permission can be found in the relevant descriptions in the above embodiments and will not be repeated here.

[0087] During the process of applying for the target payment Token, the second server may establish a correspondence between the target payment Token and the second payment authority information in the Token request message, so that the payment authority of the target payment Token is consistent with the payment authority represented by the second payment authority information.

[0088] The second original token corresponds to the target non-card account. In some examples, the non-card account server can use the second original token to manage the target payment tokens corresponding to the target non-card account on different payment channel servers, and set the status, payment permissions, etc. of the target payment tokens corresponding to the target non-card account on different payment channel servers.

[0089] After binding the target non-card account to the target payment token, the first server (i.e., the payment channel server) can use the target payment token to make payments to the target non-card account. A user can input information into a user terminal, triggering the first server to send a payment verification message to the second server via an application hosted on the user terminal, allowing the second server to verify the payment information and the payment permissions of the target payment token. The payment verification message includes the payment information and the target payment token. The payment information may include information such as the payment initiator, payment recipient, payment resource amount, and payment time, though this information is not limited here. The second server can verify the payment information and the payment permissions of the target payment token, specifically verifying whether the payment information complies with the payment permissions of the target payment token. If the payment information complies with the payment permissions of the target payment token, the verification is successful. If the payment information does not comply with the payment permissions of the target payment token, the verification is unsuccessful, indicating that the payment of the target non-card account exceeds the payment permissions of the target payment token. The second server can verify the payment information and the payment permissions of the target payment token and generate a verification result message. The verification result message includes the token verification result information. The token verification result information indicates whether the payment information and the payment authority of the target payment token have been successfully verified. If the token verification result information indicates successful verification, the first server (i.e., the payment channel server) sends an account payment message to the target third server (i.e., the non-card account server). In response to the account payment message, the target third server (i.e., the non-card account server) deducts the payment resources indicated by the payment information from the target non-card account bound to the target payment token, completing the payment of the target non-card account through the party to which the payment channel server belongs. The account payment message includes the payment information and the target payment token.

[0090] A second aspect of the present application provides a non-card account binding method, which can be applied to a second server, that is, the non-card account binding method can be executed by the second server. Figure 5 This is a flow chart of an embodiment of the non-card account binding method provided in the second aspect of this application. Figure 5 As shown, the non-card account binding method may include steps S301 to S303.

[0091] In step S301, a first list including an identifier of a party to which a third server belongs is sent to a first server.

[0092] The first server includes one of a non-card account server and a payment channel server, and the third server includes the other of the non-card account server and the payment channel server.

[0093] The second server may store the identifiers of the respective third servers that support the non-card account payment function. During the non-card account binding process, the second server may provide the first server with a first list, enabling the first server to identify the non-card account server that corresponds to the non-card account to be bound, or the payment channel server that is required for payment with the non-card account to be bound, from the first list. This is not a limitation.

[0094] In step S302, ciphertext information corresponding to the first target identifier is sent to the first server, so that the first server sends the ciphertext information to the target third server.

[0095] The first target identifier includes an identifier of a third server owner specified in the first list. The target third server includes a third server corresponding to the first target identifier.

[0096] The encrypted information is used to authorize the generation of a payment token for a non-card account. The second server can allocate the encrypted information corresponding to the identifier of the designated third server and provide it to the first server. The first server then sends the encrypted information to the target third server, granting the target third server permission to request the target payment token for the target non-card account.

[0097] In step S303, in response to the Token request message sent by the target third server, the target payment Token allocated for the target payment Token is sent to the payment channel server in the first server and the target third server, so that the payment channel server executes the binding of the target payment Token with the target non-card account.

[0098] The token request message includes encrypted information. The target non-card account includes a designated non-card account managed by a non-card account server on the first server and the target third server. If the first server includes a non-card account server and the third server includes a payment channel server, the target non-card account includes a designated non-card account managed by the first server, and the second server sends the target payment token to the target third server. If the first server includes a payment channel server and the third server includes a non-card account server, the target non-card account includes a designated non-card account managed by the target third server, and the second server sends the target payment token to the first server.

[0099] The specific contents of the above steps S301 to S303 can be found in the relevant descriptions in the above embodiments, which will not be repeated here.

[0100] In an embodiment of the present application, the second server provides the first server with a first list including the identifier of the party to which the third server belongs, and may also provide the first server with ciphertext information corresponding to the identifier of the party to which the third server is specified in the first list. The first server sends ciphertext information to the third server corresponding to the identifier of the party to which the third server belongs, so that the third server uses the ciphertext information to request the target payment Token from the second server. The second server may send the target payment Token to the third server or the payment channel server in the first server, so that the payment channel server binds the target payment Token to the selected target non-card account. After the target non-card account is bound to the target payment Token, the target non-card account can use the target payment Token to make payments through the party to which the payment channel server belongs, i.e., the payment channel party. The way the target non-card account pays using the target payment Token is similar to the way the card account pays using the card Token, so there is basically no need to modify or newly develop the issuer system and payment channel system of the non-card account, which reduces the difficulty for the non-card account to make payments through the payment channel party.

[0101] In some embodiments, the first server may request the first list and the ciphertext information from the second server by sending a request message. Figure 6 This is a flowchart of another embodiment of the non-card account binding method provided in the second aspect of this application. Figure 6 and Figure 5 The difference is that Figure 6 The non-card account binding method shown further includes step S304 and step S305.

[0102] In step S304, a list acquisition request message sent by the first server is received.

[0103] The list acquisition request message is used to request the first list.

[0104] In step S305, a ciphertext information request message sent by the first server is received.

[0105] The ciphertext information request message is used to request ciphertext information.

[0106] The specific contents of step S304 and step S305 can be found in the relevant descriptions in the above embodiments and will not be repeated here.

[0107] For the sake of convenience, the following specifically describes the contents of the non-card account binding process in the second aspect by taking the first server including the non-card account server and the third server including the payment channel server as an example, and taking the first server including the payment channel server and the third server including the non-card account server as an example.

[0108] The following first describes the non-card account binding process in the second aspect when the first server includes a non-card account server and the third server includes a payment channel server.

[0109] In the case where the first server includes a non-card account server and the third server includes a payment channel server, that is, when the non-card account binding process is initiated through the non-card account server, the encrypted information application message may include a first target identifier and a pre-acquired first original Token of the target non-card account. For specific content, please refer to the relevant content in the above embodiment and will not be repeated here.

[0110] In some examples, before sending the encrypted information corresponding to the first target identifier to the first server, the second server may also assign a first original token to the target non-card account and send the first original token of the target non-card account to the first server, i.e., the non-card account server. For specific details, please refer to the relevant descriptions in the above embodiments and will not be repeated here.

[0111] In some examples, the encrypted information request message may also include first payment authority information. The first payment authority information is used to indicate the payment authority of the target non-card account to make payments through the payment channel server corresponding to the first target identifier. For details, please refer to the relevant description in the above embodiments and will not be repeated here.

[0112] The first original Token corresponds to the target non-card account. The non-card account server can use the first original Token to manage the target payment Token corresponding to the target non-card account on different payment channel servers, and set the status, payment authority, etc. of the target payment Token corresponding to the target non-card account on different payment channel servers.

[0113] Specifically, the second server may receive a first Token management message sent by the first server, the first Token management message including the first original Token of the target non-card account. The second server generates a first Token list based on each target payment Token obtained based on the first original Token. The second server sends the first Token list to the first server, so that the first server determines the status and / or payment authority of the target payment Token that needs to be set. The second server receives the first Token setting message sent by the first server, and sets the status and / or payment authority of at least some of the target payment Tokens in the first Token list based on the first Token setting message.

[0114] The specific content of the interaction between the second server and the first server to set the status and / or payment authority of the target payment Token can be found in the relevant description in the above embodiment and will not be repeated here.

[0115] After binding the target non-card account to the target payment token, the user terminal can use the target payment token to make payments to the target non-card account through the payment channel server. The second server receives a payment verification message sent by the target third server, i.e., the payment channel server. The payment verification message includes payment information and the target payment token. The second server can verify whether the payment message complies with the payment authority of the target payment token and generate a verification result message. The verification result message includes token verification result information, which indicates whether the verification of the payment information and the payment authority of the target payment token has been successful. The second server sends the verification result message to the target third server, i.e., the payment channel server, so that if the token verification result information indicates that the verification has been successful, the target third server, i.e., the payment channel server, sends an account payment message to the first server, i.e., the non-card account server, so that the first server, i.e., the non-card account server, deducts the payment resources indicated by the payment information from the target non-card account bound to the target payment token. The account payment message includes payment information and the target payment token.

[0116] The specific contents of the interaction between the second server, the first server and the target third server to use the target payment Token to make payments to non-card accounts can be found in the relevant descriptions in the above embodiments and will not be repeated here.

[0117] The following is a detailed description of the non-card account binding process in the second aspect when the first server includes a payment channel server and the third server includes a non-card account server.

[0118] In the case where the first server includes a payment channel server and the third server includes a non-card account server, that is, when the non-card account binding process is initiated through the payment channel server, the Token request message may also include the payment channel server owner identifier and the pre-acquired second original Token of the target non-card account. For specific content, please refer to the relevant description in the above embodiment and will not be repeated here.

[0119] In some examples, before step S303, the second server may further allocate a second original token for the target non-card account and send the second original token of the target non-card account to the target third server, ie, the non-card account server.

[0120] In some examples, the ciphertext information application message may include user identity information corresponding to the target non-card account. For specific content, please refer to the relevant description in the above embodiments and will not be repeated here.

[0121] In some examples, the Token request message may also include second payment authority information, which is used to indicate the payment authority of the target non-card account to pay through the payment channel server. For specific content, please refer to the relevant description in the above embodiment and will not be repeated here.

[0122] The second original token corresponds to the target non-card account. In some examples, the non-card account server can use the second original token to manage the target payment tokens corresponding to the target non-card account on different payment channel servers, and set the status, payment permissions, etc. of the target payment tokens corresponding to the target non-card account on different payment channel servers.

[0123] Specifically, the second server may receive a second token management message sent by a target third server. The second token management message includes the second original token of the target non-card account. The second server generates a second token list based on each target payment token obtained based on the second original token and sends the second token list to the target third server. Each target payment token obtained based on the second original token is the target payment token bound to the target non-card account on the payment channel server. The target third server (i.e., the non-card account server) receives the second token list and may send it to a user terminal, causing the user terminal to display the second token list via an application of the non-card account server. The user terminal receives user input, determines the status and / or payment permissions of the target payment token to be set, and sends the status and / or payment permissions of the target payment token to be set to the target third server (i.e., the non-card account server). The target third server (i.e., the non-card account server) generates a second token setting message and sends it to the second server. The second server receives the second token setting message sent by the target third server and, based on the second token setting message, sets the status and / or payment permissions of at least some of the target payment tokens in the second token list. The second token setting message indicates that the status and / or payment permissions of at least part of the target payment token to be set are the status and / or payment permissions of the target payment token determined by the user terminal to be set. The specific details of the target payment token status and payment permissions can be found in the relevant descriptions in the above embodiments and are not further described here.

[0124] After binding the target non-card account to the target payment token, the user terminal can use the target payment token to make payments to the target non-card account through the payment channel server. The second server receives the payment verification message sent by the first server, i.e., the payment channel server. The payment verification message includes payment information and the target payment token. The second server verifies whether the payment information complies with the payment authority of the target payment token and generates a verification result message. The verification result message includes token verification result information. The token verification result information indicates whether the verification of the payment information and the payment authority of the target payment token has been successful. The second server sends the verification result message to the first server, i.e., the payment channel server, so that if the token verification result information indicates that the verification has been successful, the first server, i.e., the payment channel server, sends an account payment message to the target third server, i.e., the non-card account server, so that the target third server, i.e., the non-card account server, deducts the payment resources indicated by the payment information from the target non-card account bound to the target payment token. The account payment message includes payment information and the target payment token.

[0125] The specific contents of the interaction between the second server, the first server and the target third server to use the target payment Token to make payments to non-card accounts can be found in the relevant descriptions in the above embodiments and will not be repeated here.

[0126] A third aspect of the present application provides a non-card account binding method, which can be applied to a third server, that is, the non-card account binding method can be executed by the third server. Figure 7 This is a flow chart of an embodiment of the non-card account binding method provided in the third aspect of this application. Figure 7 As shown, the non-card account binding method may include step S401 and step S402.

[0127] In step S401, ciphertext information sent by the first server is received.

[0128] The ciphertext information is sent by the second server to the first server according to the first target identifier. The first target identifier includes a third server owner identifier of the third server in the first list sent by the second server to the first server.

[0129] In step S402, a Token request message is sent to the second server, so that the second server sends the target payment Token to the third server and the payment channel server in the first server, and the payment channel server executes the binding of the target payment Token with the target non-card account.

[0130] The token request message includes encrypted information. The target non-card account includes a designated non-card account managed by a non-card account server on either the first or third server. If the first server includes a non-card account server and the third server includes a payment channel server, the target non-card account includes a designated non-card account managed by the first server, and the second server sends the target payment token to the third server. If the first server includes a payment channel server and the third server includes a non-card account server, the target non-card account includes a designated non-card account managed by the third server, and the second server sends the target payment token to the first server.

[0131] In an embodiment of the present application, the first server obtains a first list including an identifier of the party to which the third server belongs from the second server, and may also obtain ciphertext information corresponding to the identifier of the party to which the third server is specified in the first list from the second server. The third server receives the ciphertext information sent by the first server, and uses a Token request message including the ciphertext information to request a target payment Token from the second server. The second server may send the target payment Token to the third server or the payment channel server in the first server, so that the payment channel server binds the target payment Token to the selected target non-card account. After the target non-card account is bound to the target payment Token, the target non-card account can use the target payment Token to make payments through the party to which the payment channel server belongs, i.e., the payment channel party. The way the target non-card account pays using the target payment Token is similar to the way the card account pays using the card Token, so there is basically no need to modify or newly develop the issuer system and payment channel system of the non-card account, which reduces the difficulty for the non-card account to make payments through the payment channel party.

[0132] For the sake of convenience, the following specifically describes the contents of the non-card account binding process in the third aspect by taking the first server including the non-card account server and the third server including the payment channel server as an example, and taking the first server including the payment channel server and the third server including the non-card account server as an example.

[0133] The following first provides a detailed description of the non-card account binding process in the third aspect when the first server includes a non-card account server and the third server includes a payment channel server.

[0134] In the case where the first server includes a non-card account server and the third server includes a payment channel server, after binding the target non-card account to the target payment token, the target payment token can be used to make payments to the target non-card account through the payment channel server. The third server, i.e., the payment channel server, sends a payment verification message to the second server, so that the second server can verify the payment information and the payment authority of the target payment token. The payment verification message includes the payment information and the target payment token. The third server, i.e., the payment channel server, receives the verification result message sent by the second server. The verification result message includes token verification result information, which indicates whether the verification of the payment information and the payment authority of the target payment token has been successful. If the token verification result information indicates that the verification has been successful, the third server, i.e., the payment channel server, sends an account payment message to the first server, i.e., the non-card account server, so that the first server can deduct the payment resources indicated by the payment information from the target non-card account bound to the target payment token. The account payment message includes the payment information and the target payment token.

[0135] The specific content of the interaction between the third server, the second server and the first server to use the target payment Token to make payments to non-card accounts can be found in the relevant descriptions in the above embodiments and will not be repeated here.

[0136] The following is a detailed description of the non-card account binding process in the third aspect when the first server includes a payment channel server and the third server includes a non-card account server.

[0137] In the case where the first server includes a payment channel server and the third server includes a non-card account server, that is, when the non-card account binding process is initiated through the payment channel server, the Token request message also includes the payment channel server owner identifier and the pre-acquired second original Token of the target non-card account. For specific content, please refer to the relevant description in the above embodiment and will not be repeated here.

[0138] In some examples, before step S402, the third server may receive a non-card account designation message from the first server. In response to the non-card account designation message, the third server designates a target non-card account and obtains the second original token for the target non-card account. The details of how the third server designates the target non-card account and obtains the second original token can be found in the description of the above embodiments and are not further elaborated here.

[0139] In some examples, the Token request message also includes second payment authority information, which is used to indicate the payment authority of the target non-card account to pay through the payment channel server. For specific content, please refer to the relevant description in the above embodiment and will not be repeated here.

[0140] The second original token corresponds to the target non-card account. In some examples, the non-card account server can use the second original token to manage the target payment tokens corresponding to the target non-card account on different payment channel servers, and set the status, payment permissions, etc. of the target payment tokens corresponding to the target non-card account on different payment channel servers.

[0141] Specifically, the third server, i.e., the non-card account server, may send a second token management message to the second server. The second token management message includes the second original token of the target non-card account. The third server, i.e., the non-card account server, receives a second token list fed back by the second server in response to the second token management message. The second token list includes target payment tokens derived based on the second original token. The third server, i.e., the non-card account server, then sends a second token setting message to the second server. The second token setting message is used to indicate the settings of the status and / or payment permissions of at least some of the target payment tokens in the second token list.

[0142] The specific content of the third server interacting with the second server to set the status, payment authority, etc. of the target payment Token corresponding to the target non-card account can be found in the relevant description in the above embodiment and will not be repeated here.

[0143] After binding the target non-card account and the target payment token, the user terminal can use the target payment token to make payments to the target non-card account through the payment channel server. When the token verification result information in the verification result message received by the first server, i.e., the payment channel server, indicates that the verification of the payment information and the payment authority of the target payment token is successful, the third server, i.e., the non-card account server, receives the account payment message sent by the first server, i.e., the payment channel server. The account payment message includes payment information and the target payment token. The verification result message is obtained by the second server by verifying the payment information and the payment authority of the target payment token based on the payment verification message sent by the first server. The payment verification message includes payment information and the target payment token. In response to the account payment message, the third server, i.e., the non-card account server, deducts the payment resources indicated by the payment information from the target non-card account bound to the target payment token.

[0144] The specific content of the interaction between the third server, the second server and the first server to use the target payment Token to make payments to non-card accounts can be found in the relevant descriptions in the above embodiments and will not be repeated here.

[0145] For ease of understanding, the following takes the first server as a non-card account server, the second server as an identification server, and the third server as a payment channel server as an example to illustrate the interactive process of the non-card account binding process. Figure 8 This is a flowchart of an example of a non-card account binding process initiated by a non-card account server provided in an embodiment of the present application. Figure 8 As shown, the non-card account binding process may include steps S501 to S515.

[0146] In step S501, the non-card account server requests the identification server to activate the non-card account payment function for the target non-card account.

[0147] In step S502, the identification server feeds back the first original token of the target non-card account to the non-card account server.

[0148] In step S503, the non-card account server sends a list acquisition request message to the identification server.

[0149] In step S504, the identification server sends a first list to the non-card account server, where the first list includes the identification of the party to which the payment channel server belongs.

[0150] In step S505 , the non-card account server sends a first list to the user terminal.

[0151] In step S506, the user terminal specifies the first target identifier, that is, the identifier of the party to which the payment channel server belongs.

[0152] In step S507, the user terminal sends a first target identifier to the non-card account server.

[0153] In step S508, the non-card account server sends a ciphertext information request message to the identification server. The ciphertext information request message may include the first payment authority information and the first original Token.

[0154] In step S509, the identification server responds to the ciphertext information application message, allocates ciphertext information to the target non-card account at the payment channel server indicated by the first target identifier, and sets the domain control information of the ciphertext information according to the ciphertext information application message.

[0155] The domain control information may include the payment authority indicated by the first payment authority information.

[0156] In step S510, the identification server sends the encrypted information to the non-card account server.

[0157] In step S511, the non-card account server sends the encrypted information to the payment channel server.

[0158] In step S512, the payment channel server sends a Token request message to the identification server, where the Token request message includes ciphertext information.

[0159] In step S513, the identification server allocates a target payment token of the payment channel server to the target non-card account based on the encrypted information and the first original Token, and the domain control information of the target payment token is consistent with the domain control information of the encrypted information.

[0160] In step S514, the identification server sends the target payment Token to the payment channel server.

[0161] In step S515, the payment channel server binds the target non-card account and the target payment token.

[0162] The following uses the example of the first server being a non-card account server, the second server being an identification server, and the third server being a payment channel server to illustrate the process of using the target non-card account for payment after the target non-card account is bound to the target payment token. Figure 9 This is a flowchart of an example of a non-card account payment process provided in an embodiment of the present application. Figure 9 As shown, the non-card account payment process may include steps S516 to S521.

[0163] In step S516, the user terminal sends a payment request message to the payment channel server to request payment using the target non-card account.

[0164] In step S517, the payment channel server sends a payment verification message to the identification server in response to the payment request message. The payment verification message includes payment information and a target payment Token.

[0165] In step S518, the identification server verifies the payment information and the target payment Token according to the payment verification message, and generates a verification result message, which includes Token verification result information.

[0166] In step S519, the identification server sends a verification result message to the payment channel server.

[0167] In step S520, when the Token verification result information indicates that the verification is successful, the payment channel server sends an account payment message to the non-card account server.

[0168] In step S521, the non-card account server responds to the account payment message and deducts the corresponding payment resources from the target non-card account bound to the target payment Token.

[0169] For ease of understanding, the following takes the first server as the payment channel server, the second server as the identification server, and the third server as the non-card account server as an example to illustrate the interactive process of the non-card account binding process. Figure 10 This is a flowchart of an example of a non-card account binding process initiated by a non-card account server provided in an embodiment of the present application. Figure 10 As shown, the non-card account binding process may include steps S601 to S617.

[0170] In step S601, the payment channel server sends a list acquisition request message to the identification server.

[0171] In step S602, the identification server sends a first list to the payment channel server, where the first list includes the identification of the party to which the payment non-card account server belongs.

[0172] In step S603, the payment channel server sends the first list to the user terminal.

[0173] In step S604, the user terminal specifies a first target identifier, that is, an identifier of a party other than the card account server.

[0174] In step S605, the user terminal sends the first target identifier to the payment channel server.

[0175] In step S606, the payment channel server sends a non-card account designation message to the non-card account server.

[0176] In step S607, the non-card account server specifies a target non-card account according to the non-card account specifying message.

[0177] In step S607, the non-card account server sends the target non-card account to the payment channel server to inform the payment channel server of the target non-card account.

[0178] In step S608, the non-card account server requests the identification server to activate the non-card account payment function for the target non-card account.

[0179] In step S609, the identification server feeds back the second original Token of the target non-card account to the non-card account server.

[0180] In step S610, the payment channel server sends a ciphertext information request message to the identification server.

[0181] In step S611, the identification server responds to the ciphertext information request message and allocates ciphertext information to the payment channel server for the target non-card account opened by the non-card account server indicated by the first target identifier.

[0182] In step S612, the identification server sends the encrypted information to the payment channel server.

[0183] In step S613, the payment channel server sends the encrypted information to the non-card account server.

[0184] In step S614, the non-card account server sends a Token request message to the identification server. The Token request message includes ciphertext information, the second payment authority information, and the second original Token.

[0185] In step S615, the identification server responds to the Token request message, allocates a target payment Token of the payment channel server to the target non-card account, and sets the domain control information of the target payment Token according to the Token request message.

[0186] The domain control information may include the payment authority indicated by the second payment authority information.

[0187] In step S616, the identification server sends the target payment Token to the payment channel server.

[0188] In step S617, the payment channel server binds the target non-card account and the target payment Token.

[0189] In the case where the first server is a payment channel server, the second server is an identification server, and the third server is a non-card account server, the process of using the target non-card account to pay after binding the target non-card account with the target payment token is the same as Figure 9 The non-card account payment process shown is basically the same and will not be repeated here.

[0190] A fourth aspect of the present application provides a non-card account binding device, which may include a non-card account server and a payment channel server. Figure 11 This is a structural diagram of an embodiment of a non-card account binding device provided in the fourth aspect of this application. Figure 11 As shown, the non-card account binding device 700 may include a receiving module 701 and a sending module 702 .

[0191] The receiving module 701 may be configured to receive a first list including an identifier of a party to which a third server belongs, sent by the second server, and to receive ciphertext information corresponding to a first target identifier, sent by the second server.

[0192] The third server includes another of a non-card account server and a payment channel server. The first target identifier includes an identifier of a party that owns the third server specified in the first list.

[0193] The sending module 702 can be used to send encrypted information to the target third server, so that the target third server uses the Token request message to request the target payment Token from the second server, so that the target third server and the payment channel server in the non-card account binding device 700 execute the binding of the target payment Token with the target non-card account.

[0194] The target third server includes the third server corresponding to the first target identifier, the Token request message includes ciphertext information, and the target non-card account includes the non-card account binding device 700 and a designated non-card account managed by the non-card account server in the target third server.

[0195] In an embodiment of the present application, the non-card account binding device obtains a first list including a third server owner identifier from the second server, and can also obtain ciphertext information corresponding to the third server owner identifier specified in the first list from the second server. The non-card account binding device sends ciphertext information to the third server corresponding to the specified third server owner identifier, so that the third server uses the ciphertext information to request the target payment token from the second server. The second server can send the target payment token to the third server or the payment channel server in the non-card account binding device, so that the payment channel server binds the target payment token to the selected target non-card account. After the target non-card account is bound to the target payment token, the target non-card account can use the target payment token to make payments through the owner of the payment channel server, that is, the payment channel party. The way the target non-card account uses the target payment token to pay is similar to the way the card account uses the card token to pay, so there is basically no need to modify or newly develop the issuer system and payment channel system of the non-card account, which reduces the difficulty of the non-card account making payments through the payment channel party.

[0196] In some embodiments, the sending module 702 may also be configured to send a list acquisition request message to the second server. The list acquisition request message is used to request the first list from the second server.

[0197] In some embodiments, the sending module 702 may also be configured to send a ciphertext information request message to the second server. The ciphertext information request message is used to request ciphertext information from the second server.

[0198] In some examples, when the non-card account binding device 700 includes a non-card account server and the third server includes a payment channel server, the encrypted information application message includes a first target identifier and a pre-acquired first original token of the target non-card account.

[0199] The receiving module 701 may also be configured to obtain the first original Token of the target non-card account from the second server before the non-card account binding device 700 sends the ciphertext information request message to the second server.

[0200] In some examples, when the non-card account binding device 700 includes a non-card account server and the third server includes a payment channel server, the encrypted information application message may also include first payment authority information, and the first payment authority information is used to indicate the payment authority of the target non-card account to pay through the payment channel server corresponding to the first target identifier.

[0201] In some examples, the non-card account binding device 700 includes a non-card account server, and the third server includes a payment channel server.

[0202] The sending module 702 may also be configured to send a first Token management message to the second server. The first Token management message includes a first original Token of the target non-card account.

[0203] The receiving module 701 may also be configured to receive a first token list fed back by the second server in response to the first token management message. The first token list includes target payment tokens obtained based on the first original token.

[0204] The sending module 702 may also be configured to send a first token setting message to the second server. The first token setting message is configured to indicate the setting of status and / or payment authority for at least some target payment tokens in the first token list.

[0205] Figure 12 This is a schematic diagram of another embodiment of the non-card account binding device provided in the fourth aspect of the present application. The non-card account binding device 700 may include a non-card account server, and the third server includes a payment channel server. Figure 12 and Figure 11 The difference is that Figure 12 The non-card account binding device 700 shown may further include a processing module 703 .

[0206] The receiving module 701 may be configured to receive an account payment message sent by the target third server when the token verification result information in the verification result message received by the target third server indicates that the verification of the payment information and the payment authority of the target payment token is successful.

[0207] The account payment message includes payment information and the target payment token. The verification result message is obtained by the second server verifying the payment information and the payment permission of the target payment token based on the payment verification message sent by the target third server. The payment verification message includes payment information and the target payment token.

[0208] The processing module 703 may be configured to, in response to the account payment message, deduct the payment resources indicated by the payment information from the target non-card account bound to the target payment Token.

[0209] In some examples, when the non-card account binding device 700 includes a payment channel server and the third server includes a non-card account server, the encrypted information application message includes user identity information corresponding to the target non-card account.

[0210] In some examples, when the non-card account binding device 700 includes a payment channel server and the third server includes a non-card account server, the Token request message also includes an identifier of the party to which the payment channel server belongs and a pre-acquired second original Token of the target non-card account.

[0211] In some examples, the non-card account binding device 700 includes a payment channel server, and the third server includes a non-card account server.

[0212] The above-mentioned sending module 702 can also be used to send a non-card account designation message to the target third server after the receiving module 701 receives the encrypted information corresponding to the first target identifier sent by the second server, so that the target third server specifies the target non-card account and obtains the second original Token of the target non-card account.

[0213] In some examples, when the non-card account binding device 700 includes a payment channel server and the third server includes a non-card account server, the Token request message also includes second payment authority information, and the second payment authority information is used to indicate the payment authority of the target non-card account to pay through the non-card account binding device 700.

[0214] In some examples, the non-card account binding device 700 includes a payment channel server, and the third server includes a non-card account server.

[0215] The sending module 702 may also be configured to send a payment verification message to the second server, so that the second server can verify the payment information and the payment authority of the target payment Token.

[0216] The payment verification message includes payment information and target payment token.

[0217] The receiving module 701 may also be configured to receive a verification result message sent by the second server.

[0218] The verification result message includes the token verification result information. The token verification result information indicates whether the payment information and the payment authority of the target payment token have been verified.

[0219] The sending module 702 can also be used to send an account payment message to the target third server when the token verification result information indicates that the verification is successful, so that the target third server deducts the payment resources indicated by the payment information from the target non-card account bound to the target payment token.

[0220] The account payment message includes payment information and target payment token.

[0221] In a fifth aspect, the present application provides a non-card account binding device. Figure 13 This is a structural diagram of an embodiment of a non-card account binding device provided in the fifth aspect of this application. Figure 13 As shown, the non-card account binding device 800 may include a sending module 801 and a receiving module 802 .

[0222] The sending module 801 can be used to send a first list including the identifier of the party to which the third server belongs to the first server, and to send ciphertext information corresponding to the first target identifier to the first server, so that the first server sends the ciphertext information to the target third server.

[0223] The first server includes one of a non-card account server and a payment channel server. The third server includes the other of the non-card account server and the payment channel server. The first target identifier includes an identifier of a third server owner specified in the first list. The target third server includes a third server corresponding to the first target identifier.

[0224] The receiving module 802 may be configured to receive a Token request message sent by a target third server.

[0225] The sending module 801 can also be used to send the target payment Token allocated for the target payment Token to the payment channel server in the first server and the target third server in response to the Token request message, so that the payment channel server executes the binding of the target payment Token with the target non-card account.

[0226] The token request message includes ciphertext information. The target non-card account includes a designated non-card account managed by a non-card account server in the first server and the target third server.

[0227] In an embodiment of the present application, the non-card account binding device provides a first list including a third server owner identifier to the first server, and may also provide the first server with ciphertext information corresponding to the third server owner identifier specified in the first list. The first server sends ciphertext information to the third server corresponding to the specified third server owner identifier, so that the third server uses the ciphertext information to request the target payment token from the non-card account binding device. The non-card account binding device may send the target payment token to the third server or the payment channel server in the first server, so that the payment channel server binds the target payment token to the selected target non-card account. After the target non-card account is bound to the target payment token, the target non-card account can use the target payment token to make payments through the owner of the payment channel server, i.e., the payment channel party. The way the target non-card account uses the target payment token to pay is similar to the way the card account uses the card token to pay, so there is basically no need to modify or newly develop the issuer system and payment channel system of the non-card account, which reduces the difficulty of the non-card account making payments through the payment channel party.

[0228] In some examples, the receiving module 802 may also be configured to receive a list acquisition request message sent by the first server.

[0229] The list acquisition request message is used to request the first list.

[0230] In some examples, the receiving module 802 may also be used to receive a ciphertext information request message sent by the first server.

[0231] The ciphertext information request message is used to request ciphertext information.

[0232] In some examples, when the first server includes a non-card account server and the third server includes a payment channel server, the encrypted information request message includes a first target identifier and a pre-acquired first original token of the target non-card account.

[0233] In some examples, when the first server includes a non-card account server and the third server includes a payment channel server, the encrypted information application message also includes first payment authority information, and the first payment authority information is used to indicate the payment authority of the target non-card account to pay through the payment channel server corresponding to the first target identifier.

[0234] In some examples, when the first server includes a payment channel server and the third server includes a non-card account server, the encrypted information application message includes user identity information corresponding to the target non-card account.

[0235] In some examples, when the first server includes a payment channel server and the third server includes a non-card account server, the token request message also includes an identifier of the party owning the payment channel server and a pre-acquired second original token of the target non-card account.

[0236] In some examples, when the first server includes a payment channel server and the third server includes a non-card account server, the Token request message also includes second payment authority information, and the second payment authority information is used to indicate the payment authority of the target non-card account to pay through the payment channel server.

[0237] Figure 14 This is a structural diagram of another embodiment of the non-card account binding device provided in the fifth aspect of this application. Figure 14 and Figure 13 The difference is that Figure 14 The non-card account binding device 800 shown may further include an identification allocation module 803 , a list generation module 804 , and a setting module 805 .

[0238] When the first server includes a non-card account server and the third server includes a payment channel server, the identification allocation module 803 is used to allocate a first original token to the target non-card account; the above-mentioned sending module 801 can also be used to send the first original token of the target non-card account to the first server.

[0239] In the case where the first server includes a non-card account server and the third server includes a payment channel server, the above-mentioned receiving module 802 can also be used for the first Token management message sent by the first server, and the first Token management message includes the first original Token of the target non-card account; the list generation module 804 can be used to generate a first Token list based on each target payment Token obtained based on the first original Token; the above-mentioned sending module 801 can also be used to send the first Token list to the first server; the above-mentioned receiving module 802 can also be used to receive a first Token setting message sent by the first server; the setting module 805 can be used to set the status and / or payment authority of at least some of the target payment Tokens in the first Token list according to the first Token setting message.

[0240] When the first server includes a payment channel server and the third server includes a non-card account server, the identification allocation module 803 can be used to allocate a second original token for the target non-card account; the above-mentioned sending module 801 can also be used to send the second original token of the target non-card account to the target third server.

[0241] In the case where the first server includes a payment channel server and the third server includes a non-card account server, the above-mentioned receiving module 802 can also be used to receive a second Token management message sent by the target third server, and the second Token management message includes the second original Token of the target non-card account; the list generation module 804 can be used to generate a second Token list based on each target payment Token obtained based on the second original Token; the above-mentioned sending module 801 can also be used to send the second Token list to the target third server; the above-mentioned receiving module 802 can also be used to receive a second Token setting message sent by the target third server; the setting module 805 can be used to set the status and / or payment authority of at least some of the target payment Tokens in the second Token list according to the second Token setting message.

[0242] Figure 15 This is a structural diagram of another embodiment of the non-card account binding device provided in the fifth aspect of this application. Figure 15 and Figure 13 The difference is that Figure 15 The non-card account binding device 800 shown may further include a verification module 806 .

[0243] In the case where the first server includes a non-card account server and the third server includes a payment channel server, the above-mentioned receiving module 802 can also be used to receive a payment verification message sent by the target third server, and the payment message includes payment information and a target payment Token; the verification module 806 can be used to verify whether the payment message complies with the payment authority of the target payment Token, and generate a verification result message, and the verification result message includes Token verification result information, and the Token verification result information indicates whether the verification of the payment information and the payment authority of the target payment Token is passed; the above-mentioned sending module 801 can also be used to send a verification result message to the target third server, so that the target third server sends an account payment message to the first server when the Token verification result information indicates that the verification is passed, and the account payment message includes payment information and the target payment Token, so that the first server deducts the payment resources indicated by the payment information from the target non-card account bound to the target payment Token.

[0244] In the case where the first server includes a payment channel server and the third server includes a non-card account server, the above-mentioned receiving module 802 can also be used to receive a payment verification message sent by the first server, and the payment verification message includes payment information and a target payment Token; the verification module 806 can be used to verify whether the payment information complies with the payment authority of the target payment Token, and generate a verification result message, and the verification result message includes Token verification result information, and the Token verification result information indicates whether the verification of the payment information and the payment authority of the target payment Token is passed; the sending module 801 can also be used to send a verification result message to the first server, so that the first server sends an account payment message to the target third server when the Token verification result information indicates that the verification is passed, and the account payment message includes payment information and the target payment Token, so that the target third server deducts the payment resources indicated by the payment information from the target non-card account bound to the target payment Token.

[0245] A sixth aspect of the present application provides a non-card account binding device, which includes a non-card account server and a payment channel server. Figure 16 This is a structural diagram of an embodiment of a non-card account binding device provided in the sixth aspect of this application. Figure 16 As shown, the non-card account binding device 900 may include a receiving module 901 and a sending module 902 .

[0246] The receiving module 901 may be configured to receive ciphertext information sent by the first server.

[0247] The first server includes the other of a non-card account server and a payment channel server. The second server sends the encrypted information to the first server according to the first target identifier. The first target identifier includes the identifier of the non-card account binding device in the first list of non-card account binding devices sent by the second server to the first server.

[0248] The sending module 902 can be used to send a Token request message to the second server, so that the second server sends the target payment Token to the non-card account binding device and the payment channel server in the first server, and enables the payment channel server to execute the binding of the target payment Token with the target non-card account.

[0249] The token request message includes ciphertext information. The target non-card account includes a designated non-card account managed by the first server and the non-card account server in the non-card account binding device.

[0250] In an embodiment of the present application, the first server obtains a first list including the identifiers of the parties to which the non-card account binding device belongs from the second server, and may also obtain ciphertext information corresponding to the identifiers of the parties to which the non-card account binding device belongs specified in the first list from the second server. The non-card account binding device receives the ciphertext information sent by the first server, and uses the Token request message including the ciphertext information to request the target payment Token from the second server. The second server may send the target payment Token to the non-card account binding device or the payment channel server in the first server, so that the payment channel server binds the target payment Token to the selected target non-card account. After the target non-card account is bound to the target payment Token, the target non-card account can use the target payment Token to make payments through the party to which the payment channel server belongs, i.e., the payment channel party. The way the target non-card account pays using the target payment Token is similar to the way the card account pays using the card Token, so there is basically no need to modify or newly develop the issuer system and payment channel system of the non-card account, which reduces the difficulty for the non-card account to make payments through the payment channel party.

[0251] In some examples, when the first server includes a payment channel server and the third server includes a non-card account server, the token request message also includes an identifier of the party owning the payment channel server and a pre-acquired second original token of the target non-card account.

[0252] In some examples, when the first server includes a payment channel server and the third server includes a non-card account server, the Token request message also includes second payment authority information, and the second payment authority information is used to indicate the payment authority of the target non-card account to pay through the payment channel server.

[0253] Figure 17 This is a structural diagram of another embodiment of the non-card account binding device provided in the sixth aspect of this application. Figure 17 and Figure 16 The difference is that Figure 17 The non-card account binding device 900 shown may further include a designation module 903 .

[0254] When the first server includes a payment channel server and the third server includes a non-card account server, the above-mentioned receiving module 901 can be used to receive a non-card account designation message sent by the first server; the designation module 903 can be used to respond to the non-card account designation message, designate a target non-card account, and obtain a second original Token of the target non-card account.

[0255] In some examples, the first server comprises a payment channel server and the third server comprises a non-card account server.

[0256] The sending module 902 may also be configured to send a second Token management message to the second server.

[0257] The second Token management message includes the second original Token of the target non-card account.

[0258] The receiving module 901 may also be configured to receive a second Token list fed back by the second server in response to the second Token management message.

[0259] The second token list includes target payment tokens obtained based on the second original token.

[0260] The sending module 902 may also be configured to send a second Token setting message to the second server.

[0261] The second Token setting message is used to instruct the setting of the status and / or payment authority of at least some of the target payment Tokens in the second Token list.

[0262] In some examples, the first server comprises a non-card account server and the third server comprises a payment channel server.

[0263] The sending module 902 may also be configured to send a payment verification message to the second server, so that the second server can verify the payment information and the payment authority of the target payment Token.

[0264] The payment verification message includes payment information and target payment token.

[0265] The receiving module 901 may also be configured to receive a verification result message sent by the second server.

[0266] The verification result message includes the token verification result information. The token verification result information indicates whether the payment information and the payment authority of the target payment token have been verified.

[0267] The sending module 902 may also be configured to send an account payment message to the first server when the token verification result information indicates that the verification is successful, so that the first server deducts the payment resources indicated by the payment information from the target non-card account bound to the target payment token.

[0268] The account payment message includes payment information and target payment token.

[0269] Figure 18 This is a structural diagram of another embodiment of the non-card account binding device provided in the sixth aspect of this application. Figure 18 and Figure 16 The difference is that Figure 18The non-card account binding device 900 shown may further include a processing module 904 .

[0270] In the case where the first server includes a payment channel server and the third server includes a non-card account server, the receiving module 901 may be used to receive an account payment message sent by the first server, where the token verification result information in the verification result message received by the first server indicates that the verification of the payment information and the payment authority of the target payment token has been successful. The account payment message includes the payment information and the target payment token. The verification result message is obtained by the second server based on the payment verification message sent by the first server, which verifies the payment information and the payment authority of the target payment token. The payment verification message includes the payment information and the target payment token. The processing module 904 may be used to deduct the payment resources indicated by the payment information from the target non-card account bound to the target payment token in response to the account payment message.

[0271] The seventh aspect of the present application also provides a server. Figure 19 This is a structural diagram of an embodiment of a server provided in the seventh aspect of this application. Figure 19 As shown, the server 1000 includes a memory 1001 , a processor 1002 , and a computer program stored in the memory 1001 and executable on the processor 1002 .

[0272] In an example, the processor 1002 may include a central processing unit (CPU), or an application specific integrated circuit (ASIC), or may be configured to implement one or more integrated circuits of the embodiments of the present application.

[0273] The memory 1001 may include a read-only memory (ROM), a random access memory (RAM), a magnetic disk storage medium device, an optical storage medium device, a flash memory device, an electrical, optical or other physical / tangible memory storage device. Therefore, generally, the memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., a memory device) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the non-card account binding method according to the first aspect of the embodiment of the present application.

[0274] The processor 1002 runs a computer program corresponding to the executable program code by reading the executable program code stored in the memory 1001 , so as to implement the non-card account binding method of the first aspect of the above embodiment.

[0275] In one example, the server 1000 may further include a communication interface 1003 and a bus 1004. Figure 19 As shown, the memory 1001, the processor 1002, and the communication interface 1003 are connected via a bus 1004 and communicate with each other.

[0276] The communication interface 1003 is mainly used to implement communication between the modules, devices, units and / or equipment in the embodiment of the present application. Input devices and / or output devices can also be connected through the communication interface 1003.

[0277] The bus 1004 includes hardware, software, or both, and couples the components of the server 1000 to each other. By way of example, and not limitation, the bus 1004 may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an InfiniBand interconnect, a Low Pin Count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-E) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local Bus (VLB) bus, or other suitable buses, or a combination of two or more of the above. Where appropriate, the bus 1004 may include one or more buses. Although embodiments herein describe and illustrate a particular bus, this application contemplates any suitable bus or interconnect.

[0278] The eighth aspect of the present application further provides a server. The structure of the server provided in the eighth aspect may refer to the structure of the server in the embodiment of the seventh aspect. The processor in the server provided in the eighth aspect reads executable program code stored in a memory to run a computer program corresponding to the executable program code, thereby implementing the non-card account binding method of the second aspect of the above-mentioned embodiment. Detailed description thereof is omitted here.

[0279] A ninth aspect of the present application further provides a server. The structure of the server provided in the ninth aspect may be referenced to the structure of the server in the seventh aspect. The processor in the server provided in the ninth aspect reads executable program code stored in a memory to run a computer program corresponding to the executable program code, thereby implementing the non-card account binding method of the third aspect of the aforementioned embodiment. A detailed description thereof will not be repeated here.

[0280] In a tenth aspect, the present application further provides a non-card account binding system. The non-card account binding system may include the first server, the second server, and the third server in the above-mentioned embodiment. For details, please refer to the relevant descriptions in the above-mentioned embodiment and will not be repeated here.

[0281] In an eleventh aspect of the present application, a computer-readable storage medium is provided, on which computer program instructions are stored. When the computer program instructions are executed by a processor, the non-card account binding method of the first aspect, the non-card account binding method of the second aspect, or the non-card account binding method of the third aspect of the above-mentioned embodiment can be implemented, and the same technical effects can be achieved. To avoid repetition, they are not described here. The above-mentioned computer-readable storage medium may include a non-transitory computer-readable storage medium, such as a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc., which is not limited here.

[0282] It should be clear that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. For device embodiments, server embodiments, system embodiments, and computer-readable storage medium embodiments, the relevant parts can be referred to the description part of the method embodiment. This application is not limited to the specific steps and structures described above and shown in the figures. Those skilled in the art can make various changes, modifications and additions, or change the order between the steps after understanding the spirit of this application. In addition, for the sake of brevity, a detailed description of known method technologies is omitted here.

[0283] Aspects of the present application have been described above with reference to the flowcharts and / or block diagrams of the methods, devices (systems) and computer program products according to the embodiments of the present application. It should be understood that each box in the flowchart and / or block diagram and the combination of each box in the flowchart and / or block diagram can be implemented by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer or other programmable data processing device to produce a machine so that these instructions executed via the processor of the computer or other programmable data processing device enable the implementation of the function / action specified in one or more boxes of the flowchart and / or block diagram. This processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor or a field programmable logic circuit. It is also understood that each box in the block diagram and / or the flowchart and the combination of the boxes in the block diagram and / or the flowchart can also be implemented by the dedicated hardware that performs the specified function or action, or can be implemented by the combination of dedicated hardware and computer instructions.

[0284] Those skilled in the art should understand that the above embodiments are illustrative rather than restrictive. Different technical features appearing in different embodiments can be combined to achieve beneficial effects. Based on a study of the drawings, the specification and the claims, those skilled in the art should be able to understand and implement other variations of the disclosed embodiments. In the claims, the term "comprising" does not exclude other devices or steps; the quantifier "one" does not exclude a plurality; the terms "first" and "second" are used to identify names rather than to indicate any specific order. Any figure marks in the claims should not be understood as limiting the scope of protection. The functions of multiple parts appearing in the claims can be implemented by a separate hardware or software module. The fact that certain technical features appear in different dependent claims does not mean that these technical features cannot be combined to achieve beneficial effects.

Claims

1. A non-card account binding method, characterized in that: Applied to a first server, the first server comprising one of a non-card account server and a payment channel server, the method comprising: receiving a first list including an identifier of a third server sent by the second server, wherein the third server includes the other of the non-card account server and the payment channel server; receiving ciphertext information corresponding to a first target identifier sent by the second server, where the first target identifier includes an identifier of the party to which the third server specified in the first list belongs; The ciphertext information is sent to the target third server so that the target third server uses the Token request message to request the target payment Token from the second server, so that the target third server and the payment channel server in the first server execute the binding of the target payment Token and the target non-card account, the target third server includes the third server corresponding to the first target identifier, the Token request message includes the ciphertext information, and the target non-card account includes the designated non-card account managed by the first server and the non-card account server in the target third server.

2. The method according to claim 1, characterized in that Before receiving the first list including the identifier of the party to which the third server belongs, the method further includes: A list acquisition request message is sent to the second server, where the list acquisition request message is used to request the first list from the second server.

3. The method according to claim 1, characterized in that Before receiving the ciphertext information corresponding to the first target identifier sent by the second server, the method further includes: Send a ciphertext information request message to the second server, where the ciphertext information request message is used to request the ciphertext information from the second server.

4. The method according to claim 3, characterized in that In the case where the first server includes a non-card account server and the third server includes a payment channel server, the encrypted information request message includes the first target identifier and a pre-acquired first original token of the target non-card account.

5. The method according to claim 4, characterized in that The encrypted information application message also includes first payment authority information, where the first payment authority information is used to indicate the payment authority of the target non-card account to pay through the payment channel server corresponding to the first target identifier.

6. The method according to claim 4, characterized in that Before sending the ciphertext information request message to the second server, the method further includes: Obtain the first original Token of the target non-card account from the second server.

7. The method according to claim 3, characterized in that In a case where the first server includes a payment channel server and the third server includes a non-card account server, the ciphertext information application message includes user identity information corresponding to the target non-card account.

8. The method according to claim 1, characterized in that The Token request message also includes the payment channel server owner identifier and the pre-acquired second original Token of the target non-card account.

9. The method according to claim 8, characterized in that The Token request message further includes second payment authority information, where the second payment authority information is used to indicate the payment authority of the target non-card account to pay through the first server.

10. The method according to claim 8, characterized in that After receiving the ciphertext information corresponding to the first target identifier sent by the second server, the method further includes: A non-card account designation message is sent to the target third server, so that the target third server designates the target non-card account and obtains the second original Token of the target non-card account.

11. The method according to claim 4, characterized in that Also includes: Sending a first token management message to the second server, where the first token management message includes the first original token of the target non-card account; receiving a first token list fed back by the second server in response to the first token management message, wherein the first token list includes each of the target payment tokens obtained based on the first original token; A first Token setting message is sent to the second server, where the first Token setting message is used to indicate the setting of status and / or payment authority of at least some of the target payment Tokens in the first Token list.

12. The method according to claim 1, characterized in that The first server includes a non-card account server, and the third server includes a payment channel server. The method further comprises: In the case where the Token verification result information in the verification result message received by the target third server indicates that the verification of the payment information and the payment authority of the target payment Token is passed, receiving an account payment message sent by the target third server, the account payment message including the payment information and the target payment Token, the verification result message being obtained by the second server verifying the payment information and the payment authority of the target payment Token based on the payment verification message sent by the target third server, the payment verification message including the payment information and the target payment Token; In response to the account payment message, the payment resource indicated by the payment information is deducted from the target non-card account bound to the target payment Token.

13. The method according to claim 1, wherein The first server includes a payment channel server, and the third server includes a non-card account server. The method further comprises: Sending a payment verification message to the second server, the payment verification message including the payment information and the target payment token, so that the second server verifies the payment information and the payment authority of the target payment token; receiving a verification result message sent by the second server, the verification result message including token verification result information, the token verification result information indicating whether verification of the payment information and the payment authority of the target payment token is successful; When the Token verification result information indicates that the verification is passed, an account payment message is sent to the target third server, and the account payment message includes the payment information and the target payment Token, so that the target third server deducts the payment resources indicated by the payment information from the target non-card account bound to the target payment Token.

14. A non-card account binding method, characterized in that: Applied to the second server, the method includes: Sending a first list including an identifier of a third server to a first server, where the first server includes one of a non-card account server and a payment channel server, and the third server includes the other of the non-card account server and the payment channel server; Sending ciphertext information corresponding to a first target identifier to the first server, so that the first server sends the ciphertext information to a target third server, where the first target identifier includes an identifier of the third server specified in the first list, and the target third server includes the third server corresponding to the first target identifier; In response to the Token request message sent by the target third server, the target payment Token allocated to the target non-card account is sent to the first server and the payment channel server in the target third server, so that the payment channel server executes the binding of the target payment Token with the target non-card account, the Token request message includes the ciphertext information, and the target non-card account includes the designated non-card account managed by the non-card account server in the first server and the target third server.

15. The method according to claim 14, characterized in that Before sending the first list including the identifier of the party to which the third server belongs to the first server, the method further includes: A list acquisition request message sent by the first server is received, where the list acquisition request message is used to request the first list.

16. The method according to claim 14, characterized in that Before sending the ciphertext information corresponding to the first target identifier to the first server, the method further includes: Receive a ciphertext information request message sent by the first server, where the ciphertext information request message is used to request the ciphertext information.

17. The method according to claim 16, characterized in that In the case where the first server includes a non-card account server and the third server includes a payment channel server, the encrypted information request message includes the first target identifier and a pre-acquired first original token of the target non-card account.

18. The method according to claim 17, characterized in that The encrypted information application message also includes first payment authority information, where the first payment authority information is used to indicate the payment authority of the target non-card account to pay through the payment channel server corresponding to the first target identifier.

19. The method according to claim 17, wherein Before sending the ciphertext information corresponding to the first target identifier to the first server, the method further includes: Allocating the first original Token to the target non-card account; Send the first original Token of the target non-card account to the first server.

20. The method according to claim 16, wherein In a case where the first server includes a payment channel server and the third server includes a non-card account server, the ciphertext information application message includes user identity information corresponding to the target non-card account.

21. The method according to claim 14, wherein The Token request message also includes the payment channel server owner identifier and the pre-acquired second original Token of the target non-card account.

22. The method according to claim 21, characterized in that The Token request message also includes second payment authority information, where the second payment authority information is used to indicate the payment authority of the target non-card account to pay through the payment channel server.

23. The method according to claim 21, characterized in that Before sending the target payment Token allocated for the target payment Token to the payment channel server in the first server and the target third server in response to the Token request message sent by the target third server, the method further includes: Allocate the second original Token to the target non-card account; Send the second original Token of the target non-card account to the target third server.

24. The method according to claim 17, wherein Also includes: receiving a first token management message sent by the first server, where the first token management message includes the first original token of the target non-card account; Generate a first token list based on each of the target payment tokens obtained based on the first original token; Sending the first Token list to the first server; Receive a first Token setting message sent by the first server; According to the first Token setting message, the status and / or payment authority of at least some of the target payment Tokens in the first Token list are set.

25. The method according to claim 21, characterized in that Also includes: receiving a second Token management message sent by the target third server, where the second Token management message includes the second original Token of the target non-card account; Generate a second token list based on each of the target payment tokens obtained based on the second original token; Sending the second Token list to the target third server; Receive a second Token setting message sent by the target third server; According to the second Token setting message, the status and / or payment authority of at least some of the target payment Tokens in the second Token list are set.

26. The method according to claim 14, wherein The first server includes a non-card account server, and the third server includes a payment channel server. The method further comprises: Receive a payment verification message sent by the target third server, wherein the payment verification message includes payment information and the target payment token; Verify whether the payment information complies with the payment authority of the target payment token, and generate a verification result message, wherein the verification result message includes token verification result information, and the token verification result information indicates whether the payment information is verified against the payment authority of the target payment token; The verification result message is sent to the target third server, so that the target third server sends an account payment message to the first server when the Token verification result information indicates that the verification is passed. The account payment message includes the payment information and the target payment Token, so that the first server deducts the payment resources indicated by the payment information from the target non-card account bound to the target payment Token.

27. The method according to claim 14, wherein The first server includes a payment channel server, and the third server includes a non-card account server. The method further comprises: receiving a payment verification message sent by the first server, the payment verification message including payment information and the target payment token; Verify whether the payment information complies with the payment authority of the target payment token, and generate a verification result message, wherein the verification result message includes token verification result information, and the token verification result information indicates whether the payment information is verified against the payment authority of the target payment token; The verification result message is sent to the first server, so that the first server sends an account payment message to the target third server when the Token verification result information indicates that the verification is passed. The account payment message includes the payment information and the target payment Token, so that the target third server deducts the payment resources indicated by the payment information from the target non-card account bound to the target payment Token.

28. A non-card account binding method, characterized in that: Applied to a third server, the third server comprising one of a non-card account server and a payment channel server, the method comprising: receiving encrypted information sent by a first server, the first server including the other of the non-card account server and the payment channel server, the encrypted information being sent by the second server to the first server according to a first target identifier, the first target identifier including a third server owner identifier of the third server in the first list sent by the second server to the first server; A Token request message is sent to the second server so that the second server sends a target payment Token to the third server and the payment channel server in the first server, and the payment channel server executes binding of the target payment Token with a target non-card account, wherein the Token request message includes the ciphertext information, and the target non-card account includes a designated non-card account managed by the non-card account server in the first server and the third server.

29. The method according to claim 28, characterized in that In the case where the first server includes a payment channel server and the third server includes a non-card account server, the Token request message further includes an identifier of the party to which the payment channel server belongs and a pre-acquired second original Token of the target non-card account.

30. The method according to claim 29, wherein The Token request message also includes second payment authority information, where the second payment authority information is used to indicate the payment authority of the target non-card account to pay through the payment channel server.

31. The method according to claim 29, wherein Before sending the Token request message to the second server, the method further includes: receiving a non-card account designation message sent by the first server; In response to the non-card account designation message, designate the target non-card account; Obtain the second original token of the target non-card account.

32. The method according to claim 29, wherein Also includes: Sending a second token management message to the second server, where the second token management message includes the second original token of the target non-card account; receiving a second token list fed back by the second server in response to the second token management message, wherein the second token list includes each of the target payment tokens obtained based on the second original token; A second Token setting message is sent to the second server, where the second Token setting message is used to indicate the setting of status and / or payment authority of at least some of the target payment Tokens in the second Token list.

33. The method according to claim 28, wherein The first server includes a non-card account server, and the third server includes a payment channel server. The method further comprises: Sending a payment verification message to the second server, the payment verification message including the payment information and the target payment token, so that the second server verifies the payment information and the payment authority of the target payment token; receiving a verification result message sent by the second server, the verification result message including token verification result information, the token verification result information indicating whether verification of the payment information and the payment authority of the target payment token is successful; When the Token verification result information indicates that the verification is passed, an account payment message is sent to the first server, where the account payment message includes the payment information and the target payment Token, so that the first server deducts the payment resources indicated by the payment information from the target non-card account bound to the target payment Token.

34. The method according to claim 28, wherein The first server includes a payment channel server, and the third server includes a non-card account server. The method further comprises: If the token verification result information in the verification result message received by the first server indicates that the verification of the payment information and the payment authority of the target payment Token is successful, the second server receives an account payment message sent by the first server, the account payment message including the payment information and the target payment Token, and the verification result message is obtained by the second server verifying the payment information and the payment authority of the target payment Token based on the payment verification message sent by the first server, the payment verification message including the payment information and the target payment Token; In response to the account payment message, the payment resource indicated by the payment information is deducted from the target non-card account bound to the target payment Token.

35. A non-card account binding device, characterized in that: The non-card account binding device includes one of a non-card account server and a payment channel server, and the non-card account binding device includes: a receiving module, configured to receive a first list including a third server owner identifier sent by a second server, the third server including the other of the non-card account server and the payment channel server, and to receive ciphertext information corresponding to a first target identifier sent by the second server, the first target identifier including the third server owner identifier specified in the first list; A sending module is used to send the encrypted information to a target third server, so that the target third server uses a Token request message to request a target payment Token from the second server, so that the target third server and the payment channel server in the first server execute the binding of the target payment Token with the target non-card account. The target third server includes the third server corresponding to the first target identifier, the Token request message includes the encrypted information, and the target non-card account includes a designated non-card account managed by the first server and the non-card account server in the target third server.

36. A non-card account binding device, characterized in that: include: a sending module, configured to send a first list including identifiers of third server owners to a first server, the first server including one of a non-card account server and a payment channel server, and the third server including the other of the non-card account server and the payment channel server, and to send ciphertext information corresponding to a first target identifier to the first server, so that the first server sends the ciphertext information to a target third server, the first target identifier including identifiers of the third server owners specified in the first list, and the target third server including the third server corresponding to the first target identifier; A receiving module, configured to receive a Token request message sent by the target third server; The sending module is also used to send the target payment Token allocated to the target non-card account to the payment channel server in the first server and the target third server in response to the Token request message, so that the payment channel server executes the binding of the target payment Token with the target non-card account, the Token request message includes the ciphertext information, and the target non-card account includes the designated non-card account managed by the non-card account server in the first server and the target third server.

37. A non-card account binding device, characterized in that: The non-card account binding device includes one of a non-card account server and a payment channel server, and the non-card account binding device includes: a receiving module, configured to receive ciphertext information sent by a first server, the first server including the other of the non-card account server and the payment channel server, the ciphertext information being sent by a second server to the first server according to a first target identifier, the first target identifier including a non-card account binding device owner identifier of the non-card account binding device in a first list sent by the second server to the first server; A sending module is used to send a Token request message to the second server, so that the second server sends a target payment Token to the non-card account binding device and the payment channel server in the first server, and enables the payment channel server to perform binding of the target payment Token with the target non-card account, the Token request message includes the ciphertext information, and the target non-card account includes a designated non-card account managed by the first server and the non-card account server in the non-card account binding device.

38. A server, characterized in that: include: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, the non-card account binding method according to any one of claims 1 to 13 is implemented.

39. A server, characterized in that: include: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, the non-card account binding method according to any one of claims 14 to 27 is implemented.

40. A server, characterized in that: include: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, it implements the non-card account binding method according to any one of claims 28 to 34.

41. A non-card account binding system, characterized in that: Including the server as claimed in claim 38, the server as claimed in claim 39 and the server as claimed in claim 40.

42. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer program instructions, which, when executed by a processor, implement the non-card account binding method according to any one of claims 1 to 34.

Images