Payment methods, apparatuses, devices, systems, and media

Abstract

The application discloses a payment method, device, equipment, system and medium. The method is applied to a first electronic wallet platform, and includes the following steps: when the remaining resource value of a first payment account bound to the first electronic wallet is smaller than the required resource value of a to-be-paid order, sending a first account obtaining request to a second electronic wallet platform; receiving a second payment account with a binding relationship with the second electronic wallet fed back by the second electronic wallet platform; sending a second account obtaining request to a payment platform; receiving a third payment account with a remaining resource value not smaller than the required resource value fed back by the payment platform; and sending the to-be-paid order and the third payment account to the payment platform via a background system of a merchant, so that the payment platform pays the to-be-paid order by using the remaining resource in the third payment account. According to the embodiment of the application, the payment can be completed when the remaining resource value of the payment account with the binding relationship with the electronic wallet is smaller than the required resource value.

Description

Technical Field

[0001] The present application relates to the field of electronic payment technology, and in particular to a payment method, device, equipment, system and medium. Background Art

[0002] With the rapid development of mobile payments, more and more users are using e-wallets for online payments. To use e-wallets for online payments, it is often necessary to bind a payment account to the e-wallet so that payments can be made through the bound payment account. If the remaining resource value in the payment account bound to the e-wallet is less than the required resource value of the order to be paid, the payment cannot be completed, resulting in a poor payment experience for users.

[0003] Therefore, there is an urgent need for a payment method that can complete payment when the remaining resource value in the payment account bound to the electronic wallet is less than the required resource value of the order to be paid, thereby improving the user's payment experience. Summary of the Invention

[0004] The embodiments of the present application provide a payment method, apparatus, device, system, computer-readable storage medium, and computer program product, which can complete payment when the remaining resource value in a payment account bound to an electronic wallet is less than the required resource value of an order to be paid, thereby improving the user's payment experience.

[0005] In a first aspect, an embodiment of the present application provides a payment method, which is applied to a first electronic wallet platform, wherein the first electronic wallet platform includes a backend server of a first electronic wallet, and the first electronic wallet is bound to a first payment account. The method includes:

[0006] When the remaining resource value in the first payment account is less than the required resource value of the order to be paid, sending a first account acquisition request to a second e-wallet platform, where the second e-wallet platform includes a backend server of the second e-wallet, and the first account acquisition request is used to request a second payment account that is bound to the second e-wallet;

[0007] Receiving the second payment account number fed back by the second electronic wallet platform in response to the first account acquisition request;

[0008] Sending a second account acquisition request to the payment platform, where the second account acquisition request is used to request a third payment account whose remaining resource value is greater than or equal to the required resource value to be determined in the second payment account;

[0009] Receiving the third payment account number fed back by the payment platform in response to the second account acquisition request;

[0010] The order to be paid and the third payment account are sent to the payment platform via the merchant's backend system, so that the payment platform uses the remaining resources in the third payment account to pay for the order to be paid.

[0011] In a second aspect, an embodiment of the present application provides a payment method applied to a second electronic wallet platform, wherein the second electronic wallet platform includes a backend server of the second electronic wallet, and the method includes:

[0012] receiving a first account acquisition request sent by a first e-wallet platform, the first account acquisition request being generated by the first e-wallet platform when a remaining resource value in a first payment account is less than a required resource value for an order to be paid, the first e-wallet platform including a backend server for the first e-wallet, the first payment account being bound to the first e-wallet, and the first account acquisition request being used to request acquisition of a second payment account being bound to the second e-wallet;

[0013] Responding to the first account acquisition request, acquiring the second payment account;

[0014] The second payment account is sent to the first e-wallet platform so that the first e-wallet platform obtains a third payment account based on the second payment account, and the order to be paid and the third payment account are sent to the payment platform via the merchant's backend system so that the payment platform uses the remaining resources in the third payment account to pay for the order to be paid. The third payment account is a payment account in which the remaining resource value in the second payment account is greater than or equal to the required resource value.

[0015] In a third aspect, an embodiment of the present application provides a payment method, applied to a payment platform, comprising:

[0016] receiving a second account acquisition request sent by a first e-wallet platform, the second account acquisition request being used to request a third payment account whose remaining resource value is greater than or equal to the required resource value of the order to be paid, in the second payment account; the second account acquisition request being generated by the first e-wallet platform when the remaining resource value in the first payment account is less than the required resource value of the order to be paid; the first e-wallet platform including a backend server of the first e-wallet; the first payment account being bound to the first e-wallet; and the second payment account being a payment account bound to the second e-wallet;

[0017] In response to the second account acquisition request, acquiring the remaining resource value of the second payment account from the resource management server to which the second payment account belongs;

[0018] If the remaining resource value of the second payment account is greater than or equal to the required resource value, determining the second payment account as the third payment account;

[0019] Sending the third payment account to the first electronic wallet platform;

[0020] Receiving the order to be paid and the third payment account sent by the first electronic wallet platform via the merchant's backend system;

[0021] The remaining resources in the third payment account are used to pay for the order to be paid.

[0022] In a fourth aspect, an embodiment of the present application provides a payment method, applied to a second electronic wallet, the method comprising:

[0023] receiving a first account acquisition request sent by a first e-wallet, the first account acquisition request being generated by the first e-wallet platform and sent to the first e-wallet when a remaining resource value in a first payment account is less than a required resource value of an order to be paid, the first payment account being bound to the first e-wallet, the first account acquisition request being used to request acquisition of a second payment account being bound to the second e-wallet, and the first e-wallet platform including a backend server of the first e-wallet;

[0024] In response to the first account acquisition request, acquiring the second payment account from a security module of a target electronic device, where the target electronic device is the electronic device where the second electronic wallet is located;

[0025] The second payment account is sent to the first electronic wallet so that the first electronic wallet sends the second payment account to the first electronic wallet platform, and the first electronic wallet platform obtains a third payment account based on the second payment account, and sends the order to be paid and the third payment account to the payment platform via the merchant's backend system, so that the payment platform uses the remaining resources in the third payment account to pay for the order to be paid. The third payment account is a payment account in which the remaining resource value in the second payment account is greater than or equal to the required resource value.

[0026] In a fifth aspect, an embodiment of the present application provides a payment device, applied to a first electronic wallet platform, wherein the first electronic wallet includes a backend server of the first electronic wallet, and the first electronic wallet is bound to a first payment account, and the device includes:

[0027] a first sending module configured to send a first account acquisition request to a second e-wallet platform when the remaining resource value in the first payment account is less than the required resource value of the order to be paid, the second e-wallet platform including a backend server of the second e-wallet, the first account acquisition request being used to request acquisition of a second payment account bound to the second e-wallet;

[0028] a first receiving module, configured to receive the second payment account number fed back by the second electronic wallet platform in response to the first account acquisition request;

[0029] The first sending module is further configured to send a second account acquisition request to the payment platform, wherein the second account acquisition request is configured to request a third payment account whose remaining resource value is greater than or equal to the required resource value to be determined in the second payment account;

[0030] The first receiving module is further configured to receive the third payment account number fed back by the payment platform in response to the second account number acquisition request;

[0031] The first sending module is further configured to send the order to be paid and the third payment account to the payment platform via the merchant's backend system, so that the payment platform uses the remaining resources in the third payment account to pay for the order to be paid.

[0032] In a sixth aspect, an embodiment of the present application provides a payment device, which is applied to a second electronic wallet platform, wherein the second electronic wallet platform includes a backend server of the second electronic wallet, and the device includes:

[0033] a second receiving module, configured to receive a first account acquisition request sent by a first e-wallet platform, the first account acquisition request being generated by the first e-wallet platform when a remaining resource value in a first payment account is less than a required resource value for an order to be paid, the first e-wallet platform including a backend server for the first e-wallet, the first payment account being bound to the first e-wallet, and the first account acquisition request being used to request acquisition of a second payment account that is bound to the second e-wallet;

[0034] A first acquisition module, configured to acquire the second payment account in response to the first account acquisition request;

[0035] The second sending module is used to send the second payment account to the first electronic wallet platform, so that the first electronic wallet platform obtains a third payment account based on the second payment account, and sends the order to be paid and the third payment account to the payment platform via the merchant's backend system, so that the payment platform uses the remaining resources in the third payment account to pay for the order to be paid. The third payment account is a payment account in which the remaining resource value in the second payment account is greater than or equal to the required resource value.

[0036] In a seventh aspect, an embodiment of the present application provides a payment device, applied to a payment platform, the device comprising:

[0037] a third receiving module, configured to receive a second account acquisition request sent by the first e-wallet platform, the second account acquisition request being used to request a third payment account whose remaining resource value is greater than or equal to the required resource value of the order to be paid, in the second payment account; the second account acquisition request being generated by the first e-wallet platform when the remaining resource value in the first payment account is less than the required resource value of the order to be paid; the first e-wallet platform includes a backend server of the first e-wallet; the first payment account is bound to the first e-wallet; and the second payment account is a payment account bound to the second e-wallet;

[0038] a second obtaining module, configured to obtain, in response to the second account obtaining request, the remaining resource value of the second payment account from the resource management server to which the second payment account belongs;

[0039] a determination module, configured to determine the second payment account as a third payment account when the remaining resource value of the second payment account is greater than or equal to the required resource value;

[0040] A third sending module, configured to send the third payment account to the first electronic wallet platform;

[0041] The third receiving module is further configured to receive the order to be paid and the third payment account number sent by the first electronic wallet platform via the merchant's backend system;

[0042] A payment module is used to pay for the order to be paid using the remaining resources in the third payment account.

[0043] In an eighth aspect, an embodiment of the present application provides a payment device, applied to a second electronic wallet, the device comprising:

[0044] a fourth receiving module, configured to receive a first account acquisition request sent by a first e-wallet, the first account acquisition request being generated and sent to the first e-wallet by the first e-wallet platform when the remaining resource value in the first payment account is less than the required resource value of the order to be paid, the first payment account being bound to the first e-wallet, the first account acquisition request being used to request acquisition of a second payment account being bound to the second e-wallet, and the first e-wallet platform including a backend server of the first e-wallet;

[0045] a third acquisition module, configured to obtain the second payment account from a security module of a target electronic device in response to the first account acquisition request, where the target electronic device is the electronic device where the second electronic wallet is located;

[0046] The fourth sending module is used to send the second payment account to the first electronic wallet, so that the first electronic wallet sends the second payment account to the first electronic wallet platform, and enables the first electronic wallet platform to obtain a third payment account based on the second payment account, and send the pending payment order and the third payment account to the payment platform via the merchant's backend system, so that the payment platform uses the remaining resources in the third payment account to pay for the pending payment order. The third payment account is a payment account in which the remaining resource value in the second payment account is greater than or equal to the required resource value.

[0047] In a ninth aspect, an embodiment of the present application provides an electronic device, the device comprising: a processor and a memory storing computer program instructions;

[0048] When the processor executes the computer program instructions, the method in any possible implementation method of the first aspect, the second aspect, the third aspect, or the fourth aspect is implemented.

[0049] In a tenth aspect, an embodiment of the present application provides a payment system, including:

[0050] A first electronic wallet platform, configured to implement the payment method according to the first aspect;

[0051] A second electronic wallet platform, used to implement the payment method according to the second aspect;

[0052] A payment platform is used to execute the payment method as described in the third aspect.

[0053] In the eleventh aspect, an embodiment of the present application provides a computer-readable storage medium having computer program instructions stored thereon, which, when executed by a processor, implement a method in any one of the possible implementation methods of the first aspect, the second aspect, the third aspect, or the fourth aspect mentioned above.

[0054] In the twelfth aspect, an embodiment of the present application provides a computer program product. When the instructions in the computer program product are executed by the processor of an electronic device, the electronic device executes a method in any possible implementation method of the first aspect, the second aspect, the third aspect, or the fourth aspect mentioned above.

[0055] In an embodiment of the present application, when the remaining resource value in the first payment account that is bound to the first electronic wallet is less than the required resource value of the order to be paid, the first electronic wallet platform requests the second electronic wallet platform to obtain the second payment account that is bound to the second electronic wallet, thereby breaking away from the limitations of the electronic wallet and seeking a payment account externally. By requesting the payment platform to determine a third payment account whose remaining resource value is greater than or equal to the required resource value in the second payment account when the second payment account is fed back by the second electronic wallet platform, and by sending the order to be paid and the third payment account to the payment platform via the merchant's backend system when receiving the third payment account fed back by the payment platform, the payment platform can use the remaining resources in the third payment account to pay for the order to be paid, thereby achieving the goal of completing payment when the remaining resource value in the payment account that is bound to the electronic wallet is less than the required resource value of the order to be paid, thereby improving the user's payment experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0056] 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.

[0057] Figure 1 This is a flow chart of a payment method applied to a first electronic wallet platform provided in an embodiment of the present application;

[0058] Figure 2 This is a flow chart of a payment method applied to a second electronic wallet platform provided in an embodiment of the present application;

[0059] Figure 3 This is a flow chart of a payment method applied to a payment platform provided in an embodiment of the present application;

[0060] Figure 4 This is a flow chart of a payment method applied to a second electronic wallet provided in an embodiment of the present application;

[0061] Figure 5 This is a flow chart of a payment method applied to a payment system provided in an embodiment of the present application;

[0062] Figure 61 is a schematic diagram of the structure of a payment device applied to a first electronic wallet platform provided in an embodiment of the present application;

[0063] Figure 7 1 is a schematic diagram of the structure of a payment device applied to a second electronic wallet platform provided in an embodiment of the present application;

[0064] Figure 8 This is a schematic diagram of the structure of a payment device applied to a payment platform provided in an embodiment of the present application;

[0065] Figure 9 1 is a schematic diagram of the structure of a payment device applied to a second electronic wallet provided in an embodiment of the present application;

[0066] Figure 10 This is a structural diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0067] 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.

[0068] It should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, the elements defined by the phrase "comprising..." do not exclude the presence of other identical elements in the process, method, article, or device comprising the elements.

[0069] In addition, the acquisition, storage, use, and processing of information and data in the embodiments of the present application are authorized by users or relevant institutions and comply with relevant provisions of national laws and regulations.

[0070] As described in the background technology section, with the rapid development of mobile payments, more and more users are using e-wallets for online payments. To use e-wallets for online payments, it is often necessary to bind a payment account to the e-wallet so that payments can be made through the bound payment account. There may be one or more payment accounts bound to the e-wallet. If there is only one payment account bound to the e-wallet, and the remaining resource value in that payment account is less than the required resource value of the order to be paid, payment cannot be completed, affecting the user's payment experience. If there are multiple payment accounts bound to the e-wallet, and the remaining resource value in the first-priority payment account is less than the required resource value of the order to be paid, the other payment accounts will be automatically polled. If the remaining resource values ​​in multiple payment accounts are all less than the required resource value of the order to be paid, or if the sum of the remaining resource values ​​of multiple payment accounts is still less than the required resource value of the order to be paid, payment cannot be completed, affecting the user's payment experience.

[0071] In this case, in order to complete the payment, the user is often required to rebind other payment accounts with sufficient remaining resource value, or recharge resources to the bound payment account so that the remaining resource value in the payment account is greater than or equal to the required resource value of the order to be paid. The operation is cumbersome and the payment efficiency is low, which affects the user's payment experience.

[0072] Therefore, there is an urgent need for a payment method that can complete payment when the remaining resource value in the payment account bound to the electronic wallet is less than the required resource value of the order to be paid, without affecting the payment efficiency and improving the user's payment experience.

[0073] Thus, in order to solve the problems of the prior art, embodiments of the present application provide a payment method, apparatus, device, system, computer-readable storage medium, and computer program product. The payment method can be executed by a server and / or processor in a payment system.

[0074] The following is an introduction to the payment system provided in the embodiments of the present application.

[0075] The payment system provided in the embodiment of the present application may include a first e-wallet platform, a second e-wallet platform, a merchant's backend system, a payment platform, and a resource management server. Among them, the first e-wallet platform may include the backend server of the first e-wallet. The first e-wallet may be an e-wallet that is making payments. The first e-wallet and the first payment account may have a binding relationship. In addition, the second e-wallet platform may include the backend server of the second e-wallet. The second e-wallet and the second payment account may have a binding relationship. The second e-wallet and the first e-wallet may be two different e-wallets belonging to the same user. In addition, the payment platform can be used to interact with the resource management server to which the second payment account belongs, so as to obtain the remaining resource value of the second payment account from the resource management server, and to make payments for orders to be paid.

[0076] As an example, when the first e-wallet pays for an order to be paid, if the first payment account that is bound to the first e-wallet cannot complete the payment due to insufficient remaining resource value (that is, the remaining resource value is less than the required resource value of the order to be paid), the first e-wallet platform can send a first account acquisition request to the second e-wallet platform to obtain the second payment account that is bound to the second e-wallet from the second e-wallet platform.

[0077] The remaining resource value of the second payment account may be less than the required resource value of the order to be paid, or it may be greater than or equal to the required resource value of the order to be paid. Therefore, in order to determine whether the second payment account is available, after receiving the second payment account, the first electronic wallet platform can send a second account acquisition request to the payment platform to request the payment platform to determine a third payment account whose remaining resource value is greater than or equal to the required resource value in the second payment account. After receiving the second account acquisition request, the payment platform can interact with the resource management server to which the second payment account belongs to obtain the remaining resource value of the second payment account from the resource management server, and determine the third payment account based on the size relationship between the remaining resource value and the required resource value.

[0078] After receiving the third payment account, the first electronic wallet platform may send the order to be paid and the third payment account to the payment platform via the merchant's backend system, so that the payment platform uses the remaining resources in the third payment account to pay for the order to be paid.

[0079] Thus, through the embodiments of the present application, payment can be completed even when the remaining resource value in the first payment account bound to the first electronic wallet is less than the required resource value of the order to be paid. Furthermore, the payment process does not require the user to re-bind another payment account with sufficient remaining resource value or to top up resources into an already bound payment account, thus maintaining payment efficiency and improving the user's payment experience.

[0080] The following is an introduction to the payment method applied to the first electronic wallet platform provided in the embodiment of the present application.

[0081] Figure 1 The flow chart of a payment method applied to the first electronic wallet platform provided by the embodiment of the present application is shown. The payment method can be executed by the backend server of the first electronic wallet platform. Figure 1 As shown, the payment method provided in the embodiment of the present application includes the following steps:

[0082] S110: When the remaining resource value in the first payment account is less than the required resource value of the order to be paid, sending a first account acquisition request to the second e-wallet platform, the second e-wallet platform including a backend server of the second e-wallet, the first account acquisition request being used to request acquisition of a second payment account that is bound to the second e-wallet;

[0083] S120: Receive a second payment account number fed back by the second electronic wallet platform in response to the first account acquisition request;

[0084] S130: Send a second account acquisition request to the payment platform, where the second account acquisition request is used to request a third payment account whose remaining resource value is greater than or equal to the required resource value in the second payment account;

[0085] S140: Receive a third payment account number that is fed back by the payment platform in response to the second account acquisition request;

[0086] S150: Send the third payment account to the payment platform via the merchant's backend system, so that the payment platform uses the remaining resources in the third payment account to pay for the order to be paid.

[0087] In an embodiment of the present application, when the remaining resource value in the first payment account that is bound to the first electronic wallet is less than the required resource value of the order to be paid, the first electronic wallet platform requests the second electronic wallet platform to obtain the second payment account that is bound to the second electronic wallet, thereby breaking away from the limitations of the electronic wallet and seeking a payment account externally. By requesting the payment platform to determine a third payment account whose remaining resource value is greater than or equal to the required resource value in the second payment account when the second payment account is fed back by the second electronic wallet platform, and by sending the order to be paid and the third payment account to the payment platform via the merchant's backend system when receiving the third payment account fed back by the payment platform, the payment platform can use the remaining resources in the third payment account to pay for the order to be paid, thereby achieving the goal of completing payment when the remaining resource value in the payment account that is bound to the electronic wallet is less than the required resource value of the order to be paid, thereby improving the user's payment experience.

[0088] The specific implementation methods of the above steps are introduced below.

[0089] In some embodiments, in S110, the first electronic wallet can be an electronic wallet that comes with the electronic device, or a third-party electronic wallet, which is not limited here. The first payment account that is bound to the first electronic wallet can be the payment account of the first electronic wallet itself, or can be the card number of a payment card that is bound to the first electronic wallet. Among them, the payment card can be a physical card or a virtual card, which is not limited here. Payment cards can include, for example, bank cards, membership cards, transportation cards, etc. In addition, the required resource value of the order to be paid can be the amount to be paid, and the remaining resource value can be the balance. The resources in the embodiments of the present application can be currency, digital currency, points, red envelopes, etc.

[0090] As an example, when using a first e-wallet to make a payment, a user may first open the first e-wallet on an electronic device and then use the first e-wallet's primary scanning mode or scanned mode to make a graphic code payment for a merchant's pending order. The graphic code may include a QR code or a barcode. During the process of using the first e-wallet to make a graphic code payment for a merchant's pending order, the merchant's backend system may generate payment information for the pending order and send the payment information to the payment platform. The payment information may include the required resource value for the pending order. After receiving the payment information, the payment platform may determine the required resource value from the payment information and request the remaining resource value of the first payment account from the resource management platform to which the first payment account belongs. The remaining resource value is then compared with the required resource value. If the remaining resource value in the first payment account is less than the required resource value for the pending order, the payment platform may send a prompt message to the first e-wallet platform and the merchant's backend system, respectively, indicating that the remaining resource value in the first payment account is insufficient and payment cannot be completed.

[0091] It should be noted that there may be one or more first payment accounts bound to the first electronic wallet. If there is only one first payment account bound to the first electronic wallet, the payment platform may generate the above-mentioned prompt information when the remaining resource value in the first payment account is less than the required resource value of the order to be paid. If there are multiple first payment accounts bound to the first electronic wallet, the payment platform may generate the above-mentioned prompt information when the remaining resource values ​​in multiple first payment accounts are all less than the required resource value of the order to be paid, or when the sum of the remaining resource values ​​of multiple first payment accounts is still less than the required resource value of the order to be paid.

[0092] After receiving the above prompt information, the first e-wallet platform may send a first account acquisition request to the second e-wallet platform to request the second payment account that is bound to the second e-wallet. The second e-wallet may be an e-wallet that comes with the electronic device, or a third-party e-wallet, which is not limited here. The second payment account that is bound to the second e-wallet may be the payment account of the second e-wallet itself, or the card number of a payment card that is bound to the second e-wallet. The payment card may be a physical card or a virtual card, which is not limited here. Payment cards may include, for example, bank cards, membership cards, transportation cards, etc. In addition, the second e-wallet and the first e-wallet may be installed in the same electronic device, and the second e-wallet may be different from the first e-wallet. The second e-wallet platform may be different from the first e-wallet platform.

[0093] In some embodiments, in S120, after receiving the first account acquisition request, the second electronic wallet platform may respond to the first account acquisition request and obtain a second payment account that is bound to the second electronic wallet. There may be one or more second payment accounts, which is not limited here.

[0094] To ensure the security of the second payment account, in some embodiments, the second payment account can be stored in a security module of the target electronic device. The target electronic device can be an electronic device equipped with the second electronic wallet and the first electronic wallet. In addition, the security module can include, for example, a secure element (SE) and a trusted execution environment (TEE) of the target electronic device.

[0095] As an example, after receiving the first account acquisition request, the second electronic wallet platform can obtain the second payment account from the security module of the target electronic device in response to the first account acquisition request and send the second payment account to the first electronic wallet platform.

[0096] Based on this, in order to increase the speed of information acquisition and conserve communication resources, in some embodiments, if the remaining resource value in the first payment account is less than the required resource value of the order to be paid, the first e-wallet platform may first send a first account acquisition request to the first e-wallet, and then the first e-wallet may send the first account acquisition request to the second e-wallet. After receiving the first account acquisition request, the second e-wallet may respond to the first account acquisition request, obtain the second payment account from the security module of the target electronic device, and send the second payment account to the first e-wallet. The first e-wallet may return the received second payment account to the first e-wallet platform.

[0097] The embodiment of the present application obtains the second payment account through local calls between the first electronic wallet and the second electronic wallet without going through the background server, which can improve the speed of information acquisition and save communication resources.

[0098] To further ensure the security of the second payment account, in some embodiments, the second payment account can be stored and transmitted in encrypted form. If the second payment account is a bank card number, the encrypted information of the second payment account can be the bank card token information.

[0099] As an example, after receiving the first account acquisition request, the second e-wallet platform can respond to the first account acquisition request, obtain the encrypted information of the second payment account from the security module of the target electronic device, and send the encrypted information of the second payment account to the first e-wallet platform.

[0100] Based on this, in order to increase the speed of information acquisition and conserve communication resources, in some embodiments, when the remaining resource value in the first payment account is less than the required resource value of the order to be paid, the first e-wallet platform may first send a first account acquisition request to the first e-wallet, and then the first e-wallet may send the first account acquisition request to the second e-wallet. After receiving the first account acquisition request, the second e-wallet may respond to the first account acquisition request, obtain the encrypted information of the second payment account from the security module of the target electronic device, and send the encrypted information of the second payment account to the first e-wallet. The first e-wallet may return the received encrypted information of the second payment account to the first e-wallet platform.

[0101] The embodiment of the present application obtains the encrypted information of the second payment account through local calls between the first electronic wallet and the second electronic wallet without going through the background server, which can improve the information acquisition speed and save communication resources.

[0102] In some embodiments, in S130, the second payment account acquisition request may include the second payment account. Furthermore, the payment platform may store a correspondence between the second payment account and the resource management server to which the second payment account belongs. The resource management server may store the remaining resource value of the second payment account. Therefore, the payment platform can obtain the remaining resource value of the second payment account from the resource management server to which the second payment account belongs. If the second payment account is a payment card number, the resource management server may be the backend server of the card issuer to which the payment card belongs.

[0103] Furthermore, as described above, the payment platform has received the payment information for the pending order and can determine the required resource value from the payment information. Therefore, the payment platform can compare the remaining resource value with the required resource value and, based on this relationship, determine a third payment account within the second payment account whose remaining resource value is greater than or equal to the required resource value.

[0104] Based on this, as an example, after receiving the second payment account, the first electronic platform can send a second account acquisition request to the payment platform, requesting the payment platform to determine a third payment account whose remaining resource value is greater than or equal to the required resource value in the second payment account. After receiving the second account acquisition request, the payment platform can first determine the second payment account in the second account acquisition request, then determine the resource management server to which the second payment account belongs based on the correspondence between the second payment account and the resource management server to which the second payment account belongs, and send a remaining resource query request to the resource management server to query the remaining resource value of the second payment account. Afterwards, the payment platform can compare the remaining resource value with the required resource value and, if the remaining resource value is greater than or equal to the required resource value, determine the second payment account as the third payment account.

[0105] If there are multiple second payment accounts, the payment platform can repeat the above steps to determine whether each second payment account is a third payment account. In the case of multiple second payment accounts, the third payment account may be one or more.

[0106] In addition, if the first electronic wallet platform receives the ciphertext information of the second payment account, it can send the ciphertext information of the second payment account to the payment platform. The payment platform can store the correspondence between the ciphertext information and the plaintext information of the payment account. Therefore, when the payment platform receives the ciphertext information of the second payment account, it can parse the ciphertext information to obtain the plaintext information of the second payment account, and then determine the resource management server to which the second payment account belongs based on the plaintext information of the second payment account, and send a remaining resource query request to the resource management server to query the remaining resource value of the second payment account, and compare the size relationship between the remaining resource value and the required resource value. If the remaining resource value is greater than or equal to the required resource value, the second payment account is determined as the third payment account and the plaintext information of the third payment account is obtained.

[0107] In some embodiments, in S140, the transmission form of the third payment account during the information transmission process can be plain text information or encrypted information, which is not limited here.

[0108] As an example, after determining the plain text information of the third payment account, the payment platform may send the plain text information of the third payment account to the first electronic wallet platform.

[0109] In order to ensure the security of information transmission, as another example, after determining the plaintext information of the third payment account, the payment platform can determine the ciphertext information of the third payment account based on the correspondence between the ciphertext information and the plaintext information of the payment account, and send the ciphertext information of the third payment account to the first e-wallet platform.

[0110] As another example, after determining the plaintext information and ciphertext information of the third payment account, the payment platform may send the plaintext information and ciphertext information of the third payment account to the first electronic wallet platform.

[0111] In addition, after receiving the third payment account, the first electronic wallet platform can display the plain text information and / or cipher text information of the third payment account on the interactive interface of the first electronic wallet to prompt the user that there is an available payment account.

[0112] In some embodiments, in S150, if there is only one third payment account, then after receiving the third payment account, the first electronic wallet may send the third payment account to the merchant's backend server. After receiving the third payment account, the merchant's backend server may send the pending payment order and the third payment account to the payment platform, so that the payment platform uses the remaining resources in the third payment account to pay for the pending payment order.

[0113] If there are multiple third payment accounts, multiple third payment accounts can be displayed on the interactive interface of the first electronic wallet, and the user's first selection input of selecting a target payment account from the multiple third payment accounts can be received. In response to the first selection input, the target payment account can be sent to the merchant's backend system, and the merchant's backend system can send the order to be paid and the target payment account to the payment platform, so that the payment platform can use the remaining resources in the target payment account to pay for the order to be paid.

[0114] Based on this, in order to ensure payment security, in some embodiments, before the above S150, the following steps may also be included:

[0115] Sending an authorization request to the second electronic wallet platform for authorizing the first electronic wallet to use the third payment account for payment;

[0116] Receive authorization information fed back by the second electronic wallet platform in response to the authorization request.

[0117] Based on this, the above S150 may specifically include:

[0118] When the authorization information indicates that the authorization is passed, the order to be paid and the third-party payment account are sent to the payment platform via the merchant's backend system.

[0119] Here, after receiving the third payment account, the first e-wallet platform may send an authorization request to the second e-wallet platform to authorize the first e-wallet to use the third payment account for payment. The authorization request may specifically be an authorization use request. After receiving the authorization request, the second e-wallet platform may display a first authorization prompt message for authorizing the third payment account on the interactive interface of the second e-wallet. The user may confirm and input the first authorization prompt message on the interactive interface. If the second e-wallet platform receives the user's confirmation input, it may generate authorization information indicating that the authorization is passed and send the authorization information to the first e-wallet platform. The authorization information may include or exclude the third payment account, which is not limited here. If the authorization information includes the third payment account, the third payment account may be transmitted in the form of encrypted information during the information transmission process to ensure the security of information transmission and thus the security of payment.

[0120] In this way, when the authorization is passed, that is, the first electronic wallet is authorized to use the third payment account for payment, the order to be paid and the third payment account are sent to the payment platform through the merchant's backend system, so that the payment platform uses the remaining resources in the third payment account to pay for the order to be paid, thereby ensuring payment security.

[0121] Based on this, in order to ensure payment security, in some embodiments, when there are multiple third payment accounts, the authorization request sent to the second electronic wallet platform to authorize the first electronic wallet to use the third payment account for payment may specifically include:

[0122] Displaying multiple third payment accounts on the interactive interface of the first electronic wallet;

[0123] receiving a first selection input of a user selecting a target payment account from a plurality of third payment accounts;

[0124] In response to the first selection input, sending an authorization request to the second electronic wallet platform for authorizing the first electronic wallet to use the target payment account for payment;

[0125] If the authorization information indicates that the authorization is passed, the payment order and the third-party payment account are sent to the payment platform, including:

[0126] When the authorization information indicates that the authorization is passed, the order to be paid and the target payment account are sent to the payment platform.

[0127] Here, the third payment account information displayed in the interactive interface may be either plaintext or encrypted, without limitation. The target payment account may be any one of multiple third payment accounts. Furthermore, the first selected input may be a user click input, a user swipe input, a user voice input, or a user command input via another device connected to the electronic device. The other device may include at least one of a remote control, a mouse, a keyboard, or other devices with typing functionality.

[0128] In addition, the interactive interface of the first electronic wallet may also display the remaining resource values ​​corresponding to multiple third payment accounts. The user can select a target payment account based on the remaining resource values. The larger the remaining resource value of a third payment account, the more likely the user will select the third payment account as the target payment account.

[0129] As an example, after the user selects the target payment account, the first e-wallet platform may send an authorization request to the second e-wallet platform to authorize the first e-wallet to use the target payment account for payment. After receiving the authorization request, the second e-wallet platform may display a second authorization prompt message for authorizing the target payment account on the interactive interface of the second e-wallet. The user may confirm and input the second authorization prompt message on the interactive interface. If the second e-wallet platform receives the user's confirmation input, it may generate authorization information indicating that the authorization is passed and send the authorization information to the first e-wallet platform. The authorization information may or may not include the target payment account, which is not limited here. If the authorization information includes the target payment account, the target payment account may be transmitted in the form of encrypted information during the information transmission process to ensure the security of information transmission and thus the security of payment.

[0130] In this way, when there are multiple third payment accounts, the user confirms the target payment account in the first electronic wallet, and when the target payment account is authorized, the merchant's backend system sends the order to be paid and the third payment account to the payment platform, so that the payment platform uses the remaining resources in the target payment account to pay for the order to be paid, thereby ensuring payment security.

[0131] In addition, to ensure payment security, in some embodiments, when there are multiple third payment accounts, the first electronic wallet platform can send authorization requests corresponding to the multiple third payment accounts to the second electronic wallet platform. After receiving the authorization request, the second electronic platform can respond to the authorization request by displaying the multiple third payment accounts in the interactive interface of the second electronic wallet and receiving the user's second selection input to select the target payment account from the multiple third payment accounts. The second selection input can be a user's click input, a user's sliding input, a user's voice input, or a command input implemented by the user with the help of other devices connected to the electronic device. The other device can include at least one of a remote control, a mouse, a keyboard, and other devices with a typing function.

[0132] In response to the second selection input, the second e-wallet platform may display a second authorization prompt on the second e-wallet's interactive interface for authorizing the target payment account and receive a user confirmation input for the second authorization prompt. After receiving the confirmation input, the second e-wallet platform may generate authorization information indicating that the target payment account has been authorized and send the authorization information to the first e-wallet platform. The authorization information may include the target payment account. The target payment account may be transmitted in encrypted form during the information transmission process to ensure information transmission security, thereby ensuring payment security.

[0133] Based on this, the above S150 may specifically include:

[0134] The merchant's backend system sends the payment order and target payment account to the payment platform.

[0135] In this way, when there are multiple third payment accounts, the user confirms the target payment account on the interactive interface of the second e-wallet, and when the target payment account is authorized, the payment order and the third payment account are sent to the payment platform through the first e-wallet platform and the merchant's backend system, so that the payment platform uses the remaining resources in the target payment account to pay for the payment order, thereby ensuring payment security.

[0136] In addition, the authorization request may also be an authorization binding request. Based on this, in order to ensure payment success and further improve payment efficiency, in some embodiments, before the above S150, the following steps may also be included:

[0137] When the authorization information indicates that the authorization is passed, a binding relationship between the first electronic wallet and the third payment account is established.

[0138] Here, the process by which the second e-wallet platform authorizes the binding authorization request and the use authorization request can be the same and will not be described in detail here. If the second e-wallet platform authorizes the binding of the third payment account, the first e-wallet platform can establish a binding relationship between the first e-wallet and the third payment account.

[0139] The embodiment of the present application establishes a binding relationship between the first electronic wallet and the third payment account, so that the first electronic wallet can continue to use the third payment account for payment in the future without having to obtain the third payment account again through the second electronic wallet platform and the payment platform, thereby further improving payment efficiency.

[0140] Based on this, in order to improve binding efficiency, in some embodiments, establishing the binding relationship between the first electronic wallet and the third payment account may specifically include:

[0141] Displaying a verification information input box on the interactive interface of the first electronic wallet, the verification information input box is used for the user to enter verification information for verifying the third payment account;

[0142] In response to the user's input in the verification information input box, determining verification information for verifying the third payment account;

[0143] When the verification information is verified successfully, a binding relationship between the first electronic wallet and the third payment account is established.

[0144] Here, the verification information may include a mobile phone number verification code, a password of a third-party payment account, etc.

[0145] As an example, after receiving authorization information indicating successful binding authorization, the first e-wallet platform may display a verification information input box on the first e-wallet's interactive interface, allowing the user to enter verification information for the third payment account in the verification information input box. Furthermore, the first e-wallet's interactive interface may or may not display the third payment account number, without limitation. If the third payment account number is displayed, it may be displayed in plaintext or in encrypted form.

[0146] After receiving the user's input in the verification information input box, the first electronic wallet platform can determine the verification information for verifying the third payment account in response to the user input and verify the verification information. If the verification information is verified, the binding relationship between the first electronic wallet and the third payment account can be established.

[0147] In this way, from the user's perspective, by having the user input verification information for verifying the third payment account, a binding relationship between the first electronic wallet and the third payment account can be established, which can simplify user operations and improve binding efficiency.

[0148] In addition, when there are multiple third payment accounts, the process of establishing a binding relationship between the first electronic wallet and the target payment account can be the same as the process of establishing a binding relationship between the first electronic wallet and the third payment account, and will not be repeated here.

[0149] The following is an introduction to the payment method applied to the second electronic wallet platform provided in the embodiment of the present application.

[0150] Figure 2 The flow chart of a payment method applied to the second electronic wallet platform provided by the embodiment of the present application is shown. The payment method can be executed by the backend server of the second electronic wallet platform. Figure 2 As shown, the payment method provided in the embodiment of the present application includes steps S210-S230.

[0151] S210, receiving a first account acquisition request sent by the first electronic wallet platform. The first account acquisition request is generated by the first electronic wallet platform when the remaining resource value in the first payment account is less than the required resource value of the order to be paid. The first electronic wallet platform includes a backend server of the first electronic wallet. The first payment account is bound to the first electronic wallet. The first account acquisition request is used to request to obtain a second payment account that is bound to the second electronic wallet.

[0152] S220: Responding to the first account acquisition request, acquiring a second payment account.

[0153] As an example, the second payment account associated with the second e-wallet can be stored on the second e-wallet platform or on the target electronic device where the second e-wallet is located, without limitation. That is, the second e-wallet platform can obtain the second payment account from itself or from the target electronic device.

[0154] Based on this, in order to ensure the security of the second payment account, in some embodiments, the second payment account can be stored in a security module of the target electronic device. The security module can include, for example, a secure element (SE) and a trusted execution environment (TEE) of the target electronic device.

[0155] In this way, the second electronic wallet platform can obtain the second payment account from the security module of the target electronic device in response to the first account acquisition request.

[0156] To further ensure the security of the second payment account, in some embodiments, the second payment account can be stored and transmitted in encrypted form. Specifically, the encrypted information of the second payment account can be stored in the security module of the target electronic device. When the second payment account is a bank card number, the encrypted information of the second payment account can be the bank card token information.

[0157] Based on this, the above-mentioned obtaining of the second payment account may specifically include:

[0158] Obtain the encrypted information of the second payment account from the security module.

[0159] S230. Send the second payment account to the first electronic wallet platform so that the first electronic wallet platform obtains the third payment account based on the second payment account, and send the pending payment order and the third payment account to the payment platform via the merchant's backend system so that the payment platform uses the remaining resources in the third payment account to pay for the pending payment order. The third payment account is a payment account in which the remaining resource value in the second payment account is greater than or equal to the required resource value.

[0160] Based on this, in order to ensure payment security, in some embodiments, after the above S230, the following steps may be further included:

[0161] Receiving an authorization request sent by the first electronic wallet platform for authorizing the first electronic wallet platform to use the third payment account for payment;

[0162] In response to the authorization request, displaying first authorization prompt information for authorizing the third payment account on the interactive interface of the second electronic wallet;

[0163] Receiving a confirmation input from the user regarding the first authorization prompt information;

[0164] generating authorization information in response to the confirmation input;

[0165] Send authorization information to the first electronic wallet platform.

[0166] Here, the authorization request may include an authorization request for use and an authorization request for binding. Furthermore, in response to the user's confirmation input of the first authorization prompt, authorization information indicating that the authorization was approved may be generated. The authorization information may or may not include a third payment account number, without limitation. If the authorization information includes a third payment account number, the third payment account number may be transmitted in encrypted form during the information transmission process to ensure information transmission security, thereby ensuring payment security.

[0167] In this way, the third payment account is authorized through the second e-wallet platform, and when the authorization is passed, that is, the first e-wallet is authorized to use the third payment account for payment, the order to be paid and the third payment account are sent to the payment platform through the first e-wallet platform via the merchant's backend system, so that the payment platform uses the remaining resources in the third payment account to pay for the order to be paid, thereby ensuring payment security.

[0168] As mentioned above, there may be multiple third payment accounts. Based on this, in order to ensure payment security, in some embodiments, before receiving the user's confirmation input of the first authorization prompt information, the following steps may also be included:

[0169] In response to the authorization request, displaying multiple third payment accounts in the interactive interface of the second electronic wallet;

[0170] receiving a second selection input of the user selecting a target payment account from a plurality of third payment accounts;

[0171] In response to the second selection input, second authorization prompt information for authorizing the target payment account is displayed.

[0172] Based on this, the above-mentioned receiving the user's confirmation input for the first authorization prompt information may specifically include:

[0173] Receive the user's confirmation input for the second authorization prompt information.

[0174] Here, the second selected input can be a user's click input, a user's sliding input, a user's voice input, or a user's command input implemented by other devices connected to the electronic device. The other device can include at least one of a remote control, a mouse, a keyboard, and other devices with typing functions. In addition, after receiving the user's confirmation input for the second authorization prompt information, the second e-wallet platform can generate authorization information indicating that the target payment account has been authorized, and send the authorization information to the first e-wallet platform. The authorization information may include the target payment account. The target payment account can be transmitted in encrypted form during the information transmission process to ensure the security of information transmission and, thereby, the security of payment.

[0175] In this way, when there are multiple third payment accounts, the user confirms the target payment account on the interactive interface of the second e-wallet and authorizes the third payment account through the second e-wallet platform. When the authorization is passed, that is, the first e-wallet is authorized to use the target payment account for payment, the payment order and the target payment account are sent to the payment platform through the first e-wallet platform via the merchant's backend system, so that the payment platform uses the remaining resources in the target payment account to pay for the payment order, thereby ensuring payment security.

[0176] In addition, other steps of the method in the embodiment of the present application can be found in the above Figure 1 The description of the embodiments shown will not be repeated here.

[0177] In an embodiment of the present application, when the remaining resource value in the first payment account that is bound to the first e-wallet is less than the required resource value of the order to be paid, the first e-wallet platform requests the second e-wallet platform to obtain the second payment account that is bound to the second e-wallet, thereby breaking away from the limitations of the current e-wallet and seeking a payment account externally. When the first e-wallet platform obtains the second payment account fed back by the second e-wallet platform, the payment platform is requested to determine a third payment account whose remaining resource value is greater than or equal to the required resource value in the second payment account, and when the first e-wallet platform receives the third payment account fed back by the payment platform, the merchant's backend system sends the order to be paid and the third payment account to the payment platform, so that the payment platform can use the remaining resources in the third payment account to pay for the order to be paid, thereby achieving the goal of completing payment when the remaining resource value in the payment account that is bound to the e-wallet is less than the required resource value of the order to be paid, thereby improving the user's payment experience.

[0178] The following is an introduction to the payment method applied to the payment platform provided in the embodiment of the present application.

[0179] Figure 3 The flow chart of a payment method applied to a payment platform provided in an embodiment of the present application is shown. The payment method can be executed by the backend server of the payment platform. Figure 3 As shown, the payment method provided in the embodiment of the present application includes steps S310-S360.

[0180] S310, receiving a second account acquisition request sent by the first electronic wallet platform, the second account acquisition request is used to request a third payment account whose remaining resource value is greater than or equal to the required resource value of the order to be paid in the second payment account, the second account acquisition request is generated by the first electronic wallet platform when the remaining resource value in the first payment account is less than the required resource value of the order to be paid, the first electronic wallet platform includes the backend server of the first electronic wallet, the first payment account is bound to the first electronic wallet, and the second payment account is a payment account bound to the second electronic wallet.

[0181] S320 : In response to the second account acquisition request, obtain the remaining resource value of the second payment account from the resource management server to which the second payment account belongs.

[0182] Based on this, in order to ensure the accuracy of the remaining resource value of the second payment account, in some embodiments, the above S320 may specifically include:

[0183] Sending a remaining resource query request to the resource management server to which the second payment account belongs;

[0184] The remaining resource value fed back by the resource management server in response to the remaining resource query request is received.

[0185] In addition, to ensure payment security, in some embodiments, the second payment account is transmitted in encrypted form during the information transmission process. Based on this, before sending the remaining resource query request to the resource management server to which the second payment account belongs, the method may further include:

[0186] Convert the encrypted information of the second payment account into plain text information;

[0187] The resource management server to which the second payment account belongs is determined according to the plaintext information of the second payment account.

[0188] S330: When the remaining resource value of the second payment account is greater than or equal to the required resource value, the second payment account is determined as the third payment account.

[0189] S340: Send the third payment account to the first electronic wallet platform.

[0190] S350: Receive the order to be paid and the third payment account sent by the first electronic wallet platform via the merchant's backend system.

[0191] S360: Use the remaining resources in the third payment account to pay for the order to be paid.

[0192] As mentioned above, there may be multiple third payment accounts. Based on this, in order to further improve the user's payment experience, in some embodiments, when there are multiple third payment accounts, the above S350 may specifically include:

[0193] The first electronic wallet platform receives the order to be paid and the target payment account sent via the merchant's backend system. The target payment account is a payment account selected by the user from multiple third payment accounts for paying the order to be paid.

[0194] Based on this, the above S360 may specifically include:

[0195] Use the remaining resources in the third-party payment account to pay for pending orders, including:

[0196] Use the remaining resources in the target payment account to pay for the pending order.

[0197] As described above, the user can select the target payment account on the interactive interface of the first e-wallet or on the interactive interface of the second e-wallet. In addition, as described above, the user can select the target payment account based on the remaining resource values ​​corresponding to multiple third payment accounts.

[0198] Therefore, when there are multiple third payment accounts, the user can select a target payment account from the multiple third payment accounts, which can further improve the user's payment experience.

[0199] In addition, other steps of the method in the embodiment of the present application can be found in the above Figure 1 The description of the embodiments shown will not be repeated here.

[0200] In an embodiment of the present application, when the remaining resource value in the first payment account that is bound to the first e-wallet is less than the required resource value of the order to be paid, the first e-wallet platform requests the second e-wallet platform to obtain the second payment account that is bound to the second e-wallet, thereby breaking away from the limitations of the current e-wallet and seeking a payment account externally. When the first e-wallet platform obtains the second payment account fed back by the second e-wallet platform, the payment platform is requested to determine a third payment account whose remaining resource value is greater than or equal to the required resource value in the second payment account, and when the first e-wallet platform receives the third payment account fed back by the payment platform, the merchant's backend system sends the order to be paid and the third payment account to the payment platform, so that the payment platform can use the remaining resources in the third payment account to pay for the order to be paid, thereby achieving the goal of completing payment when the remaining resource value in the payment account that is bound to the e-wallet is less than the required resource value of the order to be paid, thereby improving the user's payment experience.

[0201] Figure 4 The flow chart of a payment method applied to a second electronic wallet provided in an embodiment of the present application is shown. The payment method can be executed by a processor corresponding to the second electronic wallet in the target electronic device. Figure 4 As shown, the payment method provided in the embodiment of the present application includes steps S410-S430.

[0202] S410: Receive a first account acquisition request sent by the first electronic wallet. The first account acquisition request is generated by the first electronic wallet platform and sent to the first electronic wallet when the remaining resource value in the first payment account is less than the required resource value of the order to be paid. The first payment account is bound to the first electronic wallet. The first account acquisition request is used to request to obtain a second payment account that is bound to the second electronic wallet. The first electronic wallet platform includes a backend server of the first electronic wallet.

[0203] S420: In response to the first account acquisition request, obtain a second payment account from a security module of a target electronic device, where the target electronic device is an electronic device where the second electronic wallet is located;

[0204] S430. Send the second payment account to the first electronic wallet so that the first electronic wallet sends the second payment account to the first electronic wallet platform, and enables the first electronic wallet platform to obtain a third payment account based on the second payment account, and send the pending payment order and the third payment account to the payment platform via the merchant's backend system so that the payment platform uses the remaining resources in the third payment account to pay for the pending payment order. The third payment account is a payment account in which the remaining resource value in the second payment account is greater than or equal to the required resource value.

[0205] The steps of the method in the embodiment of this application can be seen above Figure 1 The description of the embodiments shown will not be repeated here.

[0206] Through the embodiments of the present application, even when the remaining resource value in the payment account bound to the e-wallet is less than the required resource value of the order to be paid, payment can still be completed, thereby improving the user's payment experience. In addition, obtaining the second payment account through a local call between the first e-wallet and the second e-wallet, without going through the backend server, can improve information acquisition speed and save communication resources.

[0207] In order to better describe the entire solution, some specific examples are given based on the above embodiments.

[0208] For example, Figure 5 As shown, the payment method provided in the embodiment of the present application for the payment system may include the following steps:

[0209] S51. When a first electronic wallet uses a first payment account bound to the first electronic wallet to pay for an order to be paid, and the payment fails because the remaining resource value in the first payment account is less than the required resource value of the order to be paid, a first account acquisition request is sent to a second electronic wallet platform via the first electronic wallet platform.

[0210] S52. The second electronic wallet platform obtains the encrypted information of the second payment account from the security module of the target electronic device in response to the first account acquisition request, and feeds the encrypted information of the second payment account back to the first electronic wallet platform.

[0211] S53: The first electronic wallet platform sends a second account acquisition request carrying encrypted information of the second payment account to the payment platform;

[0212] S54. In response to the second account acquisition request, the payment platform parses the ciphertext information of the second payment account to obtain plaintext information, determines the resource management platform to which the second payment account belongs based on the plaintext information of the second payment account, and obtains the remaining resource value of the second payment account from the resource management platform to which the second payment account belongs.

[0213] S55. The payment platform determines a third payment account whose remaining resource value is greater than or equal to the required resource value in the second payment account based on the relationship between the remaining resource value and the required resource value of the order to be paid, and feeds the third payment account back to the first electronic wallet platform.

[0214] S56. The first electronic wallet platform sends an authorization request to the second electronic wallet platform for authorizing the first electronic wallet to use the third payment account for payment;

[0215] S57. The second electronic wallet platform sends a first authorization prompt message to the user in response to the authorization request, and generates authorization information indicating that the authorization is approved in response to the user's confirmation input of the first authorization prompt message, and sends the authorization information to the first electronic wallet platform.

[0216] S58. The first electronic wallet platform sends the third payment account number to the merchant's backend system in response to the authorization information.

[0217] S59. The merchant's backend system sends the third-party payment account and the order to be paid to the payment platform;

[0218] S510: The payment platform uses the remaining resources in the third payment account to pay for the order to be paid.

[0219] Through the embodiments of the present application, it is possible to complete payment when the remaining resource value in the payment account bound to the electronic wallet is less than the required resource value of the order to be paid, thereby improving the user's payment experience.

[0220] Based on the payment method provided in the above embodiment for a first e-wallet platform, this application also provides a specific implementation of a payment device for the first e-wallet platform. The first e-wallet includes a backend server for the first e-wallet, and the first e-wallet is bound to a first payment account. See the following embodiments.

[0221] like Figure 6 As shown, the payment device 600 provided in this embodiment of the application includes the following modules:

[0222] A first sending module 610 is configured to send a first account acquisition request to a second e-wallet platform when the remaining resource value in the first payment account is less than the required resource value of the order to be paid. The second e-wallet platform includes a backend server of the second e-wallet. The first account acquisition request is used to request a second payment account that is bound to the second e-wallet.

[0223] The first receiving module 620 is configured to receive a second payment account number fed back by the second electronic wallet platform in response to the first account acquisition request;

[0224] The first sending module 610 is further configured to send a second account acquisition request to the payment platform, where the second account acquisition request is used to request a third payment account whose remaining resource value is greater than or equal to the required resource value in the second payment account;

[0225] The first receiving module 620 is further configured to receive a third payment account number fed back by the payment platform in response to the second account number acquisition request;

[0226] The first sending module 610 is further configured to send the order to be paid and the third payment account to the payment platform via the merchant's backend system, so that the payment platform uses the remaining resources in the third payment account to pay for the order to be paid.

[0227] The payment device 600 is described in detail below.

[0228] In some embodiments, the first sending module 610 is further configured to send an authorization request to the second electronic wallet platform for authorizing the first electronic wallet to use the third payment account for payment before sending the order to be paid and the third payment account to the payment platform via the merchant's backend system;

[0229] The first receiving module 620 is further configured to receive authorization information fed back by the second electronic wallet platform in response to the authorization request.

[0230] Based on this, the first sending module 610 may specifically include:

[0231] The first sending submodule is configured to send the order to be paid and the third payment account to the payment platform via the merchant's backend system when the authorization information indicates that the authorization is passed.

[0232] In some embodiments, the payment device 600 may further include:

[0233] The binding module is used to establish a binding relationship between the first electronic wallet and the third payment account before sending the order to be paid and the third payment account to the payment platform via the merchant's backend system, if the authorization information indicates that the authorization is passed.

[0234] In some embodiments, the binding module may specifically include:

[0235] A first display submodule, configured to display a verification information input box on the interactive interface of the first electronic wallet, wherein the verification information input box is used for the user to input verification information for verifying the third payment account;

[0236] a first determining submodule, configured to determine verification information for verifying the third payment account in response to user input in the verification information input box;

[0237] The binding submodule is used to establish a binding relationship between the first electronic wallet and the third payment account when the verification information is verified.

[0238] In some embodiments, there are multiple third payment accounts, and the authorization information includes a target payment account, which is any one of the multiple third payment accounts.

[0239] Based on this, the first sending submodule is further used to send the order to be paid and the target payment account to the payment platform via the merchant's backend system.

[0240] In some embodiments, there are multiple third payment accounts. Based on this, the first sending module 610 may specifically include:

[0241] The display submodule is further configured to display multiple third payment accounts on the interactive interface of the first electronic wallet;

[0242] A first receiving submodule, configured to receive a first selection input from a user selecting a target payment account from a plurality of third payment accounts;

[0243] The first sending submodule is further configured to send, in response to the first selection input, an authorization request to the second electronic wallet platform for authorizing the first electronic wallet to use the target payment account for payment.

[0244] Based on this, the first sending submodule can be specifically used to: when the authorization information indicates that the authorization is passed, send the order to be paid and the target payment account to the payment platform via the merchant's backend system.

[0245] In some embodiments, the second payment account and / or the third payment account are transmitted in the form of encrypted information during the information transmission process.

[0246] In an embodiment of the present application, when the remaining resource value in the first payment account that is bound to the first electronic wallet is less than the required resource value of the order to be paid, the first electronic wallet platform requests the second electronic wallet platform to obtain the second payment account that is bound to the second electronic wallet, thereby breaking away from the limitations of the electronic wallet and seeking a payment account externally. By requesting the payment platform to determine a third payment account whose remaining resource value is greater than or equal to the required resource value in the second payment account when the second payment account is fed back by the second electronic wallet platform, and by sending the order to be paid and the third payment account to the payment platform via the merchant's backend system when receiving the third payment account fed back by the payment platform, the payment platform can use the remaining resources in the third payment account to pay for the order to be paid, thereby achieving the goal of completing payment when the remaining resource value in the payment account that is bound to the electronic wallet is less than the required resource value of the order to be paid, thereby improving the user's payment experience.

[0247] Based on the payment method for the second e-wallet platform provided in the above embodiment, this application also provides a specific implementation of a payment device for the second e-wallet platform. The second e-wallet includes a backend server for the second e-wallet. See the following embodiments.

[0248] like Figure 7 As shown, the payment device 700 provided in this embodiment of the application includes the following modules:

[0249] A second receiving module 710 is configured to receive a first account acquisition request sent by a first e-wallet platform. The first account acquisition request is generated by the first e-wallet platform when the remaining resource value in the first payment account is less than the required resource value of the order to be paid. The first e-wallet platform includes a backend server for the first e-wallet. The first payment account is bound to the first e-wallet. The first account acquisition request is used to request the acquisition of a second payment account that is bound to the second e-wallet.

[0250] A first acquisition module 720 is configured to acquire a second payment account in response to the first account acquisition request;

[0251] The second sending module 730 is used to send the second payment account to the first electronic wallet platform, so that the first electronic wallet platform obtains the third payment account based on the second payment account, and sends the pending payment order and the third payment account to the payment platform via the merchant's backend system, so that the payment platform uses the remaining resources in the third payment account to pay for the pending payment order. The third payment account is a payment account in which the remaining resource value in the second payment account is greater than or equal to the required resource value.

[0252] The payment device 700 is described in detail below.

[0253] In some embodiments, the second receiving module 710 is further configured to, after sending the second payment account to the first electronic wallet platform, receive an authorization request sent by the first electronic wallet platform for authorizing the first electronic wallet platform to use the third payment account for payment;

[0254] The payment device 700 may further include:

[0255] A display module, configured to display, on the interactive interface of the second electronic wallet, first authorization prompt information for authorizing the third payment account in response to the authorization request;

[0256] The second receiving module 710 is further configured to receive a user's confirmation input for the first authorization prompt information;

[0257] a generating module for generating authorization information in response to the confirmation input;

[0258] The second sending module 730 is further configured to send authorization information to the first electronic wallet platform.

[0259] In some embodiments, there are multiple third payment accounts. Based on this, the display module is further configured to display the multiple third payment accounts in the interactive interface of the second electronic wallet in response to the authorization request before receiving the user's confirmation input of the first authorization prompt information;

[0260] The second receiving module 710 is further configured to receive a second selection input from a user selecting a target payment account from a plurality of third payment accounts;

[0261] The display module is further configured to display second authorization prompt information for authorizing the target payment account in response to the second selection input.

[0262] Based on this, the second receiving module 710 may specifically include:

[0263] The second receiving submodule is configured to receive a user's confirmation input for the second authorization prompt information.

[0264] In some embodiments, the authorization information includes a target payment account number.

[0265] In some embodiments, the second payment account is transmitted in the form of encrypted information during the information transmission process, and the encrypted information of the second payment account is stored in a security module of the target electronic device, which is the electronic device where the second electronic wallet is located.

[0266] Based on this, the first acquisition module 720 may specifically include:

[0267] The acquisition submodule is used to obtain the ciphertext information of the second payment account from the security module.

[0268] In an embodiment of the present application, when the remaining resource value in the first payment account that is bound to the first e-wallet is less than the required resource value of the order to be paid, the first e-wallet platform requests the second e-wallet platform to obtain the second payment account that is bound to the second e-wallet, thereby breaking away from the limitations of the current e-wallet and seeking a payment account externally. When the first e-wallet platform obtains the second payment account fed back by the second e-wallet platform, the payment platform is requested to determine a third payment account whose remaining resource value is greater than or equal to the required resource value in the second payment account, and when the first e-wallet platform receives the third payment account fed back by the payment platform, the merchant's backend system sends the order to be paid and the third payment account to the payment platform, so that the payment platform can use the remaining resources in the third payment account to pay for the order to be paid, thereby achieving the goal of completing payment when the remaining resource value in the payment account that is bound to the e-wallet is less than the required resource value of the order to be paid, thereby improving the user's payment experience.

[0269] Based on the payment method applied to the payment platform provided in the above embodiment, the present application also provides a specific implementation of a payment device applied to the payment platform. Please refer to the following embodiments.

[0270] like Figure 8 As shown, the payment device 800 provided in this embodiment of the application includes the following modules:

[0271] A third receiving module 810 is configured to receive a second account acquisition request sent by the first electronic wallet platform, the second account acquisition request being used to request a third payment account whose remaining resource value is greater than or equal to the required resource value of the order to be paid, in the second payment account. The second account acquisition request is generated by the first electronic wallet platform when the remaining resource value in the first payment account is less than the required resource value of the order to be paid, the first electronic wallet platform includes a backend server of the first electronic wallet, the first payment account is bound to the first electronic wallet, and the second payment account is a payment account bound to the second electronic wallet.

[0272] A second acquisition module 820 is configured to obtain the remaining resource value of the second payment account from the resource management server to which the second payment account belongs in response to the second account acquisition request;

[0273] A determination module 830 is configured to determine the second payment account as a third payment account if the remaining resource value of the second payment account is greater than or equal to the required resource value;

[0274] A third sending module 840 is used to send a third payment account to the first electronic wallet platform;

[0275] The third receiving module 810 is further configured to receive the order to be paid and the third payment account number sent by the first electronic wallet platform via the merchant's backend system;

[0276] The payment module 850 is configured to use the remaining resources in the third payment account to pay for the order to be paid.

[0277] The payment device 800 is described in detail below.

[0278] In some embodiments, the second obtaining module 820 may specifically include:

[0279] A second sending submodule, configured to send a remaining resource query request to the resource management server to which the second payment account belongs;

[0280] The third receiving submodule is configured to receive a remaining resource value fed back by the resource management server in response to the remaining resource query request.

[0281] In some embodiments, the second payment account number is transmitted in encrypted form during the information transmission process. Based on this, the second acquisition module 820 may specifically include:

[0282] a conversion submodule, configured to convert the ciphertext information of the second payment account into plaintext information before sending a remaining resource query request to the resource management server to which the second payment account belongs;

[0283] The second determining submodule is configured to determine the resource management server to which the second payment account belongs based on the plain text information of the second payment account.

[0284] In some embodiments, there are multiple third payment accounts.

[0285] Based on this, the third receiving submodule is also used to receive the order to be paid and the target payment account sent by the first electronic wallet platform via the merchant's backend system. The target payment account is the payment account selected by the user from multiple third payment accounts for paying the order to be paid.

[0286] Based on this, the payment module 850 may specifically include:

[0287] The payment submodule is used to pay for pending orders using the remaining resources in the target payment account.

[0288] In an embodiment of the present application, when the remaining resource value in the first payment account that is bound to the first e-wallet is less than the required resource value of the order to be paid, the first e-wallet platform requests the second e-wallet platform to obtain the second payment account that is bound to the second e-wallet, thereby breaking away from the limitations of the current e-wallet and seeking a payment account externally. When the first e-wallet platform obtains the second payment account fed back by the second e-wallet platform, the payment platform is requested to determine a third payment account whose remaining resource value is greater than or equal to the required resource value in the second payment account, and when the first e-wallet platform receives the third payment account fed back by the payment platform, the merchant's backend system sends the order to be paid and the third payment account to the payment platform, so that the payment platform can use the remaining resources in the third payment account to pay for the order to be paid, thereby achieving the goal of completing payment when the remaining resource value in the payment account that is bound to the e-wallet is less than the required resource value of the order to be paid, thereby improving the user's payment experience.

[0289] Based on the payment method applied to the second electronic wallet provided in the above embodiment, the present application also provides a specific implementation of a payment device applied to the second electronic wallet. Please refer to the following embodiments.

[0290] like Figure 9 As shown, the payment device 900 provided in this embodiment of the application includes the following modules:

[0291] A fourth receiving module 910 is configured to receive a first account acquisition request sent by the first electronic wallet. The first account acquisition request is generated by the first electronic wallet platform and sent to the first electronic wallet when the remaining resource value in the first payment account is less than the required resource value of the order to be paid. The first payment account is bound to the first electronic wallet. The first account acquisition request is used to request acquisition of a second payment account that is bound to the second electronic wallet. The first electronic wallet platform includes a backend server of the first electronic wallet.

[0292] A third acquisition module 920 is configured to obtain a second payment account from a security module of a target electronic device in response to the first account acquisition request, where the target electronic device is an electronic device where the second electronic wallet is located;

[0293] The fourth sending module 930 is used to send the second payment account to the first electronic wallet, so that the first electronic wallet sends the second payment account to the first electronic wallet platform, and enables the first electronic wallet platform to obtain a third payment account based on the second payment account, and send the pending payment order and the third payment account to the payment platform via the merchant's backend system, so that the payment platform uses the remaining resources in the third payment account to pay for the pending payment order. The third payment account is a payment account in which the remaining resource value in the second payment account is greater than or equal to the required resource value.

[0294] Through the embodiments of the present application, even when the remaining resource value in the payment account bound to the e-wallet is less than the required resource value of the order to be paid, payment can still be completed, thereby improving the user's payment experience. In addition, obtaining the second payment account through a local call between the first e-wallet and the second e-wallet, without going through the backend server, can improve information acquisition speed and save communication resources.

[0295] Based on the payment method provided in the above embodiment, the embodiment of the present application also provides a specific implementation of the electronic device. Figure 10 A schematic diagram of an electronic device 1000 provided in an embodiment of the present application is shown.

[0296] The electronic device 1000 may include a processor 1010 and a memory 1020 storing computer program instructions.

[0297] Specifically, the processor 1010 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.

[0298] The memory 1020 may include a large capacity memory for data or instructions. By way of example and not limitation, the memory 1020 may include a hard disk drive (HDD), a floppy disk drive, a flash memory, an optical disk, a magneto-optical disk, a magnetic tape, or a universal serial bus (USB) drive, or a combination of two or more of these. Where appropriate, the memory 1020 may include removable or non-removable (or fixed) media. Where appropriate, the memory 1020 may be internal or external to the electronic device 1000. In a particular embodiment, the memory 1020 is a non-volatile solid-state memory.

[0299] The memory 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. Thus, 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 method according to the first aspect of the present application.

[0300] The processor 1010 implements any one of the payment methods in the above embodiments by reading and executing computer program instructions stored in the memory 1020 .

[0301] In one example, the electronic device 1000 may further include a communication interface 1030 and a bus 1040. Figure 10 As shown, the processor 1010, the memory 1020, and the communication interface 1030 are connected via a bus 1040 and communicate with each other.

[0302] The communication interface 1030 is mainly used to implement communication between various modules, devices, units and / or equipment in the embodiments of the present application.

[0303] Bus 1040 includes hardware, software or both, couples the parts of electronic equipment to each other.For example, and not limitation, bus may include accelerated graphics port (AGP) or other graphics bus, enhanced industry standard architecture (EISA) bus, front side bus (FSB), hypertransport (HT) interconnection, industry standard architecture (ISA) bus, infinite bandwidth interconnection, low pin count (LPC) bus, memory bus, micro channel architecture (MCA) bus, peripheral component interconnection (PCI) bus, PCI-Express (PCI-X) bus, serial advanced technology attachment (SATA) bus, video electronics standard association local (VLB) bus or other suitable bus or two or more of these combinations. In appropriate cases, bus 1040 may include one or more buses. Although the present application embodiment describes and shows specific bus, the application considers any suitable bus or interconnection.

[0304] Illustratively, the electronic device 1000 may be a mobile phone, a tablet computer, a laptop computer, a PDA, an in-vehicle electronic device, an ultra-mobile personal computer (UMPC), a netbook, or a personal digital assistant (PDA).

[0305] The electronic device can execute the payment method in the embodiment of the present application, thereby realizing the combination Figures 1 to 9 Payment methods and devices are described.

[0306] In addition, in conjunction with the payment methods in the above embodiments, embodiments of the present application also provide a payment system. The payment system may include the first e-wallet platform, the second e-wallet platform, and the payment platform in the above embodiments. The first e-wallet platform can execute the payment method applied to the first e-wallet platform in the above embodiments. The second e-wallet platform can execute the payment method applied to the second e-wallet platform in the above embodiments. The payment platform can execute the payment method applied to the payment platform in the above embodiments. For details, please refer to the relevant descriptions in the above embodiments, and since the same technical effects can be achieved, they will not be repeated here to avoid repetition.

[0307] In conjunction with the payment methods in the above embodiments, embodiments of the present application may provide a computer-readable storage medium for implementation. The computer-readable storage medium stores computer program instructions; when the computer program instructions are executed by a processor, any one of the payment methods in the above embodiments is implemented.

[0308] In combination with the payment method in the above embodiments, the present application can provide a computer program product to implement the payment method in the above embodiments. When the instructions in the computer program product are executed by a processor of an electronic device, any one of the payment methods in the above embodiments is implemented.

[0309] It should be understood that the present application is not limited to the specific configurations and processes described above and illustrated in the figures. For the sake of brevity, a detailed description of known methods is omitted here. In the above embodiments, several specific steps are described and illustrated as examples. However, the method process of the present application is not limited to the specific steps described and illustrated. Those skilled in the art can make various changes, modifications, and additions, or change the order of the steps after understanding the spirit of the present application.

[0310] The functional blocks shown in the above-described block diagram can be implemented as hardware, software, firmware or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of the present application are programs or code segments that are used to perform the required tasks. The program or code segment can be stored in a machine-readable medium, or transmitted on a transmission medium or a communication link by a data signal carried in a carrier wave. "Machine-readable medium" can include any medium that can store or transmit information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROMs, flash memories, erasable ROMs (EROMs), floppy disks, CD-ROMs, optical disks, hard disks, optical fiber media, radio frequency (RF) links, etc. The code segment can be downloaded via a computer network such as the Internet, an intranet, etc.

[0311] It should also be noted that the exemplary embodiments mentioned in this application describe some methods or systems based on a series of steps or devices. However, this application is not limited to the order of the above steps. In other words, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0312] 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.

[0313] The above description is only a specific embodiment of the present application. Those skilled in the art will clearly understand that for the convenience and brevity of description, the specific working processes of the systems, modules and units described above can refer to the corresponding processes in the aforementioned method embodiments, and will not be repeated here. It should be understood that the scope of protection of the present application is not limited thereto. Any person skilled in the art can easily think of various equivalent modifications or replacements within the technical scope disclosed in the present application, and these modifications or replacements should be included in the scope of protection of the present application.

Claims

1. A payment method, characterized in that: Applied to a first electronic wallet platform, the first electronic wallet platform includes a backend server of a first electronic wallet, the first electronic wallet is bound to a first payment account, and the method includes: When the remaining resource value in the first payment account is less than the required resource value of the order to be paid, sending a first account acquisition request to a second e-wallet platform, where the second e-wallet platform includes a backend server of the second e-wallet, and the first account acquisition request is used to request a second payment account that is bound to the second e-wallet; Receiving the second payment account number fed back by the second electronic wallet platform in response to the first account acquisition request; Sending a second account acquisition request to the payment platform, where the second account acquisition request is used to request a third payment account whose remaining resource value is greater than or equal to the required resource value to be determined in the second payment account; Receiving the third payment account number fed back by the payment platform in response to the second account acquisition request; The order to be paid and the third payment account are sent to the payment platform via the merchant's backend system, so that the payment platform uses the remaining resources in the third payment account to pay for the order to be paid.

2. The method according to claim 1, characterized in that Before sending the order to be paid and the third payment account to the payment platform via the merchant's backend system, the method further includes: Sending an authorization request to the second electronic wallet platform for authorizing the first electronic wallet to use the third payment account for payment; receiving authorization information fed back by the second electronic wallet platform in response to the authorization request; The sending of the order to be paid and the third payment account to the payment platform via the merchant's backend system includes: When the authorization information indicates that the authorization is passed, the order to be paid and the third payment account are sent to the payment platform via the merchant's backend system.

3. The method according to claim 2, characterized in that Before sending the order to be paid and the third payment account to the payment platform via the merchant's backend system, the method further includes: When the authorization information indicates that the authorization is passed, a binding relationship between the first electronic wallet and the third payment account is established.

4. The method according to claim 3, characterized in that The establishing of a binding relationship between the first electronic wallet and the third payment account includes: Displaying a verification information input box on the interactive interface of the first electronic wallet, wherein the verification information input box is used for the user to input verification information for verifying the third payment account; In response to the user's input in the verification information input box, determining verification information for verifying the third payment account; When the verification information is verified successfully, a binding relationship between the first electronic wallet and the third payment account is established.

5. The method according to any one of claims 2 to 4, characterized in that: There are multiple third payment accounts, and the authorization information includes a target payment account, which is any one of the multiple third payment accounts; The sending of the order to be paid and the third payment account to the payment platform via the merchant's backend system includes: The order to be paid and the target payment account are sent to the payment platform via the merchant's backend system.

6. The method according to any one of claims 2 to 4, characterized in that: There are multiple third payment accounts; and sending an authorization request to the second electronic wallet platform for authorizing the first electronic wallet to use the third payment account for payment includes: Displaying a plurality of the third payment accounts on the interactive interface of the first electronic wallet; receiving a first selection input of a user selecting a target payment account from a plurality of third payment accounts; In response to the first selection input, sending an authorization request to the second electronic wallet platform for authorizing the first electronic wallet to use the target payment account for payment; When the authorization information indicates that the authorization is passed, sending the order to be paid and the third payment account to the payment platform via the merchant's backend system includes: When the authorization information indicates that the authorization is passed, the order to be paid and the target payment account are sent to the payment platform via the merchant's backend system.

7. The method according to any one of claims 1 to 4, characterized in that The second payment account and / or the third payment account are transmitted in the form of encrypted information during the information transmission process.

8. A payment method, characterized in that: Applied to a second electronic wallet platform, the second electronic wallet platform includes a backend server of the second electronic wallet, and the method includes: receiving a first account acquisition request sent by a first e-wallet platform, the first account acquisition request being generated by the first e-wallet platform when a remaining resource value in a first payment account is less than a required resource value for an order to be paid, the first e-wallet platform including a backend server for the first e-wallet, the first payment account being bound to the first e-wallet, and the first account acquisition request being used to request acquisition of a second payment account being bound to the second e-wallet; Responding to the first account acquisition request, acquiring the second payment account; The second payment account is sent to the first e-wallet platform so that the first e-wallet platform obtains a third payment account based on the second payment account, and the order to be paid and the third payment account are sent to the payment platform via the merchant's backend system so that the payment platform uses the remaining resources in the third payment account to pay for the order to be paid. The third payment account is a payment account in which the remaining resource value in the second payment account is greater than or equal to the required resource value.

9. The method according to claim 8, characterized in that After sending the second payment account to the first electronic wallet platform, the method further includes: receiving an authorization request sent by the first electronic wallet platform for authorizing the first electronic wallet platform to use the third payment account for payment; In response to the authorization request, displaying first authorization prompt information for authorizing the third payment account on the interactive interface of the second electronic wallet; Receiving a confirmation input from the user regarding the first authorization prompt information; generating authorization information in response to the confirmation input; Send the authorization information to the first electronic wallet platform.

10. The method according to claim 9, characterized in that There are multiple third payment accounts, and before receiving the user's confirmation input of the first authorization prompt information, the method further includes: In response to the authorization request, displaying the plurality of third payment accounts in an interactive interface of the second electronic wallet; receiving a second selection input of the user selecting a target payment account from the plurality of third payment accounts; In response to the second selection input, displaying second authorization prompt information for authorizing the target payment account; The receiving a confirmation input of the user regarding the first authorization prompt information includes: Receive a user confirmation input for the second authorization prompt information.

11. The method according to claim 10, characterized in that The authorization information includes the target payment account number.

12. The method according to any one of claims 8 to 11, characterized in that The second payment account number is transmitted in encrypted form during the information transmission process. The encrypted information of the second payment account number is stored in a security module of a target electronic device, where the target electronic device is the electronic device where the second electronic wallet is located. The obtaining of the second payment account number includes: Obtain the encrypted information of the second payment account from the security module.

13. A payment method, characterized in that: Applied to a payment platform, the method includes: receiving a second account acquisition request sent by a first e-wallet platform, the second account acquisition request being used to request a third payment account whose remaining resource value is greater than or equal to the required resource value of the order to be paid, in the second payment account; the second account acquisition request being generated by the first e-wallet platform when the remaining resource value in the first payment account is less than the required resource value of the order to be paid; the first e-wallet platform including a backend server of the first e-wallet; the first payment account being bound to the first e-wallet; and the second payment account being a payment account bound to the second e-wallet; In response to the second account acquisition request, acquiring the remaining resource value of the second payment account from the resource management server to which the second payment account belongs; If the remaining resource value of the second payment account is greater than or equal to the required resource value, determining the second payment account as the third payment account; Sending the third payment account to the first electronic wallet platform; Receiving the order to be paid and the third payment account sent by the first electronic wallet platform via the merchant's backend system; The remaining resources in the third payment account are used to pay for the order to be paid.

14. The method according to claim 13, characterized in that The obtaining the remaining resource value of the second payment account from the resource management server to which the second payment account belongs includes: Sending a remaining resource query request to the resource management server to which the second payment account belongs; Receive the remaining resource value fed back by the resource management server in response to the remaining resource query request.

15. The method according to claim 14, characterized in that The second payment account is transmitted in encrypted form during information transmission. Before sending the remaining resource query request to the resource management server to which the second payment account belongs, the method further includes: Converting the encrypted information of the second payment account into plain text information; The resource management server to which the second payment account belongs is determined according to the plaintext information of the second payment account.

16. The method according to any one of claims 13 to 15, characterized in that: There are multiple third payment accounts, and receiving the order to be paid and the third payment account sent by the first electronic wallet platform via the merchant's backend system includes: receiving the order to be paid and the target payment account sent by the first electronic wallet platform via the merchant's backend system, where the target payment account is a payment account selected by the user from among the plurality of third payment accounts for paying the order to be paid; The using the remaining resources in the third payment account to pay for the order to be paid includes: Use the remaining resources in the target payment account to pay for the order to be paid.

17. A payment method, characterized in that: Applied to the second electronic wallet, the method includes: receiving a first account acquisition request sent by a first e-wallet, the first account acquisition request being generated by the first e-wallet platform and sent to the first e-wallet when a remaining resource value in a first payment account is less than a required resource value of an order to be paid, the first payment account being bound to the first e-wallet, the first account acquisition request being used to request acquisition of a second payment account being bound to the second e-wallet, and the first e-wallet platform including a backend server of the first e-wallet; In response to the first account acquisition request, acquiring the second payment account from a security module of a target electronic device, where the target electronic device is the electronic device where the second electronic wallet is located; The second payment account is sent to the first electronic wallet so that the first electronic wallet sends the second payment account to the first electronic wallet platform, and the first electronic wallet platform obtains a third payment account based on the second payment account, and sends the order to be paid and the third payment account to the payment platform via the merchant's backend system, so that the payment platform uses the remaining resources in the third payment account to pay for the order to be paid. The third payment account is a payment account in which the remaining resource value in the second payment account is greater than or equal to the required resource value.

18. A payment device, characterized in that: Applied to a first electronic wallet platform, the first electronic wallet includes a backend server of the first electronic wallet, the first electronic wallet is bound to a first payment account, and the device includes: a first sending module configured to send a first account acquisition request to a second e-wallet platform when the remaining resource value in the first payment account is less than the required resource value of the order to be paid, the second e-wallet platform including a backend server of the second e-wallet, the first account acquisition request being used to request acquisition of a second payment account bound to the second e-wallet; a first receiving module, configured to receive the second payment account number fed back by the second electronic wallet platform in response to the first account acquisition request; The first sending module is further configured to send a second account acquisition request to the payment platform, wherein the second account acquisition request is configured to request a third payment account whose remaining resource value is greater than or equal to the required resource value to be determined in the second payment account; The first receiving module is further configured to receive the third payment account number fed back by the payment platform in response to the second account number acquisition request; The first sending module is further configured to send the order to be paid and the third payment account to the payment platform via the merchant's backend system, so that the payment platform uses the remaining resources in the third payment account to pay for the order to be paid.

19. A payment device, characterized in that: Applied to a second electronic wallet platform, the second electronic wallet platform includes a backend server of the second electronic wallet, and the device includes: a second receiving module, configured to receive a first account acquisition request sent by a first e-wallet platform, the first account acquisition request being generated by the first e-wallet platform when a remaining resource value in a first payment account is less than a required resource value for an order to be paid, the first e-wallet platform including a backend server for the first e-wallet, the first payment account being bound to the first e-wallet, and the first account acquisition request being used to request acquisition of a second payment account that is bound to the second e-wallet; A first acquisition module, configured to acquire the second payment account in response to the first account acquisition request; The second sending module is used to send the second payment account to the first electronic wallet platform, so that the first electronic wallet platform obtains a third payment account based on the second payment account, and sends the order to be paid and the third payment account to the payment platform via the merchant's backend system, so that the payment platform uses the remaining resources in the third payment account to pay for the order to be paid. The third payment account is a payment account in which the remaining resource value in the second payment account is greater than or equal to the required resource value.

20. A payment device, characterized in that: Applied to a payment platform, the device comprises: a third receiving module, configured to receive a second account acquisition request sent by the first e-wallet platform, the second account acquisition request being used to request a third payment account whose remaining resource value is greater than or equal to the required resource value of the order to be paid, in the second payment account; the second account acquisition request being generated by the first e-wallet platform when the remaining resource value in the first payment account is less than the required resource value of the order to be paid; the first e-wallet platform includes a backend server of the first e-wallet; the first payment account is bound to the first e-wallet; and the second payment account is a payment account bound to the second e-wallet; a second obtaining module, configured to obtain, in response to the second account obtaining request, the remaining resource value of the second payment account from the resource management server to which the second payment account belongs; a determination module, configured to determine the second payment account as a third payment account when the remaining resource value of the second payment account is greater than or equal to the required resource value; A third sending module, configured to send the third payment account to the first electronic wallet platform; The third receiving module is further configured to receive the order to be paid and the third payment account number sent by the first electronic wallet platform via the merchant's backend system; A payment module is used to pay for the order to be paid using the remaining resources in the third payment account.

21. A payment device, characterized in that: Applied to a second electronic wallet, the device includes: a fourth receiving module, configured to receive a first account acquisition request sent by a first e-wallet, the first account acquisition request being generated and sent to the first e-wallet by the first e-wallet platform when the remaining resource value in the first payment account is less than the required resource value of the order to be paid, the first payment account being bound to the first e-wallet, the first account acquisition request being used to request acquisition of a second payment account being bound to the second e-wallet, and the first e-wallet platform including a backend server of the first e-wallet; a third acquisition module, configured to obtain the second payment account from a security module of a target electronic device in response to the first account acquisition request, where the target electronic device is the electronic device where the second electronic wallet is located; The fourth sending module is used to send the second payment account to the first electronic wallet, so that the first electronic wallet sends the second payment account to the first electronic wallet platform, and enables the first electronic wallet platform to obtain a third payment account based on the second payment account, and send the pending payment order and the third payment account to the payment platform via the merchant's backend system, so that the payment platform uses the remaining resources in the third payment account to pay for the pending payment order. The third payment account is a payment account in which the remaining resource value in the second payment account is greater than or equal to the required resource value.

22. An electronic device, characterized in that: The electronic device includes: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, the payment method according to any one of claims 1-7, 8-12, 13-16 or 17 is implemented.

23. A payment system, characterized in that: include: A first electronic wallet platform, configured to execute the payment method according to any one of claims 1 to 7; A second electronic wallet platform, configured to execute the payment method according to any one of claims 8 to 12; A payment platform, configured to execute the payment method as described in any one of claims 13 to 16.

24. 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 payment method according to any one of claims 1-7, 8-12, 13-16 or 17.

25. A computer program product, characterized in that When the instructions in the computer program product are executed by a processor of an electronic device, the electronic device executes the payment method as described in any one of claims 1-7 or 8-12 or 13-16 or 17.

Images